The European TMS Migration Playbook: Moving Off Legacy Systems Without Breaking WMS and ERP Integrations (2026)

European TMS migrations are governed by dependency, not effort

Most migration plans are built as effort estimates. Count the integrations, size the data migration, allocate engineers, derive a timeline. That method works when effort is the binding constraint.

In Europe it usually is not. A migration that touches how drivers are allocated work triggers employee consultation obligations in several jurisdictions. A migration that crosses a reporting year boundary carries an emissions data lineage problem. A migration that spans five countries inherits five constraint models rather than one. None of these compress when you add developers, and all of them sit on the critical path ahead of the integration work that migration plans usually treat as the long pole.

The consequence of misdiagnosing this is well documented. Gartner predicts that more than 40 percent of agentic AI projects will be cancelled by the end of 2027, attributing this to escalating costs, unclear business value, and inadequate risk controls. Model capability is not among the named causes. All three are governance and planning failures, and the pattern is recognisable in TMS programmes that scoped for technical work and were stopped by everything else.

The upside is real enough to justify doing it properly. A Gartner-commissioned analysis indicates that the average TMS user can expect to save 5 to 15 percent of annual freight costs, with more than 40 percent of adopters breaking even within 6 to 12 months and a further 25 percent within 18. That is payback rather than deployment duration, and the two are frequently confused in vendor material.

Locus, the world’s first agentic Transportation Management System, is deployed in this pattern rather than as a replacement for the surrounding stack. Built by Mara Labs Inc. and acquired by Ingka Group, parent of IKEA, in 2025, it runs across 360+ enterprise customers and 30+ countries, modelling 250+ real-world constraints per computation.

Also Read: How Enterprises Migrate from Legacy Transportation Management Systems to AI-Native Architecture

The five dependencies that set the schedule

1. Employee consultation and works council agreement

In Germany, France, the Netherlands, and several other member states, introducing a system that allocates work, monitors performance, or changes working conditions engages statutory employee consultation. In Germany specifically, co-determination gives the works council a substantive role rather than an advisory one, and dispatch algorithms fall inside its scope because they determine what a driver’s day looks like.

This is the dependency most migration plans discover late. It cannot be shortened by resourcing, it can only be started earlier, and starting it earlier requires having enough design detail to consult on. It also interacts with the EU AI Act, since worker management is a high-risk category, and with GDPR provisions on automated decision-making.

2. Data egress from the incumbent platform

Getting historical data out of a legacy TMS is a contractual question before it is a technical one. What is exportable, in what format, over what period, and at what cost. The EU Data Act’s switching and egress provisions strengthen the customer’s position here, but the practical timeline is still set by the incumbent’s export tooling and notice periods, neither of which is under your control.

What you need out is narrower than what you might want: historical carrier performance for scorecard baselines, rate structures, master data, and enough completed-shipment history to validate the new system’s plans against known outcomes.

3. CSRD data lineage continuity across cutover

If transport emissions data feeds sustainability reporting, cutover creates a lineage break. Two systems produce the year’s data using potentially different emissions factors and calculation methods, and an assurance provider will want to see the join documented.

Scope here is shifting, which changes who this applies to. EFRAG found that nearly 89 percent of surveyed companies rated the effort of implementing ESRS as enacted in 2023 as high or very high, with the revised draft cutting mandatory datapoints by 61 percent. And the European Commission’s Omnibus package is expected to remove around 80 percent of companies from CSRD scope while reducing administrative costs by approximately 4.4 billion euros annually. Establish which side of the revised scope you sit on before treating this as a hard dependency, because for many mid-market European operations it no longer is.

Also Read: Which CSRD Scope 3 Path Fits Your Operation? A Decision Framework for European Logistics Leaders

4. Multi-country constraint modelling

A single-country migration configures one constraint model. A multi-country migration configures several, because driving time and rest limits under Regulation (EC) 561/2006 interact with national working time implementations under Directive 2002/15/EC, GB operators run retained drivers’ hours rules that diverge in detail, and low-emission zone rules differ city by city.

