Most of Your Legacy Estate Should Be Left Alone

← All posts

The most valuable page in a portfolio assessment is the list of systems you decided not to touch, and almost nobody writes it.

A regional insurer we’ll call Northmark assessed 214 applications and came out with a three-year modernization roadmap covering 61 of them. Eighteen months later they had finished four. One was a Delphi desktop tool used by eleven people in the reinsurance team, which had received two change requests since 2019. It took seven months and a little over a million euros to replace, and the eleven people preferred the old one.

Meanwhile the policy administration platform, which absorbed every regulatory change the business received and had three people left who understood the rating tables, was scheduled for year three.

That is the failure this post is about, and we are a modernization firm saying it. The hard part of portfolio work is not deciding how to modernize. It is deciding what, and what not to. Every system you modernize without a reason is one you could not modernize that had one.

Here is the claim you can disagree with. Age is not a defect. A stable system that runs cheaply, meets its obligations and receives almost no change requests is an asset, and rewriting it converts a known quantity into an unknown one at a cost you will underestimate.

The Deloitte 2026 Global Technology Leadership Study puts technical debt at 21% to 40% of IT spending, midpoint around 30%. That number is real and large, which is precisely why the remediation budget cannot be sprayed evenly across the estate. Roughly 60% to 80% of IT budgets goes to maintaining what already exists, and that is the pool every modernization proposal fights over. Spend it on the wrong twenty systems and you have burned three years without reducing risk.

Why rate of change beats technology age as a triage variable

Most portfolio triage tools sort on technology age. They ingest an inventory, tag each application with its runtime and version, and produce a heat map where anything past some threshold glows red. Easy to build, easy to demo, and measuring the wrong thing.

The cost of legacy technology is not incurred when the system runs. It is incurred when the system changes. An unmaintainable codebase nobody needs to modify imposes almost no cost. The same codebase under a stream of regulatory amendments imposes an enormous one. The axis that matters is not how old is it, it is how often must someone change it, and how expensive is each change.

Plot the estate on those two axes and the four quadrants carry different instructions.

High change demand, high change difficulty. Where your money should go, nearly all of it. A policy administration system taking twelve regulatory and product changes a year, each needing a scarce specialist and a nine-week test cycle, bleeds continuously and you can measure it in the change budget. These justify rearchitecture, occasionally rebuild.

High change demand, low change difficulty. Leave it alone. Frequent, cheap changes are the definition of a healthy application regardless of what it is written in. Well-factored COBOL with a good regression suite and three people who know it belongs here. Teams modernize these because they are visible and active, confusing activity with pain.

Low change demand, high change difficulty. Over-modernized and under-analysed. Difficulty is real but latent, so it costs nothing today. The questions are about the future: will change demand stay low, and can you survive the exception when it arrives? Encapsulate, document, remove the single-person dependency, revisit annually. Do not rebuild.

Low change demand, low change difficulty. Retain, or check whether anyone still uses it. A meaningful share of this quadrant is retirement candidates nobody has confirmed.

The measurement that makes this real

Change demand is not a feeling, it is a query: 24 months of change records, incidents that produced a code change, and release history per application. Few organizations have run it, and the result surprises people. The systems everyone complains about in architecture forums are often not the ones absorbing the work.

Change difficulty is measurable by proxy: median lead time from request to production, how many people can safely make the change, test cycle duration, and change failure rate. Four numbers, all sitting in your ticketing and deployment tooling. Run both and your triage reflects cost rather than the estate’s emotional temperature.

The nine dispositions and what disqualifies each

The familiar list of Rs is a taxonomy, and taxonomies are the least useful part of this work. The value is in the disqualifiers, because the common failure is not missing an option nobody thought of, it is picking one that was never available. Relative cost is indexed against a rehost of the same system, as a planning rule of thumb rather than a benchmark.

Explicit disqualifiers for rebuild

Rebuild is the disposition most often chosen for the wrong reasons. Do not rebuild if any of these is true.

