At 4am in a Midlands haulage office, the night dispatcher notices that a driver is close to the weekly hours limit. The tachograph download sits in one compliance application, the ERP has already assigned that driver to a Friday international job, and the transport management system contains a different vehicle reference. Nobody has one reliable operational view. The operator licence clock is still running, and the decision can't wait for someone to reconcile three screens and a spreadsheet.
That situation is the starting point for legacy system integration in UK fleets. This isn't primarily a software refresh. It's about keeping compliance data, vehicle activity, driver availability and booked work aligned when telematics devices, tachographs, dashcams, CAN-bus feeds, transport systems and ERP platforms were built at different times for different jobs.
The UK government's State of Digital Government Review estimated that legacy technology made up 28% of systems in central government departments in 2024, compared with 26% in 2023. The review also linked ageing technology with about £45 billion a year in lost public-sector productivity, showing why organisations increasingly need controlled coexistence rather than a reckless rip-and-replace programme. The same principle applies in haulage. Keep the systems that still perform a necessary function, but give them dependable ways to exchange information.
Table of Contents
- Why Fleet Telematics and Legacy Systems Need to Talk
- Choosing the Right Integration Architecture
- Mapping Telematics Data Into Your Back Office
- Picking APIs, Middleware, and Connection Methods
- Testing the Integration Before You Go Live
- Security, Compliance, and Data Handling From Day One
- Rolling Out Without Breaking Operations
Why Fleet Telematics and Legacy Systems Need to Talk
The dispatcher in that 4am scenario doesn't need another dashboard for its own sake. She needs to answer practical questions quickly. Has the driver completed the required download? How much legal availability remains? Is the vehicle assigned to the correct job? Does the planned run depend on equipment that has a maintenance exception or a missing compliance record?
A telematics platform may know the vehicle's location and movement. A tachograph service may hold driver-card and vehicle-unit files. A dashcam platform may contain incident evidence, while the ERP stores customer orders, asset codes and invoicing data. The TMS may own the schedule. Each system can be accurate within its own boundary and still leave the operator with an incomplete picture.
Practical rule: Integrate decisions, not every available data point.
A useful integration passes the information needed for a workflow and preserves the source system for the records it owns. Driver-hours status might flow into planning. A vehicle's true odometer reading might support maintenance scheduling. A geofence event might trigger an exception for the transport team. The raw tachograph file should remain available in its controlled archive, rather than being flattened into a number that loses its evidential value.
The operational cost of disconnected records
The fleet data integration guide for operators is useful context because it treats the problem as a flow of operational information rather than a collection of disconnected products. That distinction matters on mixed fleets. Hardware serials, registration numbers, ERP asset codes and driver identifiers rarely line up automatically, and a technically successful connection can still produce unsafe planning if the identity mapping is wrong.
The National Audit Office has previously shown the scale of legacy dependency in public services. Its review estimated that at least £480 billion of central government revenue and at least £210 billion of non-staff expenditure relied to some extent on legacy ICT, while annual government IT spending was reported at £4.7 billion, including £2.3 billion spent keeping old systems running. The figures are government-specific, but the operational lesson is broader. Old systems often sit underneath critical processes because replacing them would interrupt the work they support. The Networking2000 migration playbook for SMEs offers a useful migration perspective for organisations that need to manage that dependency without treating replacement as the only answer.
What integration should restore
A sound design creates a trusted operational picture while respecting system ownership. The compliance application remains authoritative for tachograph analysis. The TMS remains responsible for jobs and planning. The ERP retains commercial and asset records. The integration layer synchronises the fields and events that staff need to act on, with timestamps, error handling and an audit trail.
That approach protects continuity. It also creates a safer route to automation and AI, because connected, consistently identified data matters more than adding a model to an estate that can't agree which vehicle or driver a record describes.
Choosing the Right Integration Architecture
Architecture should follow the fleet's complexity, not an aspirational enterprise diagram. A 40-truck operator with one telematics provider and one TMS has different needs from a multi-site group running several hardware estates, an ERP, a compliance platform and multiple planning consumers.
The four patterns that appear most often are point-to-point connections, an enterprise service bus, an integration platform as a service, and an API gateway supported by shared services. The F1Group overview of integration patterns provides useful background, but fleet projects need a more operational test. Ask how the pattern behaves when a telematics vendor changes an endpoint, a file arrives late, or an ERP rejects a record during a busy planning period.
| Pattern | Best fit | Upfront cost | Maintenance risk | Time to first sync |
|---|---|---|---|---|
| Point-to-point scripts | Small fleet with one telematics vendor and one TMS | Low | High as connections multiply | Fast |
| Enterprise service bus | Multi-site operator with mature IT governance | High | Lower when centrally governed, but complex | Slower |
| iPaaS | Mid-sized haulier needing managed connectors and faster delivery | Medium | Moderate, depending on vendor and configuration | Fast to moderate |
| API gateway with shared services | Estate with several downstream consumers and reusable business services | Medium to high | Moderate when ownership is clear | Moderate |
Point-to-point is a deliberate choice, not a shortcut
A small operator can sensibly use a focused service that receives a webhook, transforms the payload and updates the TMS. A scheduled process can collect tachograph files from SFTP and place them into the compliance workflow. That design is inexpensive to understand and quick to deploy.
It becomes fragile when every new consumer gets its own script. A vendor API change then requires a search through undocumented code, and a failure in one connection can be difficult to distinguish from a bad source record.
ESB and iPaaS solve different problems
An ESB suits organisations that already have central integration skills, formal change control and a broad application estate. It can enforce routing, transformation and monitoring, but it brings platform administration that a smaller fleet may not need.
An iPaaS can be a practical middle ground. Managed connectors, monitoring and reusable transformations reduce the amount of infrastructure the operator must own. The trade-off is dependency on the provider's connector quality, pricing model and release process. A connector that handles simple vehicle updates may still need custom logic for tachograph files, driver identity and compliance exceptions.
Use an API gateway when reuse justifies it
An API gateway earns its place when several applications need the same controlled service, such as a canonical vehicle status or driver availability feed. It can standardise authentication, rate limiting and logging at the boundary. It won't fix poor data ownership or ambiguous identifiers, though.
The decision rule is simple. Choose the least complex pattern that can survive the next two vendor changes, not just the first integration. If the answer is a small managed service with strong monitoring, don't buy an enterprise platform to make the architecture look mature.
Mapping Telematics Data Into Your Back Office
Most integration failures aren't caused by the HTTP request. They happen because two systems use different names for the same operational object, or the same name for different objects. A vehicle might appear as a hardware serial in the telematics platform, a registration number in the fleet office and an asset code in the ERP. A driver might be identified by a tachograph card ID, a personnel number and an operator licence record.
Start with a canonical record owned by the business, not by the vendor.
Establish identity before transformation
Create a vehicle master with a stable internal identifier and explicit relationships to every external reference. For example:
- Canonical vehicle ID: TRK-042
- Registration: the current registration held by fleet administration
- Telematics reference: device or platform identifier
- ERP asset code: the accounting and maintenance reference
- TMS reference: the planning-system vehicle key
- Status: active, spare, sold or unavailable
If a tracker is replaced, the canonical vehicle remains TRK-042 while the telematics reference changes. If the vehicle is re-registered, the relationship is updated without rewriting historical journeys. That distinction prevents reports from splitting one asset into several apparent vehicles.
Use the same discipline for drivers. Keep the tachograph card identifier, personnel number and compliance record as separate fields linked to one canonical driver ID. Don't use a registration number or employee name as the primary key. Names change, registrations can be reassigned, and free-text fields contain spelling variations.
Normalise units and time deliberately
A mileage value without a unit is unusable. Decide whether the canonical model stores distance in miles or kilometres, fuel in litres or another agreed measure, and timestamps in UTC with a separate presentation timezone. Apply conversion once at the boundary and record the original value when it may matter for audit or investigation.
A journey arriving at 23:30 UTC may appear on the UK operations screen at a different local time depending on daylight-saving rules. If one system writes local time and another assumes UTC, an overnight event can land on the wrong operational day. That can distort driver-hours review, job sequencing and incident investigation.
Treat files and signals as contracts
Tachograph downloads can arrive through formats such as .ddd, .esm and .c1b, while mixed OEM CAN-bus feeds may use different names or meanings for apparently similar signals. Build a versioned parser and mapping document, then retain the original file alongside the transformed record.
Three rules deserve particular attention:
- Vehicle identity must be stable. A wrong vehicle mapping contaminates location, fuel, mileage, maintenance and compliance outputs.
- Driver identity must be authoritative. A driver-hours event attached to the wrong person can create a serious planning and audit problem.
- Time and units must be explicit. A technically valid value can still be operationally wrong if the receiving system interprets its unit or timezone differently.
The UK fleet telematics integration workflow provides a useful way to think about source capture, validation, transformation and delivery as one controlled chain. Test the mapping with known records before allowing historical imports or live updates.
Picking APIs, Middleware, and Connection Methods
A 20- to 200-vehicle haulier doesn't automatically need an enterprise middleware estate. The right question is whether the connection method gives the operations team reliable delivery, useful visibility and a controlled recovery path.
REST APIs are usually practical for current vehicle status, journeys and alerts. SOAP may still appear in older ERP or transport applications, and it isn't unusable. The integration service should isolate that older protocol from newer consumers rather than forcing every application to understand it.
Webhooks are valuable for events that need prompt attention, such as a driver-hours alert or an incident notification. They need authentication, payload validation, idempotency and a retry strategy. Scheduled SFTP remains entirely reasonable for tachograph files when the source system already delivers .ddd files that way. Replacing a dependable file exchange with a fashionable API can introduce risk without improving the workflow.
| Method | Best for | Typical latency | Maintenance effort | Rough cost band |
|---|---|---|---|---|
| REST API polling | Periodic status and journey synchronisation | Minutes to hours | Moderate | Low to medium |
| Webhook receiver | Alerts and event-driven workflows | Near real time | Moderate | Low to medium |
| Scheduled SFTP | Tachograph file delivery and batch exchange | Scheduled | Low to moderate | Low |
| Native ERP connector | Standard finance, asset or order updates | Connector dependent | Low to moderate | Medium |
| Lightweight iPaaS | Several managed connections and transformations | Near real time to scheduled | Moderate | Medium |
| Self-hosted gateway | Reusable APIs, policy and multiple consumers | Near real time | High | Medium to high |
Keep the middleware honest
A single Python service with scheduled jobs may be the right answer where the estate is small and the transformation rules are stable. It still needs proper logging, secrets management, deployment control, health checks and a dead-letter queue. “Simple” shouldn't mean “unrecoverable”.
A lightweight iPaaS earns its keep when the operator needs managed connectors, visual monitoring and support for multiple flows. A self-hosted gateway such as Kong or an enterprise platform such as MuleSoft makes more sense when several teams consume shared services and the organisation can staff the platform properly. Neither product removes the need to understand the data.
Configure for failure
Set a rate-limit strategy before production. Use exponential backoff for temporary provider errors, but don't retry a malformed record indefinitely. Add an idempotency key so a repeated webhook doesn't create a duplicate journey or alert. Send poison messages to a dead-letter queue with the source payload, error reason and retry history.
Run the old and new paths in parallel during cutover. Compare accepted records, rejected records and timestamps, then resolve differences before staff rely on the new feed. A middleware checklist should confirm ownership, rate limits, retries, dead-letter handling, alert routing, audit retention and the person who can change a mapping at 3am.
Testing the Integration Before You Go Live
Testing needs to follow the data's journey, from one field in one payload to the transport manager's decision at the end of the process. A green API response proves very little if the receiving compliance application rejects the file or the ERP assigns the event to the wrong asset.
Start with field-level tests. Validate required fields, data types, enumerations, timestamp rules, unit conversions and identity lookups. Then replay a set of known-good and deliberately invalid tachograph files, including .ddd and .v1b downloads where those formats are part of the operating estate. The test should confirm not only successful processing, but also the exact error placed in the exception queue.
Build evidence as you test
Use contract tests against the telematics provider's sandbox where one exists. They should detect changes to field names, authentication, pagination and event payloads before a provider release reaches production. For ERP connections, test both accepted and rejected records, including duplicate asset codes, missing drivers and invalid job references.
Replay golden files through the full pipeline. A golden file is a retained input with an expected output, exception result and audit entry. It gives the team a repeatable way to prove that a parser or mapping change hasn't altered established behaviour.
Load testing should imitate operational peaks rather than an abstract request rate. Simulate a concentrated batch of driver-card or vehicle-unit downloads, then observe queue depth, processing time, API responses and ERP rejects. The system must fail visibly and recover predictably when a downstream service slows down.
Put operations in the test room
User acceptance testing should involve dispatchers, transport managers and the person responsible for compliance records. Give them real scenarios to exercise:
- Planning conflict: a driver with limited availability is assigned to a job.
- Missing download: a vehicle file doesn't arrive in the expected landing folder.
- Identity exception: a newly added vehicle has no mapped ERP code.
- Provider outage: the telematics endpoint is unavailable and retries begin.
- Rollback: staff return to the known-good process without losing evidence.
Every phase should leave rollback artefacts. Take a verified ERP snapshot, preserve a known-good SFTP landing folder and keep an audit log that compliance staff can inspect. A pilot on a small, representative group of vehicles should run before the full fleet, including different hardware types and the workflows that cause the most operational pressure.
Security, Compliance, and Data Handling From Day One
Security added after go-live becomes a negotiation with operations. By then, someone may already have copied driver-hours data into an open shared folder, granted broad access to solve a support problem or disabled a control that interrupted downloads.
Protect the flow before the first live record moves. Use TLS 1.2 or later in transit, encrypted SFTP for tachograph file exchanges and role-based access control that separates viewing, planning, administration and compliance actions. A dispatcher may need to see availability, but that doesn't mean they should be able to edit driver-card data or alter the source file.
Separate records by purpose and authority
Keep DVLA-related data, tachograph data and operational telemetry logically separated, with access granted according to a defined business need. The integration should document which system is authoritative for each field and whether a downstream application can write back.
A process that mutates compliance data needs a tamper-evident audit trail. Record the original value, the transformed value, the actor or service account, the timestamp, the reason for the change and the correlation ID for the transaction. If the system only reads and presents data, document that boundary clearly. Auditors and compliance teams need to know whether they are looking at source evidence or a derived operational view.
Retention must support the real duty
Retention rules should align with the organisation's operator licence record-keeping responsibilities and its data protection obligations. Don't retain every raw feed indefinitely just because storage is inexpensive. Define retention for raw tachograph files, transformed records, alerts, access logs and failed messages separately, then document the deletion process.
Maintain the processing record required by GDPR Article 30 where applicable. Review supplier access, service accounts, encryption, incident handling and backup restoration before cutover. A compliance workflow that can't produce its evidence during an inspection isn't complete, even if the integration has been technically available.
The transport manager and IT lead should sign off that:
- Access is role based: staff can see and change only what their jobs require.
- Transport is encrypted: API traffic and file transfers use approved protection.
- Source ownership is documented: each compliance field has a named authoritative system.
- Changes are traceable: mutations create tamper-evident audit records.
- Retention is defined: raw files, derived data and logs have approved handling rules.
- Recovery is tested: the team can restore service and preserve evidence after failure.
Rolling Out Without Breaking Operations
A rollout succeeds when the night shift can keep working during a supplier outage, a bad file and an unexpected mapping exception. The technical deployment is only one part of that outcome. The rest is a controlled operating model with named owners, visible health indicators and clear exit gates.
Phase one and readiness
Before cutover, freeze the mapping catalogue and take the verified ERP backup. Confirm source credentials, SFTP paths, webhook endpoints, alert routes, support contacts and the manual fallback procedure. The exit gate is evidence that the final system backup has been verified and that the team can recover the known-good process.
The integration runbook should name the person on call when a tachograph download fails at 03:00. It should also state who can pause a flow, who can approve a data correction and who informs the transport manager. Avoid a shared mailbox as the only escalation route.
Phase two and shadow operation
In shadow mode, the new integration observes and transforms live inputs without becoming the operational system of record. Dispatchers and planners compare its output with the established workflow, recording differences rather than correcting them.
Measure sync latency, API error rate, file completeness, ERP reject rate and exception queue size. Don't set arbitrary targets without baselining the actual process. Define the variance that triggers investigation and the condition that stops the trial. The supplied rollout visual captures the principle of using exit gates rather than relying on optimism.
Phase three and parallel operation
Parallel operation lets the new path process live records while the existing path remains available. Reconcile vehicles, drivers, downloads, alerts and ERP updates. A mismatch isn't automatically a software defect. It may reveal that one system uses a different business rule, timezone or definition of a completed download.
Use the fleet telematics implementation guide to keep the operational work visible, including hardware fitment, user preparation, workflow ownership and support arrangements. Tell drivers and planners what they will see during shadow and parallel modes, and explain which screen remains authoritative until the cutover gate is passed.
Phase four and controlled cutover
Cut over during a period with manageable operational demand, not during a peak operating week or immediately before a major compliance deadline. Keep the old route available for the agreed rollback window, monitor the exception queue actively and require operations to confirm that live data is arriving before closing the change.
The first days need more staffing than the steady state. Someone must review failures, distinguish source-data problems from integration defects and communicate decisions quickly. Keep screenshots, logs, reconciliation results, approvals and rollback decisions in the project record. Those artefacts demonstrate control when the traffic commissioner or an auditor asks how the operator preserved compliance evidence through the change.
Three mistakes repeatedly derail fleet programmes:
- Cutting over at the wrong time: peak operations turn small defects into missed jobs and unsafe workarounds.
- Under-staffing early support: unresolved exceptions encourage planners to bypass the new process.
- Leaving documentation until the end: undocumented mappings and recovery steps become tribal knowledge.
Targeted integration can deliver operational value without replacing every old application. ONS reported that it migrated three critical short-term surveys from legacy systems in December 2025, with a 15% improvement in Monthly Business Survey clearance rates and faster error resolution, as recorded in the UK government review of digital government. The wider lesson for fleets is practical. A carefully bounded integration, measured against a real operational workflow, can be more useful than a grand modernisation programme that leaves staff waiting for the replacement system.
Fleetalyse connects remote tachograph download feeds with existing tachograph analysis software using an industry-standard format, alongside GPS tracking, mixed-fleet telemetry and smart dashcam workflows. If your fleet needs to wrap older back-office systems without losing operator licence visibility, visit Fleetalyse to discuss the data flows, hardware estate and rollout controls that fit your operation.