Estimated reading time: 11 minutes
Every organization running legacy systems must make one decision for each: retain, isolate, modernize, or replace. That choice directs capital over the coming years, sets where teams focus effort, and determines how much risk the operation carries through the transition.
Each path carries a different cost:
- Retaining a system that already limits the operation defers the investment and shifts the cost to the next incident;
- Isolating without defining clear boundaries can simply move the complexity into other parts of the architecture;
- Modernizing legacy without measuring dependencies and coupling raises the risk of discovering the full scope only after the project has started;
- Replacing a system that still does its job consumes capital without creating competitive advantage.
This article turns that decision into measurable criteria. It shows which indicators point toward retaining, isolating, modernizing or replacing each system, and how to record the choice so it guides investment, execution and governance.
Which metrics reveal the debt inside a legacy system
Assessing a legacy system takes more than an impression of obsolescence. A system is not legacy merely because its language has aged, the original team has left, or documentation is missing.
The weight of legacy can be measured by operational data: the cost and frequency of production incidents, the time to put a new feature live, and the rework rate from structural failures. Another indicator is how much the operation depends on a few people’s knowledge. When that knowledge stays concentrated, one person’s absence can stall the operation.
The difference in perception shows up in the data. The 2025 Architecture in Software Development report, independent research commissioned by vFunction, surveyed 629 technology leaders and practitioners across the United States and the United Kingdom. Among executive leaders, 52% say architecture documentation matches what runs in production. Among engineering and architecture practitioners, that number drops to 36%. Whoever decides about the system may be working from a different picture than whoever handles it day to day.
That alone does not mean the system is unstable or expensive to run. Technological age and technical debt are different things. Age is neutral. Technical debt matters when it raises cost, slows delivery, or increases operational risk.
For that reason the decision has to start with metrics, not perception. The data usually already exists in the environment: in continuous integration (CI) tooling, incident records, and cost allocation.
| Category | What to measure | Where the data already lives |
|---|---|---|
| Delivery | Measures such as deployment frequency, change lead time, recovery from failed deployments, change failure rate, and rework rate form DORA’s five key software delivery metrics. Data sources include CI pipelines and release records. | CI pipeline and release records |
| Reliability | Assessed by system availability relative to SLOs, MTTR, and incident metrics such as volume and severity. Tools include incident tooling and an SLO dashboard. | Incident tooling and SLO dashboard |
| Structural risk | Evaluates the blast radius (extent of system impact if one component fails), the number of integrations, knowledge concentration (bus factor), out-of-support components, and known CVEs. Data is gathered from dependency maps and version inventories. | Dependency map and version inventory |
| Economics | Compares annual operational costs with evolution costs, including licensing, infrastructure, and specialized personnel. Data includes infrastructure and team allocation. | Infrastructure allocation and team allocation |
The turning point occurs when debt begins to hinder delivery capacity. Without explicit complaints, a poorly performing system naturally slows the business.
Choosing the right approach for each legacy system profile
A common mistake is to frame the decision as simply refactoring or rewriting. Isolation should be considered a genuine option, as it is the most commonly chosen in practice.
- Retain: Keep operating with no evolution investment. Suited to a stable, commoditized system with low running cost and no demand for change.
- Isolate: Encapsulate the system behind an interface with an integration contract, limits and monitoring, and integrate through it from then on. Fits high-value systems exposed in risky ways, with a large blast radius to contain. Established patterns for this include encapsulation, the Strangler Fig Pattern and an anti-corruption layer.
- Modernize: Evolve in stages, through refactoring, replatforming, or adopting a new architecture for parts of the system, while preserving the operations. This is the choice for a system that sustains revenue and needs to change frequently.
- Replace: Build or buy a new system and switch off the current one. Justified when legacy blocks a critical capability the business needs to offer and no incremental evolution delivers that result.
The ordering rule is simple: choose the lowest-risk path that solves the problem. Replacement tends to concentrate more execution and transition risk, which is why it should normally be considered after the incremental alternatives.
For the extreme case there is an objective threshold, proposed by McKinsey in a study of 50 CIOs in financial services and technology (2020).
When an area’s technical debt exceeds 50% of the value of its technology asset, the risk and cost of the current systems begin to outweigh the benefit, and building a new stack enters the discussion.
Tech debt: Reclaiming tech equity
The same study recommends avoiding the big-bang approach, because IT megaprojects concentrate execution risk and freeze the ability to compete while they run.
How to read the numbers and choose between isolating and replacing
| Predominant reading | Indicated path |
|---|---|
| Stable delivery metrics, low cost, no demand for change | Retain |
| High value, large blast radius, need to integrate without rewriting | Isolate, starting with the most critical interfaces |
| Revenue dependent on the system, high lead time, frequent changes required | Modernize in stages |
| Blocked business capability, no incremental path, out-of-support components | Replace, with a transition plan and parallel running |
| Debt above half the value of the area’s asset | Assess a new stack, phased and without a big-bang |
| Bus factor of one, no runbook | Treat the risk before the architecture: runbook, knowledge redundancy and monitoring |
When one specialist and no runbook are all that remain, operational risk outweighs any argument about code quality. That risk belongs in the price of the decision.
Signals that the modernization is paying off
Each path has a success signal and a failure signal. Tracking both keeps the choice from becoming an endless project.
| Path | Success signal | Failure signal |
|---|---|---|
| Retain | Keeps the system inexpensive, stable, and free of attributed incidents | A critical vulnerability remains unfixable |
| Isolate | Enables new integrations without affecting the core system | The isolation layer becomes a second, maintenance-intensive system |
| Modernize | DORA metrics improve with each update | Migration stalls, leaving the company to operate two systems indefinitely |
| Replace | The new system handles all traffic seamlessly without downtime | Scope expands, deadlines slip, and no rollback option is available |
Why AI agents change the urgency of modernization
The decision regarding legacy systems predates the rise of agentic AI. What has changed is the rising cost of delaying modernization.
The common expectation is the opposite. In the same survey, 65% believe that AI-accelerated development will simplify their architecture. However, the report argues that rapid code generation without proper architectural decisions can increase fragmentation.
When an agent reads from and writes to a system, it inherits all underlying issues: undocumented dependencies, fragile interfaces, and silent failures, all at high speed and scale.
A knowledgeable human can work around system quirks and adapt. In contrast, an agent operating on brittle interfaces or implicit behaviors tends to worsen these issues: it might fail, execute unexpected sequences, or produce results that are hard to audit.
Gartner reports that integrating agents with legacy systems is often technically complex, causing workflow disruptions and costly modifications (June 2025). Many agentic projects never reach production, as documented in How to scale AI agents in banking.
The following conditions suggest that a system can handle agent exposure with manageable risk:
- Using explicit, versioned interfaces with a clear integration contract and no direct database access.
- Employing machine-to-machine identity with short-lived credentials and minimal privileges.
- Critical operations are idempotent or protected by an idempotency key.
- Well-defined transactional boundaries prevent the system from ending up in an inconsistent state.
- Sufficient logs, metrics, and tracing for auditing and reversing agent actions.
- Data that is accessible, with established governance and classification.
- Fast credential revocation procedures with an agreed time frame.
Systems that fail to meet these criteria should be isolated before being exposed. The Model Context Protocol specification warns that tools exposed to agents could execute arbitrary code and emphasizes the need for consent and control when invoking such tools. Encapsulating legacy systems without proper contracts, authorization, operational limits, and audit trails merely shifts risk to a new layer.
The identity and integration layer that these agents traverse is discussed in Agentic Enterprise: identity and integration with AI agents.
The cost of modernizing after the agent goes into production
| Path | Scope of work | What stops | Evidence required |
|---|---|---|---|
| Prioritize isolating the interface | Create a single integration layer with a clear contract and boundaries | No production activity | Coupling map of the system |
| Pause production activities | Rework architecture with the agent already integrated | The agentic initiative and related flows | Incident investigation aligned with a regulator’s timeline |
The first path consumes planning time. The second consumes execution budget, leadership attention and the team’s confidence in the roadmap.
How to document the architecture decision for audits
To withstand an audit, an architecture decision must record the assessed system, the analysis metrics and date, the chosen path, and the responsible person. Without this history, discussions become cyclical, as each new budget cycle revives the same opinions without new data to advance the project.
Companies that treat technical debt as a strategic concern adopt a practice McKinsey advocates: linking each application to its operating costs and strategic goals. They then formally record decisions to invest in, retain, or retire each asset.
Frequently asked questions
Isolation involves wrapping the system with an interface and integrating through it without changing the core. Modernization involves gradually evolving the system through refactoring, replatforming, or architectural updates. Isolation limits risk; modernization alters the system.
The five DORA metrics for delivery, SLO achievement and MTTR for reliability, blast radius and bus factor for structural risk, and a comparison of running costs to evolution costs for economics. Age alone isn’t indicative.
Not necessarily. Age is neutral; what matters is whether technical debt impacts delivery speed, reliability, structural risk, or costs.
McKinsey suggests that when technical debt exceeds 50% of a system’s value, the risks and costs outweigh benefits. They recommend phased transitions rather than abrupt changes.
Because the AI inherits the dependencies and failure modes of the underlying system. Gartner notes that integrating AI often requires costly modifications and can disrupt workflows. Delaying this decision increases implementation costs.
A strategic conversation is essential for your challenge
TreeID’s Application Modernization team conducts an architecture review, maps dependencies, and assesses operational risks based on incident history. We document the decision pathway, assign ownership and criteria, and define the agentic project scope before any work begins.
Sources
- vFunction. “2025 Architecture in Software Development Report: Rethinking the Role of Architecture”. 2025. Independent research commissioned by vFunction, surveying 629 technology leaders and practitioners (315 U.S., 314 U.K.).
- McKinsey & Company. “Tech debt: Reclaiming tech equity”. October 2020. July 2020 survey of 50 CIOs at financial services and technology companies with revenue above US$1 billion. Cited here for the decision threshold and the recommendation against a big bang, both of which remain reference practice.
- Model Context Protocol. “Specification”. Official protocol documentation, 2026.
- Gartner. “Gartner Predicts Over 40% of Agentic AI Projects Will Be Canceled by End of 2027”. June 2025.
- Google Cloud. DORA, the DevOps Research and Assessment program.