1. The requirements exist only in the code. Without a behavioural specification independent of the implementation, the rebuild has no acceptance criteria, only an oracle you reverse-engineer under deadline pressure.
2. The legacy system will keep receiving mandatory changes during the build. The single most reliable predictor of failure, covered below.
3. You cannot run both systems in parallel and compare outputs. Without comparison testing you rely on tests written by people who did not know what the old system did.
4. The business sponsor changes more often than every eighteen months. A four-year rebuild needs sponsorship continuity most organizations cannot supply.
5. The stated reason is the technology rather than the behaviour. “It’s COBOL” is not a requirement. “The product structure cannot represent bundled policies” is.

If two or more apply, you are not planning a rebuild. You are planning a rewrite that gets cancelled in year three and quietly recorded as a platform investment.

Encapsulation is often the terminal state, not a way station

The industry treats encapsulation as a holding pattern. Wrap the legacy system in an API, integrate against the facade, replace what is behind it later. Later frequently never comes, and the interesting question is whether that is a failure.

Often it is not. A clean API over a stable core can be the permanent right answer, and treating it as permanent from day one produces a better facade. Scaffolding gets no owner, no SLA and no design review. Permanent infrastructure gets all three.

What makes encapsulation durable

• The domain is stable in shape, not just in volume. A general ledger posting engine works this way. The rules change; the concept of a posting does not.
• Change demand is low and can be shown to be low from records.
• The runtime is supportable over a defined horizon. z/OS is supported and will be for a long time. Windows Server 2012 running an unpatched framework is a different situation.
• The contract speaks the consumer’s domain language, not the legacy system’s. This is the part teams skip. If your API exposes CUST-STAT-CD and a nine-character policy key with embedded meaning, you have published the legacy model to every consumer and made replacement harder, not easier.

What makes it a trap

• An unpatchable runtime. No facade design fixes a CVE in an EOL application server. Encapsulation manages coupling, not vulnerability.
• An EOL vendor stack with no upgrade path. PowerBuilder against an unsupported Oracle release does not become safe because there is REST in front of it.
• A bus factor of one. A facade lets you defer learning the system, which feels like progress and is the opposite.
• A leaky contract. Every consumer coupled to legacy semantics through the facade adds cost to the eventual replacement.

The honest test: write down the support horizon of everything behind the facade and the date you will revisit it. If you cannot, it is a way station and you should say so.

The retire quadrant, which everyone skips

Ask for the disposition mix from any portfolio assessment and count the retires. In most it is under 5% of applications. Where usage has actually been measured, the true figure is usually higher. Systems stay alive not because they are needed but because nobody has confirmed they can be switched off, and confirming that is unglamorous work with no architecture diagram attached.

This is the highest-return activity in the portfolio. The return is immediate (licences, infrastructure, support contracts, patch cycles, audit scope, access recertification) and the risk is bounded, because the failure mode is “turn it back on.” Compare that to a rearchitecture, where the return arrives in year four and the failure mode is a program review.

The retirement playbook

1. Instrument before you ask. Connection, authentication and query-level logging for a full business cycle. A quarter is the minimum; anything with annual processing needs a year, and you should say so rather than guess.
2. Separate humans from machines, then trace the machines. A system with zero human logins and one nightly service account is a data feed, not an application. Every service account belongs to something, and the ones you cannot trace are why dark periods exist.
3. Run a communication campaign with a deadline. Publish the intent to retire, the date and the owner, and require objections in writing with a business justification. Silence is not consent, but anonymous objections are not evidence either.
4. Take the dark period. Switch the system off for a defined window, a long weekend or a fortnight for low-frequency systems, with monitoring in place and a rollback that takes minutes rather than a change request. Agree who to call and how to restore before you start. If the objection is theoretical, extend the window: “someone might need it at year end” is answered by going dark across year end, not by cancelling.
5. Archive to satisfy retention, not to preserve the system. Obligations under SOX, GDPR, HIPAA or sector rules apply to the data and its readability, not the application. An extracted, queryable archive with a schema description and a retention clock satisfies an auditor. Keeping a running instance “for compliance” is usually a decision nobody has re-examined since making it.
6. Decommission for real. Reclaim infrastructure, cancel licences, remove firewall rules, close audit scope, delete service accounts, update the register. A system switched off but still costing money and appearing in scope has not been retired.

