Replace a freight system by its customer connections, not its modules

Every few years a freight company decides that its transport management system has to go. The system is old, its original authors have retired, its hosting costs rise every year and it cannot do what the commercial team needs. A vendor is chosen, a programme is approved and a plan appears that looks like the vendor's product: order management in the first release, then planning, then proof of delivery, then billing, with a cut-over weekend at the end when everything moves at once.

I have come to think that this plan is organised around the wrong object. A transport system is not mainly a set of modules. It is a set of promises to customers, expressed through the connections by which they send bookings and receive status updates, proofs of delivery and invoices. Replace the modules and you have replaced software. Break a connection and you have broken a promise, usually on the day the customer is least inclined to forgive it. At Morrowgate we planned our replacement around those connections. It cost more and took longer, and I would do it the same way again.

The integrations are the system

When we started, three divisions ran on three platforms with 410 customer connections between them. Some were modern message exchanges. Some were overnight file transfers built by a contractor nobody could name. A dozen were spreadsheets that a customer's clerk emailed to a depot each evening and a depot clerk retyped. Each carried commercial meaning: which reference appeared on the invoice, which rate card applied, what counted as delivered, how a pallet exchange was recorded.

None of that was in the vendor's specification, because it was not in ours either. It lived in the connections and in the heads of the people who maintained them. So before configuring anything, we spent five months building a catalogue: every connection, its format, its volume, its owner on both sides, the contract terms that depended on it and what would happen to the customer's operation if it stopped. The catalogue was tedious, and it became the most valuable document in the programme. It found 54 connections that duplicated others and could be retired, and it identified 120 customers whose needs a single standard interface could meet instead of a bespoke one.

It also changed how we described progress. A module plan reports features delivered. Ours reported customers migrated and invoicing cleanly, which is the only measure a customer recognises.

Cohorts, not a cut-over weekend

We grouped customers into cohorts according to the connections they used and moved one cohort at a time, starting with interstate freight, where the oldest platform carried the most risk. Each cohort ran on both platforms until it had completed two clean billing cycles on the new one. Only then did we switch off its old connections.

The alternative, a single cut-over, had a respectable case. Our chief financial officer argued that a long migration would keep the business distracted for years and that paying for two platforms was waste. He was right about both costs. But a cut-over weekend concentrates every unknown into one night. If something fails across 410 connections at once, there is no smaller group to fall back to and no old system to run the next morning. In freight, where the trucks leave whether or not the invoice works, that failure lands on depots and customers before it reaches the programme office.

Cohorts do not remove failure. Our port wave, in August 2024, failed badly when the interface to the stevedores' vehicle booking systems stopped working at Brisbane for 52 hours, and our team booked 1,900 container movements by hand. But it was one division at one port, with the old platform still running behind it, and the affected customers were ones we could telephone individually. A failure of that size on a single cut-over weekend would have reached every customer we had.

What the parallel run really costs

I want to be precise about the price, because advocates of phased migration often understate it. Running two platforms for a cohort means double entry or a reconciliation layer, a project team that stays assembled for years, and hosting for the legacy system long after a cut-over plan would have retired it. In our case the cohort approach cost about A$11 million more than the cut-over plan, of which roughly A$8 million was two extra years of the legacy hosting contract. The programme cost A$72 million in total against A$64 million approved, mostly because of rework after the port wave.

It also cost features. Our commercial team wanted automated rate quoting for small shippers early in the programme, and it waited until the last cohort was complete. That delay had a commercial price, which the team estimated and I do not dispute.

What we bought was continuity. No customer missed an invoice run during the migration. Invoice disputes fell from 4.1 per cent of invoices to 1.5 per cent, mainly because the catalogue forced us to agree, customer by customer, what each reference and each charge meant. Connections fell to 236, which makes the next change cheaper for everyone involved.

There is a further benefit that took me longer to see. A cohort plan makes the programme answerable to the operating divisions rather than to its own milestones. Depot managers knew which of their customers would move and when, and they could tell us which week was a bad one. Several cohorts moved a fortnight later than planned because a depot was carrying a seasonal peak, and none of those delays cost us a customer.

For boards and executive committees approving a system replacement, I would suggest three questions. Does the plan describe progress in customers migrated or in modules delivered? How many customer connections exist, and who owns each one on the customer's side? And if the cut-over fails, what does the business run on the next morning? A programme that can answer those questions has understood what it is replacing. One that answers with a feature list is about to find out.