Lumen Freight had tried to replace their scheduling mainframe twice. Both attempts were big-bang rewrites. Both were cancelled — the first after fourteen months, the second after nine — at a combined cost of around $14M.
We replaced it in eighteen months without a cutover weekend, without a feature freeze, and without a single customer-visible scheduling incident. The pattern is not novel. The discipline required to actually follow it is where the difficulty lives.
Why big-bang rewrites fail here
The failure mode is not technical. It is that a rewrite must reach feature parity with twenty years of accumulated behaviour before it can deliver any value at all, and nobody knows what that behaviour is.
The business rules live in COBOL written by people who retired. There is no specification. There is a system that works, and an organisation that has quietly reshaped itself around its quirks. Any rewrite is therefore a reverse-engineering project wearing a greenfield costume, and its schedule is a guess about how much you do not yet know.
Step one: find out what it does
Before we wrote a line of replacement code we spent seven weeks extracting business rules from the mainframe into an executable specification.
The output was 1,840 rules, each with a test and each reviewed by an operations lead. Roughly 300 of them surprised the operations directors. Around forty turned out to be bugs that the business had adapted to and now depended on.
That document was the single most valuable artefact of the engagement, and we delivered it before any migration began. If the project had been cancelled that week, the client would still have come out ahead.
Step two: the facade goes in first
On day one — before any behaviour moved — all traffic was routed through a facade.
This is the step teams are tempted to skip, because on the day you install it the facade does nothing except add a hop. Its value is entirely in what it makes possible later: from that point on, migrating a bounded context means changing a routing rule, and rolling back means changing it back.
Rollback that takes seconds rather than a database restore changes the political character of the whole project. It is why nobody had to approve a "migration weekend", and why the appetite for risk stayed high through eighteen months.
Step three: contexts in dependency order, alone
Nine bounded contexts. Each fully in production before the next started.
We began with rating, because it was the most isolated and the least frightening. Scheduling — the core, the thing the mainframe was named for — went last, by which point the pattern had been executed eight times and had stopped being interesting.
The temptation to parallelise is enormous, particularly around month ten when the pace feels slow and someone runs the arithmetic on doing three at once. Resist it. Two contexts in flight means that when the reconciliation drifts, you have two candidate causes and no way to isolate them.
Step four: parallel run, and mean it
Every context ran alongside the mainframe for at least three weeks. Both received the same input. An automated comparator checked the outputs and alerted on any divergence.
The first context diverged on 3.4% of records. Almost all of it was date handling around a timezone edge the specification had captured incorrectly. We would not have found that in testing — it needed real traffic, at real volume, over a real month boundary.
By the ninth context, first-run divergence was under 0.1%. The team had learned the shape of the legacy system's weirdness, which is knowledge you can only buy this way.
The part that is genuinely hard
None of the above is intellectually difficult. What is difficult is holding the line for eighteen months while people ask reasonable questions.
Why is this taking so long? Why can we not do two at once? We are 80% done — can we not just cut over the rest? Each of those is asked in good faith by someone under real pressure, and each of them, accepted, converts the project back into the big-bang rewrite that failed twice already.
The answer we gave, every time, was the same: we are not going faster, we are going without a rollback plan. Then we showed them the reconciliation dashboard.
Was it worth it?
Eighteen months and a team of seventeen is not cheap. But it is cheaper than $14M of cancelled projects, and considerably cheaper than the third failure.
More to the point: value shipped every fortnight throughout. By month six, three contexts were live and the operations team had already stopped using two mainframe screens. That continuous delivery of something is what keeps a modernisation programme funded — and funding, not architecture, is what usually kills them.