The Migration Trap: When the Replacement Can't Replace
Last week I wrote about why $31 billion in market value evaporated over a blog post about COBOL modernisation. The conclusion was that the market didn't panic because AI threatens legacy systems — it panicked because AI threatens the revenue model built on keeping those systems complex, opaque, and expensive.
This week, I want to show what actually happens when organisations attempt the modernisation that everyone is now debating. Not in theory. Not in a blog post. In reality — with real budgets, real teams, and real consequences.
There's a pattern I've watched repeat across critical infrastructure organisations for over three decades. The names change. The vendors change. The PowerPoint decks get better. The outcome doesn't.
An organisation runs its operations on a legacy platform. The platform works. It has worked for decades. It's not glamorous. It doesn't photograph well for annual reports. But when something breaks at 3 AM, someone knows how to fix it — usually in minutes.
Then someone decides the platform needs to be replaced.
Not because it stopped working. Because it stopped looking modern.
The promise
The business case for the new platform is always impeccable on paper. It promises everything the old one delivers, plus a list of attributes that read like a management consulting brochure: availability, resilience, agility, time-to-market, scalability.
Each attribute gets a letter. The letters form an acronym. The acronym gets a project name. The project name appears on slide decks, on budget requests, on org charts. It becomes a living entity with its own gravitational pull — attracting budget, headcount, and careers.
The premise goes unquestioned. The old platform costs tens of millions a year in licensing — a large, visible line item on the balance sheet. The new platform will eliminate that cost. This is the narrative. It's clean, it's compelling, and it's fundamentally incomplete.
Because the question that never gets adequate airtime is not "can we build a replacement?" It's "can we turn off what it replaces?"
The execution
The old architecture was simple by necessity. Two layers. A front-end that handled the interface. A back-end that handled the processing. Two systems. Known failure modes. A team that understood both.
The replacement was designed for a distributed world. Multiple layers, multiple services, multiple interfaces. This is architecturally defensible in theory. In practice, it means every function that previously existed in one place now exists across several, with communication protocols, latency, and failure domains between each.
The project scope expanded. Because the back-end ran batch processing that couldn't be replicated in the new architecture, a parallel sub-project was created — a "rehosting" initiative to handle the workloads the new platform couldn't absorb. One replacement project became two.
The budget grew. When the numbers were still tracked internally, the project had consumed more than ten times the annual cost of the platform it was supposed to eliminate. In a few years.
The headcount exploded. The original operation ran with a few hundred people. Within a short period, the organisation grew to several times that number — a combination of permanent hires and external consultants. The consultants, brought in to fill the competence gaps inherent in distributed systems, were offered conditions that many long-tenured internal staff could only observe from a distance. Cars. Fuel cards. Reserved parking. The symbolism was not lost on anyone.
And the old platform? Still running. Still processing. Still consuming the same licensing costs it always had. Because it turned out — as some people had said from the beginning — that you can't simply turn it off.
The arithmetic
Before the project, the organisation had two systems and a team that understood them.
After the project, the organisation has four systems: the original front-end, the original back-end, the new distributed platform, and the rehosting layer. None of them is optional. All of them require maintenance, licensing, and people.
The cost of the old platform didn't disappear. It was joined by the cost of the new one. The headcount didn't stabilise — it multiplied by six.
And here's the detail that cuts deepest: when a new function needs to be implemented on the old platform, it takes days. Corrections or improvements take minutes to a couple of hours. On the new platform — the one built for "time-to-market" — new functions take weeks to months. And when urgent corrections are needed, the new platform does what was never planned for in the original business case: it falls back to the old one. The system built to replace the legacy became dependent on it.
The promise was elimination. The result was multiplication.
The governance failure
If this were purely a technical miscalculation, it would be painful but forgivable. Complex migrations go wrong. Estimates are exceeded. Timelines slip. This is known.
What makes this pattern structural rather than incidental is what happened next.
The organisation's leadership changed. The new administration arrived from a different industry — telecommunications — and brought an entire management layer from that world. Positions that had been held by people with decades of domain knowledge were reassigned to people with loyalty to the new leadership but no understanding of the systems they were now responsible for.
The internal experts — the people who had built, maintained, and understood the infrastructure — were not fired. That would have been too visible. They were reassigned to operational roles where their expertise continued to keep things running, but where their voices no longer reached decision-making forums. They became, in effect, the engine room crew of a ship whose bridge officers had never sailed these waters.
Some raised concerns. Early in the project, there were meetings where technical and operational questions were put on the table — questions about feasibility, about fallback scenarios, about whether the fundamental premise of elimination was realistic. Those meetings were discontinued. Not because the questions were answered. Because the questions were inconvenient.
The best people left. Not because they were pushed — though some effectively were — but because skilled professionals don't remain in environments where competence is subordinated to political alignment. The organisation haemorrhaged institutional knowledge, one resignation at a time. Each departure made the remaining team more dependent on external consultants who had no institutional memory and no incentive to simplify.
Why it happens
This isn't a story about one organisation. It's a pattern that repeats wherever three conditions converge.
Condition 1: The cost is invisible to the decision-makers. In organisations where the budget comes from captive clients — entities that have no alternative provider — there is no market signal for failure. The cost of the migration is absorbed into operational charges that the clients must pay regardless. The decision-makers never face the consequence of their decisions in the form of lost business, because the business cannot leave.
Condition 2: Impunity is structural. When an organisation is owned by its own clients, and those clients are simultaneously shareholders, customers, and funding source, accountability becomes circular. The losses from a failed project are absorbed by the owners who are the clients who are the shareholders. It's a closed loop. No external body ever audits the delta between what was promised and what was delivered — because everybody at the table is simultaneously accountable and complicit.
Condition 3: The project serves careers, not operations. A legacy platform that works doesn't generate promotions. A transformation project worth hundreds of millions does. It creates positions, budgets, visibility, and narrative. "I led the modernisation of national infrastructure" is a career-defining line on a CV. "I maintained a platform that processed billions of transactions without incident" is not. The incentive structure rewards disruption even when continuity is what the operation needs.
These three conditions — invisible cost, structural impunity, and career-driven decisions — are the two variables from my previous newsletter (impunity and cheap money) applied to a specific domain. The migration trap isn't a technology problem. It's a governance problem wearing a technology costume.
The deeper pattern
What I've described is not a failure of modernisation. Modernisation is sometimes necessary, sometimes valuable, sometimes unavoidable. What I've described is what happens when modernisation is treated as an objective rather than a means — when the decision to migrate is made before the question of whether migration serves the operation.
The old platform had a characteristic that no distributed system can easily replicate: concentration. One system to understand. One team to maintain it. One throat to choke when something went wrong. This concentration was described as a weakness — a single point of failure, a vendor dependency, an architectural anachronism.
But concentration has a property that distribution lacks: accountability. When the system is in one place, the failures are in one place. The knowledge is in one place. The cost is in one place — visible, measurable, manageable.
Distribution disperses everything. The system becomes many systems. The failures become distributed across services, interfaces, and teams. The knowledge fragments across vendors, contractors, and consultants — each holding a piece, none holding the picture. And the cost disperses across budget lines, contracts, and SLAs until no single number captures the total.
The old platform was expensive. The replacement is more expensive. But the replacement's cost is spread across enough line items that no single report shows the full picture. This is not a bug. It's the feature that makes these projects politically survivable.
What would have worked
This is where I refuse to be the person who only diagnoses and never prescribes.
First: Honest assessment before commitment. "Can we actually turn off the old platform?" is the only question that matters in a replacement project. If the answer is "not for years" or "not completely," then the project isn't a replacement — it's an addition. Budget it as an addition. Staff it as an addition. Set expectations as an addition. The damage comes from the gap between what's promised (elimination) and what's delivered (multiplication).
Second: Technical validation of strategic decisions. No migration of critical infrastructure should proceed without sign-off from the people who operate the current system. Not as a courtesy — as a governance requirement. The people who maintain the engine are the only ones who know which parts can be replaced under load and which ones can't.
Third: Honest accounting. The total cost of the migration — including the ongoing cost of the platform it was supposed to replace — should be reported as a single figure, annually, to the governance body. Not distributed across budget lines. Not buried in operational charges. One number. Compared annually to the cost of the system it was meant to eliminate.
Fourth: Protect institutional knowledge. The people who know how the system works are not interchangeable with people who know how a different system works. Domain knowledge takes decades to build and months to lose. Any transformation that treats experienced operators as obstacles rather than assets is not modernising — it's amputating.
The takeaway
Every critical infrastructure organisation will face this decision eventually. The technology will age. The vendors will push upgrades. The consultants will present roadmaps. The board will want to see "transformation" in the strategic plan.
When that moment comes, the question to ask is not "what does the new platform promise?" It's "what happens if we can't turn off the old one?"
Because if the honest answer is "we'll have both," then you're not planning a migration. You're planning a multiplication — of systems, of cost, of complexity, and of the number of things that can go wrong at 3 AM.
And you'd better make sure the people who know how to fix things at 3 AM are still in the building when that happens.