Legacy systems in logistics: modernise or replace?

Modernise incrementally in almost every case. A logistics operation runs continuously, has no natural freeze window, and settles money against records created months earlier, so a big-bang replacement carries an outage and reconciliation risk that a rewrite rarely justifies. Replacement earns its place in two situations only: the vendor has withdrawn support, or the data model cannot represent how you now move freight.

What follows is a test you can run against your own transport management system this week, the three routes available once you have answered it, and the sequence that lets AI attach to the modernised edge in the first phase rather than the last.

Why a logistics rewrite fails more often than it succeeds

Three properties of logistics make replacement harder here than in most industries, and none of them are about code quality.

The first is that there is no quiet weekend. A retailer can cut over between seasons; a line-haul operator has trucks on the road at 3am on a Sunday, and a parcel network has a peak that lasts a quarter. The window for a hard cutover is measured in hours, and the rollback plan has to work inside it.

The second is that money settles against history. Freight rating, fuel surcharges, detention charges, cash-on-delivery remittance and partner payouts are all computed from records that predate the new system. A replacement must either migrate that history perfectly or run both systems until the old records age out, which is the modernisation path with extra steps.

The third is integration surface. A working logistics stack touches EDI feeds from shippers, courier partner APIs, telematics devices, a rating engine, a warehouse system, an accounting ledger and a handful of state portals. Every one of those is an interface a replacement has to rebuild before it can do anything useful, and each has undocumented behaviour that only production reveals. Integrating TMS, ERP and telematics with a new dispatch platform goes through what that surface really looks like.

None of this is an argument that the old system is fine. It is an argument that the cost of being wrong is asymmetric. A modernisation that stalls leaves you roughly where you started, with a working business and some new services. A replacement that stalls leaves you running two half-finished systems through peak season, with a team that has stopped maintaining the old one.

Replace, re-platform or strangle: a side-by-side

Three routes are genuinely available. Choosing between them is easier once the trade-offs are laid out against the things a logistics business actually cares about.

A five-question test for your transport stack

Most arguments about modernisation are really arguments about two different systems being described with one word. Separate the components before you decide, because the answer is often replace the driver client, wrap the core and leave the rating engine alone for another two years.

Answer these about the system you are arguing over. Three or more answers in the replacement column is the only honest case for a rewrite.

• Is the platform still supported? An unsupported runtime or a database version past end of life is a security decision, not an architecture preference, and it points to replacement of that component at least.
• Can the data model represent your current business? If multi-leg movements, part-truckload consolidation or a new marketplace channel have been forced into fields meant for something else, the model is the problem and refactoring around it will not help.
• Is there an API surface, or can one be added? A monolith with a stable database and clear transaction boundaries can be wrapped. Adding an API layer to a legacy monolith is usually weeks, not quarters.
• Does anyone understand the rating and settlement logic? If the answer is one person near retirement, write characterisation tests before touching anything, whichever route you choose.
• What does the licence and hosting cost per year? Replacement is easier to justify when the annual run cost approaches the cost of a rebuild, which happens with per-seat legacy transport suites more often than people expect.

How incremental modernisation actually runs in logistics

The pattern is the strangler fig, described by Martin Fowler as gradually creating a new system around the edges of the old one until the old system is strangled, and set out at martinfowler.com. In a logistics context it has a specific shape.

Build the read model before touching writes

Stream shipment, status and exception events out of the legacy system into a new store that has the data model you wish you had. Nothing changes for operations, but dashboards, customer tracking pages and AI features can now be built against clean data while the old system remains the system of record.

Put an anti-corruption layer between old and new

Every new service talks to the legacy system through one translation layer that converts its vocabulary into yours. When a legacy field turns out to mean three different things depending on consignment type, that knowledge lives in one place instead of spreading through the new code.

Pin behaviour with characterisation tests

Before any rating, surcharge or settlement logic moves, capture a year of real inputs and outputs and assert the new code reproduces them exactly. Characterisation tests are the reason a phased move does not quietly change what a customer is billed.

Run in parallel, then switch one flow at a time

New and old compute the same result for weeks while only the old one is acted on. Differences are investigated, not explained away. Switching happens per lane, per client or per branch, with an immediate route back.

Where AI connects in the first phase

The argument for modernisation over replacement is strongest here. Once the event stream and read model exist, useful AI does not have to wait for the platform. Exception triage can read the stream and classify delays, missed pickups and address failures with a recommended action. Customer update messaging can generate from clean status data. A natural language query layer over the read model lets operations ask about lane performance without a report request. None of that requires the legacy system to change.

The same order applies to the field. An offline-first driver app can be rebuilt independently of the core, because proof of delivery arrives through the new layer rather than the old client. Dispatch logic is a separate question covered in Route optimisation vs dispatch rules.

When replacement really is the right call

Two situations justify it, and pretending otherwise wastes years. The first is an unsupported stack with no upgrade path, where continuing to run it is a security and insurance problem. The second is a data model that genuinely cannot express the business, which usually shows up as a proliferation of spreadsheets outside the system doing the work the system should do.

There is also an honest middle case. If your legacy system is a small operational tool rather than a settlement system of record, replacing it outright can be cheaper than wrapping it. Incremental modernisation is a risk management technique, and where there is little risk it is overhead. The general argument is laid out in Application modernization vs rewrite.

Cost, timeline and what we would quote

A Legacy-to-AI Modernization programme starts at $31,500 or ₹22.4 lakh and runs to $105,000 or ₹72 lakh and beyond, depending on how many capabilities move. Where the work is mostly building the replacement operational platform around a retained core, Custom ERP and CRM development starts at $28,000 or ₹18.4 lakh. Before either, a ten-day Sprint Zero at $3,250 or ₹2,00,000, credited to the build, produces the capability map, the strangling order and the cutover plan. Full starting prices sit on the pricing page.

Most first phases we run in logistics and field services take eight to sixteen weeks to a live capability. After go-live a Care Plan from $1,000 or ₹68,000 per month covers patching, monitoring and the on-call rota that a phased estate needs while two systems coexist.

A worked example

A last-mile operator came to us with dispatch inside an ageing core and drivers on paper. Rather than replacing the core, we built the dispatch platform and driver app around it, with the legacy system continuing to own billing while the new layer owned assignment and proof of delivery. The dispatch platform and field apps case study describes what moved and what deliberately did not. A parallel example outside logistics, where a fifteen-year-old system was modernised without a rewrite, is the university ERP programme.

Related reading

The strangler pattern explains the technique in general terms, Embedding AI into legacy systems without a rewrite covers the attachment points, and Compliance and data rules for AI in logistics covers what the new layer must log. Our wider logistics and field services page sets out where we normally start.

In logistics the question is rarely whether the old system deserves to die; it is whether you can afford the night on which it does.