One logistics operator found 30 of 190 applications had no human user in six months. Twenty-two came off in a year. The saved run cost funded the assessment several times over, and bought the credibility for a harder conversation about the two systems that actually mattered.

Why rewrites underestimate: the moving-target problem

Brooks named the second-system effect in 1975 and it has not aged. The usual summary, that rewrites take longer than you think, hides the actual asymmetry.

The incumbent system’s requirements are undocumented but complete. Thirty years of edge cases, regulatory amendments, correction routines and workarounds for a partner’s malformed file format are all encoded, all working, and none of them written down.

The rewrite’s requirements are documented but incomplete. Beautifully specified, and the subset someone was able to articulate. The gap between those two sets is not a rounding error. It is most of the difficulty, and it is invisible at estimation time, which is why the estimate looks reasonable to everyone in the room.

The moving target is what kills programs

Here is the pattern that turns a difficult rebuild into a failed one. You start a three-year rebuild of a system that receives mandatory external changes: DORA resilience requirements, a tax rule change, PCI DSS 4.0 controls, a regulator’s new reporting schema.

Those changes do not pause. They must land in the legacy system, because that is what is in production and the deadline is statutory. So every change is implemented twice, and the second implementation is against a target that is not yet complete and cannot be tested against production traffic. The rewrite team spends a rising share of capacity chasing parity instead of building.

The arithmetic is unkind. If mandatory change takes 25% of the rewrite team’s capacity and the rebuild was scoped at three years, you are now at four, during which more mandatory change arrives. Programs cross a threshold where the parity backlog grows faster than it clears, and after that the completion date is no longer a date. It is a direction.

The defences are limited: freeze legacy scope to statutory-only changes in writing, cut the rebuild into slices that go live in under twelve months each, or choose a different disposition. A system under heavy mandatory change is usually a rearchitecture candidate, changed in place, where every change lands once.

A weighted scoring model you can actually run

Scoring models get dismissed as theatre, usually because they were built to produce an answer someone already had. A model earns its place when it makes disagreement explicit: two people arguing about a dimension score is more productive than two people arguing about a disposition.

Seven dimensions, weighted. Change demand carries the most weight, deliberately, because it is the variable most triage tools ignore.

Business criticality carries the lowest weight on purpose, and this is where people push back. Criticality is not a reason to modernize. It argues both ways at once: the system matters, so fix it, and the system matters, so do not break it. Its real function is as an execution-risk multiplier on the disposition you choose, not a driver of the choice. Weight it high and the model simply ranks your most important systems, which you already knew.

Score bands and their dispositions

Weighted score on a 1.00–5.00 scale.

• Below 2.20. Retain, or investigate for retirement. Nothing here justifies spend.
• 2.20–2.80. Retain with documentation and knowledge remediation, or retire. Confirm usage first.
• 2.80–3.40. Encapsulate, rehost or replatform. Reduce risk without touching logic.
• 3.40–4.20. Replatform, refactor or rearchitect. Real investment, staged.
• Above 4.20. Rearchitect or replace. Only here does rebuild enter the conversation, and only after the five disqualifiers.

Two override rules sit above the bands, because a weighted average dilutes a single fatal condition. Any internet-facing system on an unsupported runtime moves to immediate action regardless of score, as does any system scoring 5 on both technology risk and knowledge risk, where you are one resignation away from an unmodifiable production system.

Worked example: six systems in a composite insurer

Northmark again, across a representative slice. Weights as above.

The reasoning matters more than the arithmetic.

