Modernization Sequencing: Which Systems to Modernize First When AI Changes the Cost Curve

For most of the last decade, sequencing barely mattered. Budget was the constraint, and it was tight enough that only one or two modernization efforts ever got funded in a given year. The question was rarely “what should we do first.” It was “what can we afford to do at all.”

AI has broken that constraint. McKinsey’s research has documented gen AI-driven modernization cutting costs tied to technology debt by roughly 40 percent and accelerating timelines by 40 to 50 percent, turning projects that once ran well past $100 million into ones costing less than half that. When five systems become affordable instead of one, sequencing stops being a formality and becomes the actual strategic decision. Get it wrong, and Gartner’s own research suggests the odds aren’t in your favor: the firm expects more than 70 percent of mainframe migrations started this year to fail, driven largely by underestimating what a modernization effort actually requires once cost stops being the limiting factor.

When budget was the binding constraint, the organization’s attention, integration capacity, and appetite for business change were rarely tested, because so little was happening at once. AI removes the budget ceiling but doesn’t remove those other constraints. An enterprise that could previously fund one modernization program a year can now afford three or four simultaneously, but running three or four at once multiplies the integration dependencies, the change management load, and the number of things that can go wrong together.

Gartner VP Analyst Matt Brasier’s framing of legacy modernization as an unsolved business problem rather than an unsolved technical problem applies directly here. The questions he says CIOs actually need to answer, what it will cost, how much organizational change it requires, and whether it’s worth it, get harder to answer well the more initiatives are running in parallel. Sequencing is what keeps those questions answerable.

The two most common default approaches to sequencing are both weak ones. Starting with whatever’s cheapest or fastest to show a visible win optimizes for an early press release, not for value. Starting with whatever system is oldest assumes age correlates with business impact, which it frequently doesn’t.

McKinsey’s research offers a better anchor: as many as 80 percent of successful interventions in a struggling digital transformation are based on re-anchoring the scope around a well-defined business domain, an end-to-end process, rather than an individual application or use case. The unit of sequencing should be a business domain, not a technical asset. A ten-year-old customer onboarding system sitting in the middle of a high-value domain deserves to be sequenced ahead of a thirty-year-old batch job that nobody outside IT ever notices.

The most useful recent data on sequencing doesn’t come from a modernization vendor. It comes from a March 2026 Deloitte model comparing two levers enterprises pull when addressing technical debt: infrastructure modernization and data transformation. The finding that matters for sequencing is that these two levers pay off on completely different timelines.

Infrastructure modernization, cloud migration, microservices, modern architecture, reduces technical debt in a fairly linear, front-loaded way: about 10 percent in year one, reaching 18 percent cumulative by year five in Deloitte’s model. Data transformation looks nearly invisible by comparison in year one, producing only a marginal difference against an average organization. But it compounds sharply from there, reaching a 52.5 percent reduction in “latent,” or trapped, technology value by year five as data-driven capability scales across the business.

That gap has a direct sequencing implication. If the near-term goal is a visible, defensible reduction in technical debt, infrastructure modernization delivers it first. If the goal is unlocking the largest pool of value sitting inside an existing tech estate, data foundation work needs to start early even though its payoff won’t be visible for two or three years, because the compounding effect only begins once that foundation exists. Deloitte’s own conclusion is blunt: most organizations can’t “AI their way out” of technical debt. Infrastructure modernization and a real data strategy both have to happen, and which one goes first depends on which gap is actually larger in a given estate, not on which one is easier to fund this quarter.

Four factors, scored together rather than in isolation, produce a more defensible sequence than any single-variable ranking.

Score by value at stake first. eBay’s platform modernization is a useful reference point: the company prioritized addressing legacy infrastructure specifically because it was causing payment and checkout latency that measurably hurt the customer experience, not because the system happened to be old. The modernization produced a 100 percent improvement in buyer satisfaction scores, a result tied directly to which problem was chosen, not just how well it was executed.

Score by risk and resiliency exposure next. Systems concentrated with compliance obligations, or ones a business depends on for continuous operation, carry a cost of delay that a simple ROI calculation misses. A system processing a small transaction volume but sitting inside a regulated workflow can outrank a much larger system that just runs slow.

Score by reuse potential. McKinsey’s research on scaling data products found that a product built to serve five use cases carried roughly 30 percent lower projected cost than building five separate pipelines, and about 40 percent lower cost once that same product scaled to a second market. Systems whose modernization creates a reusable platform component for the next three systems in the queue should move earlier in the sequence, because every system that follows gets cheaper as a result.

Score by technical readiness last, but don’t skip it. A high-value system with poor documentation and no meaningful test coverage needs a reverse-engineering phase before it can be safely modernized, which changes its effective timeline even if it scores well on value. This is the same principle that separates working mainframe modernization programs from failed ones: understanding what a system actually does before rebuilding it.

Reverse engineering isn’t just an execution step in this framework, it’s also where the evidence for sequencing decisions comes from. In one case, reverse-engineering a system properly, rather than assuming its priority from its age, surfaced $12 million in hidden technical debt in just four weeks, a number that materially changed how that system ranked against others competing for the same modernization budget. Sequencing decisions made before that kind of discovery work are sequencing decisions made on incomplete information.