TL;DR
- Continuous modernization has been Gartner’s recommended approach since 2018, and most enterprises still don’t run it that way. The idea was never the problem. Adoption was.
- The obstacle has always been economic. Project-based budgeting, headcount models, and go-live success metrics all work against a standing capability with no fixed end date.
- AI prices for a given level of coding performance fell roughly five to ten times a year through late 2025, and typical per-use pricing held steady over the same stretch. That combination is what makes a continuous operating model affordable to fund now.
- A continuous operating model changes governance, funding, and how “done” gets defined. How fast code ships is a smaller part of the shift than most CIOs expect.
- Governance maturity is a real prerequisite. Without disciplined funding and clear outcome metrics, a standing capability can mask scope creep as easily as it prevents it.
Continuous modernization is Gartner’s term for treating legacy modernization as a standing capability instead of a project with a start date and an end date. It is a lower-risk alternative to periodic, big-bang rewrites, an approach the firm has recommended since 2018 [1]. The idea has been correct for eight years. Almost nobody actually runs their organization this way.
This piece is about why that gap exists and what has actually changed. The obstacle was never the concept. It was how modernization gets funded, governed, and measured, and until recently, nothing changed the underlying economics enough to make the alternative affordable. Closing that gap requires looking at funding structure and AI unit economics as one connected story.
Gartner’s 2018 Recommendation Still Isn’t Standard Practice
Gartner’s original recommendation was straightforward. Rather than replacing legacy systems wholesale on a fixed cycle, an organization should modernize continuously, in small increments, capturing value along the way instead of waiting years for one large rewrite to land [1].
The gap between recommending this and actually doing it remains wide. In one industry survey, 95% of respondents called application modernization essential to their organization’s success. Only 18% had actually reached a continuous modernization stage [2]. That gap sits inside a broader pattern already visible across the state of enterprise legacy systems in the US, where the pace of aging systems keeps outrunning the pace of remediation.
The public conversation around the term hasn’t closed that gap either. Most content using the phrase either restates Gartner’s original framing without adding anything past it, or narrows the term into something much smaller. A common version reduces it to a feature that scans a codebase and automatically patches dependency issues inside a CI/CD pipeline. That is a real, useful capability, a tool. It doesn’t touch funding, governance, or how a team decides what “done” means, the actual components of an operating model. Neither version tells a CIO what to actually change about how modernization gets run, which is the gap the rest of this piece is written to close.
That repetition is itself informative. If the funding and governance mismatch behind continuous modernization were easy to resolve, whoever currently ranks for the term would already have resolved it and said so.
Project-Based Budgets Block Continuous Modernization
The obstacle was never technical. Project-based budgeting, headcount models built around a start date and an end date, and go-live success metrics all work against a capability meant to run indefinitely.
The CFO’s objection to that is a fair one. How do you fund something with no end date? A standing budget line with no accountability attached is exactly what a finance team is right to resist. A modernization program that never has to prove its worth against a defined goal tends to become one of those lines.
Technical debt is already blowing past what gets planned for it. In one 2025 industry survey, 49% of organizations said their actual legacy maintenance costs exceeded what they had budgeted for the year, and 86% said budget pressure was actively holding back innovation work [3]. That overrun happens whether or not a standing modernization budget exists. The difference is whether it happens by design or by accident, discovered mid-quarter when a roadmap commitment slips.
The scale involved is larger than a single balance-sheet line implies. Technical debt runs 21 to 40% of total IT spending industry-wide, and organizations that invest in closing that gap can recover more than half the value it currently traps within five years [4]. That is the number a CFO is actually weighing against the ask.
None of this is abstract to a CFO reviewing next year’s plan. A modernization line item competes directly against the same roadmap commitments the business has already promised the market, and losing that competition, year after year, is exactly what keeps continuous modernization theoretical.
A Different Funding Structure Resolves the CFO’s Objection
What resolves the CFO’s objection is a different funding structure:
- Fund the work against measurable outcomes, rate of decay avoided and capability delivered, instead of a flat percentage of IT spend carved out once and left alone.
- Put a standing steering group in place with finance represented directly, so accountability sits with the group from the start instead of surfacing only when engineering leadership reports up after the fact.
- Review it on a fixed cadence. Quarterly work gets reviewed against those outcomes, the same way any other standing business function already gets reviewed.
That structure also answers the sharper version of the objection, that continuous modernization just means never finished and always spending. Measured against decay avoided and capability delivered, spending stops being open-ended. It gets judged the same way any standing function gets judged, on results, on a fixed cadence.
This funding structure replaces one discipline, tracking a fixed scope against a fixed date, with a different one, tracking outcomes against a moving baseline. The second discipline is arguably the harder of the two to build well.
Across Legacyleap’s own modernization engagements, spanning both the code and data sides of a legacy estate, this exact funding and governance mismatch shows up directly, on both sides at once.
A $0 Modernization Assessment gives finance and engineering the same starting numbers, a technical debt baseline and a dependency map, before a standing modernization budget gets proposed rather than after it gets rejected, at no cost and from inside your own environment.
Falling AI Costs Made Continuous Modernization Affordable
Project-based batching made economic sense for a specific reason. When the AI-assisted portion of code comprehension and transformation work was expensive, bundling it into one large, fixed-scope program was the only way to spread that cost across a business case anyone could defend.
That cost has changed faster than most budgeting assumptions have caught up to. Research published in March 2026 tracked pricing across frontier AI benchmarks spanning coding, math, and reasoning tasks. The price for a given level of performance fell roughly five to ten times a year between 2024 and late 2025 [5].
The coding-specific slice of that data, drawn from SWE-bench Verified, a benchmark built from real-world software engineering tasks rather than toy problems, is thinner than the math and reasoning benchmarks. That means the exact multiple for coding alone carries real uncertainty. Directionally, though, the paper’s own authors are confident. Per-token prices for frontier-level work fell sharply across the board over this period.
| Metric | Trend | Period |
| Price for a given level of performance, frontier coding, math, and reasoning benchmarks | Fell roughly 5 to 10x per year | 2024 to late 2025 |
| Cost of running whichever model currently sits at the frontier, same benchmarks | Rose 3 to 18x per year | Same period |
| Average evaluation price on SWE-bench Verified specifically, across the full range of models tested | Held roughly flat | Same period |
Figures drawn from research tracking price and performance across frontier AI benchmarks, including SWE-bench Verified [5].
Ordinary Modernization Work Only Needs Solid Performance
The second and third rows matter for what this argument is not claiming. Squeezing out the last few points of accuracy at the very top of the leaderboard has gotten more expensive. Reaching that tier now takes far more reasoning compute per query, which is why the cost of running the frontier model rose sharply over the same period.
Ordinary code comprehension and transformation work, the kind continuous modernization actually runs on, does not need the very top of the leaderboard. It needs a solid, dependable level of model performance. On SWE-bench Verified specifically, average pricing across the full range of models tested stayed roughly flat through this same window [5].
Falling prices for a given quality bar, combined with flat average pricing for typical use, are what make routine modernization work affordable to run continuously, regardless of what it costs to chase the frontier.
That decline changes the calculus behind batching directly. Once the AI-assisted portion of comprehension, transformation, and validation work costs this much less per token, spreading it across one large program to justify the expense stops being the only rational choice available. Continuous, small-batch modernization becomes viable on its own economic terms.
That is an argument about unit economics. AI does not run modernization unsupervised. Human review still governs architectural decisions, release timing, and anything that changes product behavior. What got cheaper is the AI-assisted work underneath that review.
A Continuous Operating Model Changes Ownership, Funding, and “Done”
Ownership shifts first. A project has a sponsor who owns it until go-live. A standing capability needs the steering function described above to own it indefinitely, reviewing outcomes on a fixed cadence rather than closing out a project plan on a fixed date.
Work gets sized differently too. Instead of a quarterly program scoped around one release, work moves in small, constant batches sized against actual dependency pressure. Batches follow whichever part of the estate is decaying fastest, rather than whichever ticket happens to sit next in a queue.
In practice that might mean a batch scoped around a single decaying authentication library rather than a quarter-long consolidation project, sized by what is decaying fastest rather than by a release calendar.
That shift in ownership is why the funding structure from the previous section has to exist before this one works. A steering function with no budget authority is just a committee.
“Done” changes meaning along with it. A project is done when it ships. A standing capability is never done in that sense, and that is the point of running it this way. It gets measured by the rate of decay avoided and the capability delivered over a period, the same reframe that answers the funding objection above.
| Dimension | Project-based modernization | Continuous modernization as an operating model |
| Ownership | A project sponsor, until go-live | A standing steering function, ongoing |
| Funding | A one-time program budget | Outcome-tied funding, reviewed on a fixed cadence |
| Batch size | Quarterly or larger releases | Small, constant batches sized against dependency pressure |
| Definition of “done” | The release ships | Decay avoided and capability delivered, measured continuously |
Data Needs the Same Continuous Treatment as Code
The same funding and governance mismatch that stalled continuous code modernization applies just as directly to the data layer underneath it. Treating application code as the standing capability and leaving data as a separate, occasional cleanup project just relocates the original mismatch.
Data pipelines, schemas, and the business logic embedded in ETL jobs accumulate the same kind of debt as application code, on the same clock. The modernization of the data platforms feeding those applications has to run on the same standing basis, governed by the same steering function. A pipeline that silently drifts out of sync with the schema it feeds is exactly the kind of decay a continuous operating model is built to catch early. A once-a-year data migration project only discovers that same decay after the fact.
This is also where a genuinely incremental approach to modernizing legacy systems earns its keep. Small, continuous batches move across both code and data at once, rather than either side waiting on the other to finish a phase before starting its own.
Across Legacyleap’s own engagements, the same pattern holds. The batches that hold up best are the ones sized against dependency pressure on both the code and the data side at once.
A $0 Modernization Assessment maps both the application code and the data pipelines feeding it in one pass, so a standing modernization capability starts from one baseline instead of two disconnected ones, at no cost and from inside your own environment.
Continuous Modernization Requires Governance Maturity
A standing capability without disciplined governance can be just as risky as a big rewrite. It can mask scope creep exactly as easily as it prevents it. Work keeps happening, budget keeps moving, and nobody can point to what it actually bought this quarter.
The prerequisite is the same structure a fundable standing capability already needs: outcome-tied funding, a steering group with finance represented, and a fixed review cadence. Without those three in place first, a continuous operating model has no way to prove it is working, and no way to catch it early if it isn’t.
Building that maturity is itself a change management effort. It means engineering leaders reporting outcomes to a body that includes finance, on a cadence neither side previously had reason to keep.
A useful test for whether that prerequisite is actually in place is simple. Can the steering group name what decayed and what shipped last quarter, with numbers attached? If the honest answer is no, the capability exists on paper only, and adding AI-assisted throughput to an ungoverned process just moves the same problem faster.
None of that changes because AI is involved in the work. Human review still governs architecture, release decisions, and anything touching product behavior, and roughly 20 to 30% of the work in a well-run modernization program still runs through that review. Precision about what is and isn’t automated is what actually matters here.
Conclusion: Continuous Modernization Is a Funding and Governance Decision
Continuous modernization has been the correct approach since Gartner named it in 2018. It stayed rare because project-based budgeting, headcount models, and go-live metrics were never built to fund a capability with no end date.
That has changed. The AI-assisted work behind comprehension, transformation, and validation now costs a fraction of what it did two years ago. That is what makes a standing operating model affordable now, after eight years of being merely correct.
Funding and governance are the actual gate on continuous modernization. A team that gets those two things right has already done the hard part of this transition.
A $0 Modernization Assessment maps the technical debt baseline, the dependency structure, and the AI-readiness of both your code and your data, the starting point for a standing modernization operating model, at no cost and from inside your own environment.
FAQs
It’s a different claim than continuous delivery or DevOps, which describe how fast code ships. Continuous modernization describes how legacy risk gets funded and reduced as a standing function, independent of release cadence.
In practice, this usually means converting an existing episodic modernization budget into a standing line rather than creating a new budget category from nothing. Finance teams generally find that reframing easier to approve than a net-new ask.
Not if the governance holds. If a standing team can’t show measurable outcomes for two consecutive review cycles, the correct response is to defund or restructure it, the same way any underperforming standing function gets treated. The model has its own off-ramp built in.
Cost isn’t the only variable. A team still needs the funding and governance structure covered above before falling AI costs translate into a viable operating model. Cheap AI-assisted work poured into an unchanged, project-based budget just makes the old model cheaper.
It doesn’t require merging application and data teams into one org chart. It requires both teams reporting into the same steering function, funding structure, and review cadence, so decay on either side gets caught on the same cycle.
Few organizations build outcome-tied funding, a steering group, and a review cadence all at once. The realistic starting point is usually a single pilot domain, one application and the data behind it, run under the full structure for two or three review cycles before expanding estate-wide.
References
[1] CIO. Gartner Report: Use Continuous Modernization to Build Digital Platforms From Legacy Applications
[2] Red Hat. State of Application Modernization Report
[3] Ensono. 2025 State of IT Modernization Report
[4] Deloitte. The hidden drag, quantified: Technical debt’s penalty on value and growth
[5] Gundlach, Lynch, Mertens, and Thompson. The Price of Progress: Price-Performance and the Future of AI
