For most of my career, legacy modernisation has followed a familiar economic logic. Replacing a core system or a data warehouse is expensive and risky, so organisations break the work into deliberate steps. They upgrade the existing platform to a supported version to buy time. They move one system at a time, build interfaces so that old and new can run side by side, and put each change through its own testing cycles before the next one starts. Upgrading in place is usually cheaper by a wide margin, which is why many estates are upgraded several times before they are replaced.
That logic has a long and respectable history. In the mid 1990s Brodie and Stonebraker named the two extremes: “Cold Turkey”, rewriting the system and switching over in one go, and “Chicken Little”, migrating incrementally through gateways and interfaces. Their case for the incremental approach, and Martin Fowler’s later Strangler Fig pattern, rested on sound reasoning. Each step should change as little as possible, because every change is costly to understand, make and test.
AI is changing the inputs to that reasoning. I have been using AI on data migration problems I have known for decades, and that work became Evorthon Data Harness, a software factory for migrating and building data platforms. In my new role I lead a lab that is putting this into practice, industrialising AI assisted data engineering across a large estate. The experience has led me to a conclusion that matters to anyone funding a modernisation programme: the cost of upgrading a legacy system and the cost of modernising it are now of the same order of magnitude.
Where the money goes in a transition step
A simple model helps. Each step in a programme carries two kinds of cost.
The first kind grows with the amount of logic being changed. Engineers read the existing code, work out what it does and why, rewrite or remediate it, and fix what breaks. Call it the variable cost. For a version upgrade it is modest: deprecated features, changed defaults and the occasional incompatibility. For a move to a new platform it has traditionally been very large, because every stored procedure, mapping and scheduled job has to be understood and rewritten.
The second kind is paid on every step, whatever its size. The team establishes what correct behaviour looks like, runs regression cycles, prepares environments, takes the change through governance, runs old and new in parallel, reconciles the results and manages the cutover. Call it the fixed cost of a step. An upgrade pays most of it, because the business needs the same assurance that every report still produces the same numbers after a version change as after a platform change.
Under the old economics, the variable cost of modernisation dominated. Suppose, for illustration, that an upgrade cost one unit and a modernisation of the same scope cost eight. Paying for the upgrade to stay in vendor support and deferring the modernisation was rational. So was splitting the modernisation into many small steps. Each extra step added a fixed cost and some temporary bridging code, and in return it kept the variable cost and the risk of each step small enough to manage.
AI compresses the variable cost
The variable cost consists mostly of reading, explaining and rewriting existing logic, which is the work AI accelerates most. A coworker with a suitable harness can read a legacy transformation, describe the behaviour it implements, find the business rules hidden in filters and joins, and draft the equivalent for the target platform. Questions it cannot settle go to the people who can answer them. Engineers still review and decide, but they start from an explanation and a candidate implementation, and far less of their time goes on archaeology.
The effect is uneven. The upgrade’s variable cost was already small, so it falls a little. The modernisation’s variable cost was large and made almost entirely of this kind of work, so it falls a lot. The fixed cost of a step barely moves unless verification itself changes. Both options converge on the same floor: the cost of proving that the result is correct and switching to it safely.
That is the sense in which an upgrade now costs about as much as a modernisation. The gap has not closed completely, and every estate has its own difficult corners. Once the prices are close, the question becomes what each option buys.
What the upgrade buys
An upgrade delivers no new business capability. The organisation pays to keep the system it already has, on a newer version, so that the vendor continues to support it. In effect it is a vendor tax, paid every few years for the right to stand still.
The legacy platform also keeps its running cost after the upgrade. Licences, scarce specialist skills, ageing infrastructure and the manual work around old processes all continue. In many organisations a large share of the technology budget goes on keeping existing systems running, and money spent there is not available for new capabilities. As the estate ages that share tends to grow, and the investment budget shrinks with it.
The larger cost is harder to see on a budget line. Fintechs and digital banks compete with seamless digital journeys and, increasingly, AI assisted service. An incumbent building a comparable offering on legacy platforms takes longer to deliver it. Every new product has to work through old interfaces, batch schedules, change processes designed for infrequent releases and data that is hard to find and trust. The cost of legacy includes the opportunity lost while new offerings wait.
When an upgrade cost a fraction of a modernisation, organisations could reasonably accept these costs for a few more years. With the two prices of the same order, the upgrade buys the existing system with its running cost and its drag on new offerings, for close to the money that would have paid for the move.
Fewer intermediate states
The same arithmetic applies to the chain of steps. A path through several intermediate architectures pays the fixed cost several times. Each intermediate state also needs bridging code, interfaces and reconciliations that are built, tested and eventually thrown away. While the variable cost dominated, those repeated costs were the price of keeping each step safe. Once the variable cost falls, they become the largest line in the plan.
The practical implication is to go directly to the target architecture wherever the business can accept it. An upgrade to stay in support, followed a few years later by a migration, is the clearest case of an intermediate state that existed to make the rewrite affordable. A lift and shift to new infrastructure followed by a separate refactor is another.
Small steps remain, and what they stage changes
Big bang cutovers remain a bad idea. The incremental approach was always about more than cost. Small steps deliver value earlier and limit the damage when something goes wrong. They also give the team a chance to learn and give the organisation time to absorb each change. Cutover is still the riskiest moment in any programme.
What changes is the unit of each step. The traditional approach staged the technology, one system, layer or version at a time. With the rewrite no longer the dominant cost, a step can be one consumer outcome, built directly on the target platform, verified against agreed evidence and switched over when that evidence is complete. A daily service report, a regulatory return, a customer statement run or a pricing feed can each move independently, carrying the conditions for retiring the processing it replaces.
This only works if verification becomes cheap as well. If every step still needs a long manual regression cycle, the fixed cost stays high and the pressure returns towards fewer, larger steps, with the risk that brings. Evorthon puts much of its weight on verification for this reason. It captures the inputs and expected outputs for agreed cases and compares a candidate against them each time the candidate changes. When results differ, it reports the earliest point where they diverge. A programme that can prove each step cheaply can afford many small steps of business value without paying for intermediate technology.
The constraint moves
In Goldratt’s terms, the constraint moves. For decades the bottleneck in modernisation was the engineering capacity to read and rewrite legacy logic. Once that capacity stops being scarce, throughput is limited by the work that stays with people. Business owners decide which existing behaviour to preserve, and specialists agree what counts as correct. Historical data migration, regulatory approval and operational readiness keep their own timelines.
A programme planned around the old constraint spends its money in the wrong places. It upgrades platforms it intends to leave and builds bridges it intends to remove. It also staffs for rewriting, when the scarce skills are now decision making and verification.
What a sponsor can do with this
The first decision affected is the next scheduled upgrade. Before approving it, cost the alternative of modernising the same scope with AI assisted delivery and automated verification. Compare the two on the same basis, including testing and cutover, and include what each option leaves behind: the running cost of the platform afterwards and the new offerings it can support. In many estates the difference will be much smaller than the old rule of thumb suggests.
The second decision is the shape of the plan. Some intermediate states exist to manage genuine risk, and some exist only because rewriting used to be expensive. Keep the first kind and remove the second.
These conclusions come from my own delivery work and the reasoning above, not from a measured comparison across a portfolio. The way to test them is also the way to start: take one bounded use case from a real programme, carry it to the target platform with verification evidence, and compare its cost with what an upgrade of the same scope would have taken.