This is the dependency most often underestimated, because the configuration work looks repeatable and is not. Each market has its own interpretation questions, and answering them requires local operational input rather than central configuration.

Also Read: The 28-Interpretation Problem: Why EU Compliance Isn’t One Compliance Standard

5. Security review and data residency during parallel run

Parallel running means two systems process driver and recipient personal data simultaneously, which doubles the processing surface for the duration. NIS2 raises vendor due diligence expectations for operators in scope, and residency commitments have to hold for both systems at once.

The review itself is compressible only to the extent your security function has capacity. The dependency is that it must complete before parallel run begins, not alongside it.

Which dependencies compress and which do not

The pattern worth noticing: the compressible dependencies are the technical ones. Migration plans that focus effort where effort helps and treat the rest as fixed lead times finish predictably. Plans that assume everything responds to resourcing overrun on the items that do not.

The phase model, defined by gates rather than weeks

Each phase should have entry and exit criteria. Duration is an output of the dependency profile, not an input to the plan.

Two gates deserve more attention than they usually get. Phase 3 exit is behavioural, not technical: the test is whether dispatchers trust the plans, and that cannot be certified by a test suite. Phase 4 entry requires a tested rollback path, which many programmes document and never exercise.

Integration architecture checklist: keeping WMS and ERP intact

The principle that prevents most migration damage is simple. ERP and WMS remain systems of record. The TMS becomes the system of execution. No data ownership moves, which means no upstream system needs to change to accommodate the migration.

Seven checks operationalise that:

System-of-record boundaries, written down. For every shared entity, order, location, carrier, rate, one system owns it and the others reference it. Ambiguity here is what produces divergent data six months post-cutover.

Flow direction per interface. Load release and inventory confirmation inbound from WMS or ERP. Dispatch confirmation, status, and proof of delivery outbound. Only allocation decisions and status acknowledgement need to be genuinely bidirectional.

A canonical data model. Carrier statuses, location identifiers, and order states normalised once at the boundary rather than mapped repeatedly per interface.

Event contracts, not just endpoints. Which events fire, with what payload, at what guaranteed delivery semantics. Event-driven integration with idempotent handlers survives replay; polling integrations silently lose state.

Master data alignment before migration, not during. Location identifiers and carrier records that do not match across ERP, WMS, and TMS produce reconciliation work that never ends.

Change data capture for reference data. Rates, service levels, and facility attributes change continuously and need a propagation mechanism rather than periodic re-imports.

Rollback definition per interface. What happens to in-flight messages if you revert, and whether the incumbent can accept status for shipments dispatched by the new system.

Also Read: TMS-WMS-ERP Integration Architecture for US Enterprises in 2026

What this looks like in deployment

The pattern above is not theoretical. A leading North American retailer ran freight across ocean, rail, DC, hub, and store on six disconnected systems. Locus was deployed as the decisioning layer alongside the existing ERP and WMS, which remained systems of record, replacing all six with one execution layer. Reported outcomes were 1 million dollars-plus in savings with break-even inside the first year, 99 percent-plus on-time store delivery, and an 80 percent-plus reduction in manual dispatch, from kick-off to go-live in six to nine months.

A leading ASEAN apparel retailer is the closer analogue for the sequencing question, because it migrated while its warehouse platform was also moving. The transport layer went live market by market alongside the retailer’s own WMS migration, with carrier statuses harmonised into one standard set and synced back to the retailer’s OMS and WMS. New-carrier activation fell from over three months to three days, which is the compounding benefit of getting the integration layer right during migration rather than after it.

Also Read: Why TMS Migrations Fail: 7 Architecture Mistakes That Kill Digital Transformation in 2026

The internal capability question is worth being honest about. Gartner found that 56 percent of chief supply chain officers cite integrating AI with legacy systems and processes as a major challenge, and 50 percent report limited internal expertise to implement and manage it. If the second applies to your organisation, the migration plan needs to name who does the integration work, because assuming internal capacity that does not exist is how phase 1 slips.

Learn more, visit locus.sh