Every legacy modernization business case we are asked to review has roughly the same shape. There is a current-state infrastructure cost, a projected future-state infrastructure cost, and a line labeled savings connecting the two. The program gets approved on that delta.
Two years later the delta has largely materialized. The infrastructure bill is genuinely lower. And nobody is especially happy, because shipping a change still takes a quarter and the business cannot tell what it got.
The reason is that infrastructure was never the expensive part.
The number everyone models
Run cost is easy to model because it arrives as an invoice. Compute, storage, network, licenses, floor space. You can point at it, finance understands it, and it fits neatly in a spreadsheet.
On a typical enterprise estate that has been running for ten or fifteen years, that invoice is a modest fraction of what the estate actually costs the business each year. Modernization programs routinely optimize that fraction very effectively and leave the rest exactly where it was.
The number that actually moves
The dominant term is the cost of change: what it takes to get a new capability from decision to production. Break it into parts and it becomes concrete.
There is lead time — the elapsed weeks between someone deciding to do something and a customer seeing it. There is change failure and rework — the proportion of changes that break something and the effort spent recovering. There is the coordination tax — the release train, the four teams who must all move together, the six weeks of manual regression testing that everything queues behind. There is the capacity tax — the share of your engineering budget spent keeping the estate upright rather than adding anything to it. And there is the opportunity cost of every capability the business decided not to ask for because it knew what the answer would be.
When a change that should take a week takes a quarter, the cost is not the extra engineering hours. It is the three months the business spent without the capability, and the initiatives that were never proposed because the estate made them uneconomic.
Two organizations can have identical infrastructure bills and wildly different cost of change. One ships weekly. The other ships four times a year and spends the interval regression testing. Only one of them has a modernization problem, and the invoice will not tell you which.
Why lift-and-shift disappoints
Rehosting moves a workload without changing its architecture. It captures a portion of the infrastructure savings and almost none of the cost-of-change savings, because everything that made change slow — the coupling, the missing tests, the undocumented behavior, the shared database that eleven services write to — moved along with it.
This is not an argument against rehosting. There are excellent reasons to do it: a data center lease expiring, hardware reaching end of life, a regulatory deadline, an acquisition that has to be integrated by a date. Rehost is a perfectly good answer to "we have to be out by March."
It is not an answer to "we cannot ship fast enough." The failure happens when a program is funded on the second promise and sequenced for the first.
Sequencing by cost of change
Most portfolios get sequenced by technical age or by ease of migration. Both are proxies for the wrong thing.
Sequence instead by which components most constrain delivery. There is a straightforward way to find them. Take the last eighteen to twenty-four months of significant changes — features, regulatory work, integrations, whatever counted as a project. For each one, list the components that had to be touched. Then count.
The components appearing in the most changes are your actual constraint, regardless of how old they are. Run this and the results are frequently uncomfortable: the oldest system in the estate turns out to be fine. It is stable, boring, well understood, and nobody has needed to change it in three years. Meanwhile a five-year-old service that everything routes through is in every single change list, and it is the reason nothing moves.
Modernizing the old stable thing produces an impressive slide and no change in delivery speed. Modernizing the bottleneck is unglamorous and moves the number that matters.
What to put in the business case instead
Lead time for change, baselined before the program starts and tracked through it. Change failure rate. Engineering capacity reclaimed from maintenance and redirected to new capability. Time to first value for each wave, so that the program produces something usable early rather than at the end.
Infrastructure savings still belong in the model. They just belong as a secondary line, where they are a pleasant consequence rather than the whole argument.
This is a harder case to write. It requires baselining things most organizations do not currently measure, and it requires committing to numbers that will be visible if the program does not deliver. That is precisely why it is the case worth writing: it is measuring the thing the program was actually meant to fix.
If the only number in your modernization business case is infrastructure spend, you are not making a modernization case. You are making a hosting case — and there are far cheaper ways to win that argument.