The Legacy Modernization Decision Canadian CIOs Keep Deferring
Industry benchmarks place legacy maintenance at 60 to 80 percent of total IT spend across enterprise portfolios, consistent across Gartner, Forrester, and Deloitte research. A 2025 GAO report on US federal IT spending found that 79 percent of a $105 billion annual IT budget was allocated to operations and maintenance of legacy systems. The US is an outlier in scale but not in pattern. Canadian enterprises in financial services, insurance, healthcare, and energy follow the same trajectory: a growing share of the IT budget maintaining systems that were built for an earlier era, leaving a shrinking share available for the investment the current era requires.
Legacy maintenance costs do not hold steady. Legacyleap's April 2026 analysis of enterprise portfolio maintenance costs found they compound at 10 to 20 percent annually across four converging forces: hardware components become scarcer and more expensive after warranty expiration, the talent pool of developers with legacy expertise shrinks as specialists retire, third-party vendor support contracts escalate as vendors sunset legacy product lines, and each year of deferred modernization adds technical debt that makes the eventual migration more complex and costly.
The decision to defer legacy modernization is rarely made explicitly. It is made implicitly, repeatedly, in annual planning cycles where the modernization investment is displaced by the more urgent priorities that accumulate around any organization operating complex technology. The deferral feels rational each time it is made. The compounding cost of repeated deferral becomes visible only when the maintenance budget has grown to a level that can no longer be justified against the business value the legacy systems provide, or when an AI program, a regulatory requirement, or an integration need makes the limitation of the legacy architecture undeniable and immediate.
This post provides the decision framework that makes the modernization question answerable before it becomes undeniable, because the organizations that make deliberate modernization decisions on their own timeline consistently produce better outcomes than those whose timeline is set by a crisis.
Why the Decision Keeps Being Deferred
The legacy modernization decision is deferred not because CIOs and technology leaders do not understand the cost of deferral. Most do. It is deferred because the cost of deferral is distributed across time and categories in ways that make it less visible than the cost of action, which is concentrated and immediate.
The maintenance invoice arrives monthly. Its year-over-year increase is incremental enough to be absorbed in the IT budget without triggering a decision. The opportunity cost of what the maintenance budget cannot fund does not appear on any invoice. The integration debt accumulated in custom workarounds built to connect the legacy system to modern SaaS tools represents $20,000 to $60,000 in annual developer time per system, according to tkxel's 2026 TCO analysis, but appears in the staffing budget rather than the legacy system budget. The security exposure of running unsupported software appears in the risk register rather than the IT budget. The AI program that cannot be built because the legacy system cannot connect to modern data pipelines appears in the AI program's failure retrospective rather than in the legacy system's cost accounting.
Changepond's research identified the specific cognitive pattern: many businesses reach a tipping point where maintaining legacy systems costs more than modernizing them, yet continue deferring because modernization costs feel more visible than maintenance costs. The modernization investment is a discrete, visible capital request. The maintenance cost is ambient and unchallenged. Until someone does the full cost accounting, the comparison is between a visible new cost and an invisible existing one, and the visible new cost consistently loses.
The decision framework that makes the modernization question answerable requires making the invisible costs visible, comparing the full cost of continued maintenance against the full cost of modernization, and applying a strategic filter that distinguishes between systems whose modernization produces strategic capability and systems whose modernization produces only cost reduction.
The True Cost of Maintenance
Building the full cost of legacy maintenance requires going beyond the maintenance invoice to include the six cost categories that consistently go unaccounted for in legacy system budgets.
Direct maintenance costs are the most visible: vendor support contracts, internal maintenance staff, and the ongoing patching and configuration work required to keep the system running. For systems approaching or past vendor end-of-support, the direct maintenance cost frequently includes extended support agreements that carry premium pricing, or the cost of maintaining internal expertise to support a system the vendor will no longer patch.
Integration debt represents the ongoing cost of custom workarounds built to connect legacy systems to the modern SaaS tools, data platforms, and AI systems that the organization has added around them. These workarounds require maintenance every time the connected system changes, and their fragility creates operational risk that is difficult to quantify until a workaround fails in production. The $20,000 to $60,000 annual per-system estimate is conservative for complex enterprise integrations.
Talent scarcity costs reflect the market reality that the developer population with expertise in COBOL, RPG, and other legacy languages is shrinking as specialists retire and the pipeline of new developers with these skills is negligible. The organizations still running mainframe or legacy midrange systems are competing for a shrinking talent pool, and the compensation premium for legacy expertise has increased materially as supply has contracted.
Security exposure costs represent the risk of running systems that are no longer receiving security patches, or that were designed before modern security principles were established and cannot be retrofitted to meet current standards. A single breach involving an unpatched legacy system can exceed the entire modernization budget in incident response, regulatory penalty, and reputational cost. This cost is probabilistic rather than certain, which makes it easy to exclude from cost comparisons, but its expected value, the probability multiplied by the cost if it occurs, belongs in any honest total cost of ownership calculation.
Opportunity cost represents the programs and capabilities that cannot be built because the legacy architecture is the constraint. The AI program that requires real-time data that the legacy batch processing architecture cannot provide. The customer experience improvement that requires API access to data that the legacy system holds but cannot expose. The regulatory reporting requirement that requires data lineage documentation that the legacy system was not designed to produce. These costs appear in the failed or constrained program budgets rather than the legacy system budget, but they are directly caused by the deferral of the modernization decision.
Developer productivity loss represents the overhead that legacy system constraints impose on the engineering team: the time spent on manual processes that a modern system would automate, the workarounds built around system limitations, and the cognitive overhead of maintaining expertise in systems whose complexity was accumulated over decades without the documentation and architectural clarity that modern systems maintain.
The Modernization Strategy Decision
Once the full cost comparison is built, the next decision is which modernization strategy is appropriate for each system. The six standard strategies, applied to different systems based on their business criticality, technical complexity, and strategic importance, are not equally appropriate for all situations.
| Strategy | What It Means | Best Fit | Risk Level |
|---|---|---|---|
| Encapsulation | Wrap legacy functionality with modern APIs, exposing it to modern systems without changing the core | Systems with stable core logic but poor integration capability; buying time for replacement | Low: preserves existing logic, limited scope |
| Rehosting | Migrate the application to cloud infrastructure without changing the code | Data centre exits, hardware end-of-life; does not address technical debt but reduces infrastructure cost | Low to medium: limited functional change, infrastructure complexity |
| Replatforming | Move to a modern platform with targeted code changes to take advantage of platform capabilities | Systems where the architecture is sound but the platform is the constraint | Medium: requires code changes, testing complexity |
| Refactoring | Restructure the code to improve maintainability, performance, or scalability without changing external behaviour | Systems with business logic worth preserving but technical debt making maintenance expensive | Medium: code changes required, regression risk |
| Rebuilding | Rewrite the system from scratch using modern architecture and technology | Systems where the existing code is too complex or poorly documented to refactor; high strategic importance | High: full replacement scope, longest timeline |
| Replacing | Retire the legacy system and implement a commercial or SaaS replacement | Commodity functions well served by market solutions; organization does not need differentiated capability in this area | Medium to high: organizational change, data migration, integration complexity |
The Thoughtworks 2026 observation is essential guidance for rebuilding decisions: modernization is rarely about preserving the past in a new syntax. Blind code conversion would risk recreating the same system with the same limitations in a different language. The rebuilding decision requires understanding what the legacy system does at the functional level, which capabilities need to be preserved, and which constraints of the legacy design should be eliminated in the rebuild. That understanding is the systems analysis work that precedes rebuilding decisions, and it is consistently underestimated in modernization program scoping.
What AI Has Changed About the Decision
AI-assisted modernization tools have materially changed the cost and timeline mathematics of legacy modernization in 2025 and 2026. Mobisoft's April 2026 structured review of 73 legacy application modernization projects found that AI-assisted approaches reduced code discovery and analysis time significantly compared to traditional methods, and that the payback window for projects that were previously borderline has shortened to the point where the financial argument for action is difficult to ignore.
The specific changes that AI assistance produces in the modernization economics are in the code discovery and documentation phase, which has historically been among the most expensive and uncertain components of any legacy modernization program. Legacy systems whose documentation was lost decades ago and whose developers have long since retired can now be analyzed systematically by AI tools that read the code, map the business logic, identify dependencies, and produce documentation of what the system actually does that would have required months of manual analysis to produce. That analysis was previously the primary risk factor that made modernization programs difficult to scope and price accurately. The AI-assisted analysis produces a more reliable current-state baseline in less time, which reduces the contingency that responsible modernization programs need to carry for discovery risk.
Red Hat's October 2025 launch of AI-powered tools integrated with its Migration Toolkit for Applications, specifically designed to accelerate legacy codebase modernization, and the broader ecosystem of AI-assisted code analysis and transformation tools that have matured in 2025 and 2026, mean that the modernization decision is being made in a cost and capability environment that is materially more favourable than it was two years ago. Organizations that were unable to make the financial case for modernization in 2023 should revisit the analysis with current cost and tooling assumptions, because the conclusion may have changed.
The Portfolio Sequencing Decision
Most organizations have more legacy systems requiring modernization than they can address simultaneously. The sequencing decision, which systems to modernize in what order, is as important as the strategy decision for each individual system, because the sequencing determines what becomes possible in the next phase and how the total cost of the modernization program is distributed across budget cycles.
The sequencing framework that produces the most strategic value prioritizes systems on three dimensions: the degree to which the system constrains other strategic programs, the urgency of the maintenance cost trajectory, and the risk of the modernization itself. Systems that are blocking AI programs, open banking integrations, or regulatory compliance initiatives should be prioritized over systems whose limitations, while real, are not blocking strategic progress. Systems whose maintenance cost is compounding fastest, typically those approaching or past vendor end-of-support, should be addressed before those with more stable maintenance trajectories. Systems where the modernization risk is manageable with current tooling and current team capability should be sequenced before those where the risk is higher and the team needs to build capability first.
The application portfolio rationalization framework described in this series provides the analytical foundation for this sequencing decision. Combined with the full cost of maintenance analysis described above, it produces a modernization roadmap that is grounded in financial reality, strategic priority, and risk management rather than in the technical preferences of the architecture team or the political dynamics of which systems have the loudest advocates.
Talk to Us
ClarityArc helps Canadian organizations build full cost of maintenance analyses for legacy portfolios, select the right modernization strategy for each system, and develop sequencing roadmaps that connect modernization investment to the strategic programs it enables. If your organization is deferring the legacy modernization decision and wants a structured approach to making it, we are ready to help.
Get in Touch