Policy administration is the only unambiguous investment: high change demand meeting high difficulty across a wide integration surface, under regulatory pressure. It scores highest despite running on the best-supported platform in the list. z/OS is not the problem. The coupling and the change volume are.

The reserving mart is a pure runtime problem. SQL Server 2012 is out of extended support and the logic is fine. Replatform, touch the SSIS packages only as far as the version change forces, and resist the offer to “modernize the pipeline while we’re in there.”

The commission engine is the instructive one. Change demand is 2, so on a change-based view alone it would be a retain. It scores 3.23 because technology risk and knowledge risk are both 5, triggering the second override rule: one developer, an unsupported database, a build environment that exists on a single machine. It costs you nothing today. It could stop being changeable at all with two weeks’ notice.

Correspondence and print is the encapsulation case. The domain is stable, RPG on the AS/400 works, and the fan-out is the pain. Build a document generation API in the consumers’ language and it stays where it is indefinitely, reviewed annually.

The broker extranet shows why the model informs rather than decides. It scores 2.35, inside the retain-or-retire band, but the first override applies: internet-facing on a framework in extended support. Telemetry found 40 active brokers, all with accounts on the main portal, which does everything the extranet does apart from one report. Build the report, migrate the users, switch it off. Six weeks of work removing an attack surface and a DORA headache.

The ceding calculator is the system Northmark actually rebuilt in the story at the top of this post. It scores 2.03: two changes in six years, eleven users, negligible run cost, no regulatory exposure. The correct disposition was to document it, train a second person, set a review date and walk away. The million euros belonged to the extranet retirement and the first slice of the policy platform.

Sequencing the register once you have one

Triage produces a ranked list. The ranking is not the sequence, and treating it as one loses programs in their first year.

1. Start with a retirement. Small, provable, complete inside a quarter. It builds the decommissioning muscle every incremental program later fails at, and produces a number the CFO can verify. Credibility is a budget input.
2. Then run one full cycle end to end. One system, all the way: assess, change, cut over, migrate consumers, decommission, reclaim cost, update the register. A mid-sized one where success is likely and the learning transfers. Scale up before completing a cycle and you discover your decommission capability is theoretical at the worst moment.
3. Reserve capacity for what will be forced on you. Within 24 months an external deadline lands: a vendor EOL date, a data centre exit, a regulatory window, a partner deprecating an interface. Commit 100% of capacity to the ranked list and every forced item arrives as a crisis. Hold back 20% to 30%.
4. Then the top of the ranked list, staged so each stage has independent value. If stage one delivers nothing usable alone, it gets cancelled when the sponsor changes.

The answer to “what first” is almost never the biggest system, because you cannot yet execute at that scale, and almost never the worst, because the worst system is worst for reasons that will defeat an inexperienced program.

A disposition is a decision with a review date

Every entry is a judgement made against conditions that will change. Retain is not a verdict of permanence. It says that under current change demand, support status and staffing, action is not justified, reviewed on a date by a named person.

Run an annual review and re-score every application, not just the interesting ones, because the point is to catch the ones that moved quietly. Between reviews, these triggers force an off-cycle re-score:

• A vendor end-of-life announcement. Technology risk moves to 5 the day the announcement lands, not the day support ends.
• The departure or retirement notice of a named expert. Knowledge risk is the fastest-moving dimension in the model, and the only one that can change in an afternoon.
• An acquisition or divestment. Duplicate systems arrive, retirement candidates appear, integration fan-out changes shape.
• A regulatory change in the system’s domain. Change demand and regulatory exposure both move.
• A step change in transaction volume. A system fine at 40,000 transactions a day may not be at 400,000, and the constraint surfaces as an incident rather than an analysis.

The register needs a named owner per system, a person rather than a team, plus the current score with its date, the disposition, the review date and the last measured change demand. If it lives in a slide deck it is not a register.

When “retain” is really avoidance

