A finance director at a midsize insurer once described her company’s old claims platform as held together by duct tape and a prayer. The phrase stuck, mostly because everyone in the room had heard some version of it before. Engineers tend to blame the code. The vendor takes the heat from executives. Almost nobody questions the spreadsheet that justified spending eleven million dollars to fix it. That spreadsheet, more often than the platform itself, is where the trouble actually starts.
Somewhere in most large IT budgets sits a single number, the expected return arriving in year 3 or year 4, that justifies everything downstream of it. Most companies build an application modernization strategy around that one figure, dressed up in slide decks and approved by committee. That kind of plan for updating an aging application portfolio rarely survives contact with reality, because the math behind it was wrong before a single line of code changed.
A Familiar Eulogy for the Wrong Patient
Legacy systems make an easy villain. They are slow, brittle, expensive to staff, and visibly old enough to mock at a town hall meeting. COBOL mainframes from the 1980s really do struggle to talk to a modern API layer, and the developers who understand them are retiring faster than anyone is training replacements. But blaming the system for a stalled rebuild is a little like blaming a 1973 station wagon for a road trip that never had enough gas money budgeted.
80% of the federal government’s IT budget goes toward operating and maintaining systems that already exist, leaving a thin sliver for the work of replacing any of it. That imbalance is not a coding problem. It is an allocation problem, repeated at every level of government and, less visibly, inside private companies that never bothered to measure it the same way.
Private budgets tend to hide the same imbalance behind tidier language, and the modernization strategy on paper often looks nothing like the actual spending pattern underneath it. A company might call its legacy spend “run” and its new work “change,” track both loosely, and never ask why run keeps eating into change’s share year after year. McKinsey’s analysis of corporate technology budgets found that the organizations getting the most value from their spending direct roughly a third of it toward change work, while the rest let legacy upkeep crowd out nearly everything else. The gap between those two groups has less to do with engineering talent and more to do with discipline in how the books get kept.
Where the Numbers Quietly Lie
Ask an engineering team to price out a migration, and they will produce a number. Ask whether that number assumes the cutover happens on schedule, with no parallel-run period, no data-mapping surprises, and full staff adoption on day one, and the room tends to go quiet. Naive ROI models treat implementation as a foregone conclusion. Real migrations rarely cooperate.
A handful of costs get left off the spreadsheet almost every time, and each one is large enough on its own to flip a project from profitable to underwater:
- Parallel operations, the stretch where the old and new systems both need monitoring, support, and reconciliation at once.
- Integration rework, the interface fixes, and data-mapping defects that only surface once real traffic hits the new architecture.
- Specialist staffing, the contractors brought in because nobody left on the team remembers how the old system actually works.
None of these show up on a clean payback chart. All of them show up on the first invoice after go-live. Old system, new system, both fully staffed. All running at once, for longer than anyone planned.
There is no shortcut around this. Execution risk is the discount nobody wants to apply, the haircut that turns a tidy 15% return into something closer to six. A defensible case applies it anyway, and separates the must-have work, security patching, vendor end-of-life, regulatory gaps, from the nice-to-have refactoring that can wait a budget cycle. It also resists rolling every benefit into one optimistic percentage, because finance teams have learned to distrust numbers that arrive that clean. Building that kind of strategy for modernizing legacy applications takes longer at the front end and saves a fair amount of embarrassment at the back end.
What a Believable Case Actually Looks Like
Most modernization proposals present return as a single aggregate figure landing somewhere between three and five years out. That projection might even be accurate. It is also unfundable, because the executive sponsor who approved it has usually moved teams or companies by the time anyone can check the math. A sturdier structure breaks the timeline into early wins inside the first six months, a break-even point around eighteen to twenty-four months, and a profitability stretch beyond that, with each horizon answering to its own metrics and its own audience.
7 in 10 executives believe customer expectations are outpacing their organizations’ ability to keep pace, and a brittle legacy system is frequently the reason. A checkout flow that times out, a support agent who cannot see a customer’s full history, a claims process that takes 6 extra clicks more than it should, none of these are abstract inconveniences. They show up as churn, and churn is a number a CFO already tracks closely.
Firms that work in this space, N-iX among them, have started building proposals around exactly this kind of layered accounting: hard savings in one column, revenue protection in another, risk avoidance in a third. The approach is not flashy. It sits closer to bookkeeping than to vision-setting, and that is precisely its appeal to a board that has been burned before.
By the time a credible application modernization strategy reaches the board, the uncomfortable numbers are already on the page, not buried in an appendix nobody reads.
Conclusion
The legacy system was never an innocent bystander, but it was rarely the actual cause of failure either. Bad code can be rewritten in months. A modernization case built on borrowed optimism takes years to unwind, often after the budget and the patience for a second attempt have both run out. Fix the math first. The code will still be waiting, and it will be far cheaper to fix once the spreadsheet finally tells the truth.