Everything above can be misused, and it will be. “Retain” is the easiest disposition to hide behind, because until you look at the evidence, doing nothing is indistinguishable from deciding to do nothing.

Five tells that separate a genuine retain from institutional inertia.

1. No expiry. A genuine retain has a review date and a named owner. Avoidance has neither, and nobody can say when the decision was last examined.
2. Nobody can state the support horizon. If the team cannot give you the end-of-support date for the runtime, database and middleware, they have not assessed the system. They have deferred it.
3. The change-demand number is a memory. “It hardly ever changes” is an impression. The query against 24 months of change records is a fact, and the two disagree more often than not.
4. Bus factor is assumed, not measured. Ask who else can make a production change, then ask when that person last did. A second name who has not touched it in four years is not a second name.
5. No cost is attached. A retain decision with no run-cost figure has not weighed anything. You cannot call a system cheap to keep if nobody has calculated what it costs.

The inverse abuse is worth naming too: modernization proposed as a hiring and retention strategy. It is an honest problem, since engineers do not want to spend a career in Oracle Forms, but said plainly it can be debated, and disguised as a risk case it corrupts the register.

Frequently Asked Questions

Does leaving systems alone not accumulate more technical debt?

Debt accrues interest when you transact. A system that does not change accrues little beyond platform risk, a separate and directly measurable concern managed through patching and support horizons. The Deloitte 2026 figure of 21% to 40% of IT spending consumed by technical debt is a portfolio-level average of wildly different situations. Debt concentrates in the systems under change pressure, so paying it down uniformly underfunds the places where interest compounds and spends real money where it does not.

How do we know change demand will stay low?

You do not, and the framework does not require certainty. It requires a review date and a trigger list. Change demand rises for identifiable reasons: a regulatory programme, a new product line, a business model shift, a partner integration. Those appear in the business plan two or three quarters before they hit the backlog, which is enough warning to change disposition before the cost lands. What you cannot do is predict once, at assessment time, and treat that answer as permanent.

Is encapsulation not just deferring the problem at higher cost?

Sometimes. The question is what sits behind the facade. Encapsulating a stable domain on a supported runtime with a clean, consumer-language contract is a durable architecture many organizations run for a decade. Encapsulating an unpatchable runtime is deferral with extra infrastructure, because a facade addresses coupling and does nothing about vulnerability or vendor abandonment. If the support horizon behind it is short or unknown, you are deferring. If it is long and the contract does not leak legacy semantics, you are architecting.

What if the business insists on rebuilding a system we scored as retain?

Ask for the requirements source. Not the business case, the requirements: where do acceptance criteria come from if not the existing code, and who adjudicates a behavioural difference found in parallel run. If the answer is “we’ll work it out during discovery,” you have a rewrite without an oracle. Then ask what mandatory changes the incumbent will receive during the build window, and who implements them twice. Those two questions settle most of these arguments, because they surface the disqualifiers in terms the sponsor already understands.

The Bottom Line

What your organization needs from a portfolio assessment is not a roadmap covering 61 systems. It is a defensible decision for every system, most of them retain, encapsulate or retire, plus a small ranked set that justifies investment.

Sort on rate of change, not technology age. Give change demand more weight than business criticality. Treat encapsulation as a legitimate end state where the runtime supports it, and retirement as the highest-return work in the portfolio. Apply the rebuild disqualifiers before anyone falls in love with a target architecture. Put a review date on every decision.

The reason to be disciplined is not that modernization does not work. It is that the budget is finite and the debt is real. Every system you modernize without justification is one you could not modernize that needed it, and that trade-off is being made in your portfolio right now whether or not anyone has written it down.

If you are heading into a planning cycle with a modernization list longer than your budget, a structured triage usually shortens it considerably, and the systems that survive the cut are the ones worth defending. Modernize Software runs portfolio triage workshops that score an estate against the model above and produce a disposition register with owners, review dates and an explicit do-not-touch list. Happy to walk your architecture team through the scoring model before you commit a euro to a build.