Everything engineering and transformation leaders need to know in 2026 – from choosing the approach through AI placement and human gates to audit traceability. From the architects behind the Modernization Framework.
Ask a CFO what the IT budget buys and the answer is usually "the future." Look at the actual ledger and the answer is the past: legacy-heavy organizations routinely spend 60–80% of their IT budget just keeping existing systems running. The money isn't building anything. It is paying rent on decisions made fifteen years ago.
The trap has a mechanism, and it compounds. Aging platforms get more expensive to keep alive every year — vendor support premiums, scarce specialist skills, hardware maintenance that climbs 10–15% annually once warranties lapse. Meanwhile every new regulation lands as a change request against a system that resists change, so compliance work crowds out product work. In a regulated industry this is not just a cost problem; it is accumulating audit and security exposure with a budget line attached.
The third driver is quieter and often decisive: engineers. The people capable of modernizing your estate do not want to spend their careers babysitting it — and in a market that competes for senior talent, "come maintain our 2009 stack" is a recruitment ad for your competitors. The maintenance trap is therefore triple: it eats the budget, it compounds the risk, and it repels exactly the people who could end it.
The quotable version for your next steering committee: a legacy system's biggest cost is not what it takes to run — it is everything it prevents you from building.
future articles on this sub-topic will be linked here
Every modernization starts with the same fork: replace the system in one coordinated cut-over (big-bang rewrite) or migrate it piece by piece while it keeps running (the strangler-fig pattern). The honest answer is that big-bang is occasionally right — for small, well-understood systems with tolerant downtime windows and stable requirements. That describes almost nothing that runs a regulated business.
For everything else, the strangler wins on the only dimension that matters to a board: risk shape. A rewrite concentrates all risk at a single go-live — the day when years of assumptions meet production traffic at once. Strangler migration spreads that risk across many small, reversible cut-overs: carve the estate into domains, route one domain at a time to the new system, prove it under real load, then retire the old path. If a step fails, you roll back a domain, not a company.
The trade-off, stated plainly: strangler costs more in engineering discipline. You need clean domain boundaries, an integration layer that can route by domain, and the patience to run two systems in parallel (chapter 6 puts numbers on exactly that). Modular, event-driven target architectures make the carving tractable — the deep dive below covers the patterns. But discipline is a cost you control. A failed big-bang is not.
The calculation from chapter 6 as a template – for your budget request.
View the Builderfuture articles on this sub-topic will be linked here
Mechanics instead of magic. AI helps modernization in four specific places, and knowing exactly where is what separates a credible program from a slideware one.
Analysis is the most dramatic: LLM-assisted codebase analysis maps a system of 7,000+ files in roughly two hours, producing a structured report — architecture, dependencies, dead code, risk hotspots — that previously consumed weeks of senior-engineer archaeology. This changes the economics of the decision itself: you can afford to understand a system before committing budget to it. Refactoring is where AI generates the mechanical transformation volume — framework migrations, API extraction from monolith modules, dependency upgrades — at a pace no human team matches. Test generation attacks the classic schedule-eater: characterization tests that pin down what the legacy system actually does before you change it. Documentation falls out of the process instead of being deferred forever.
And the honest half: what AI cannot do reliably. It does not know your business intent — it sees what the code does, not what it was supposed to do, and legacy systems are archives of undocumented exceptions that matter. It cannot own a risk decision. And unreviewed, it confidently produces plausible-looking changes that are subtly wrong. Which is why every mechanism above runs behind human gates — the subject of the next chapter.
future articles on this sub-topic will be linked here
Mechanics instead of magic. AI helps modernization in four specific places, and knowing exactly where is what separates a credible program from a slideware one.
Analysis is the most dramatic: LLM-assisted codebase analysis maps a system of 7,000+ files in roughly two hours, producing a structured report — architecture, dependencies, dead code, risk hotspots — that previously consumed weeks of senior-engineer archaeology. This changes the economics of the decision itself: you can afford to understand a system before committing budget to it. Refactoring is where AI generates the mechanical transformation volume — framework migrations, API extraction from monolith modules, dependency upgrades — at a pace no human team matches. Test generation attacks the classic schedule-eater: characterization tests that pin down what the legacy system actually does before you change it. Documentation falls out of the process instead of being deferred forever.
And the honest half: what AI cannot do reliably. It does not know your business intent — it sees what the code does, not what it was supposed to do, and legacy systems are archives of undocumented exceptions that matter. It cannot own a risk decision. And unreviewed, it confidently produces plausible-looking changes that are subtly wrong. Which is why every mechanism above runs behind human gates — the subject of the next chapter.
In a supervised industry the question is never only "does the new system work?" — it is "can you prove how it came to be?" FINMA's Guidance 08/2024 expects institutions using AI to maintain inventories, document processes, ensure explainability, and subject critical applications to independent review. Translated to modernization: every AI-assisted change needs a paper trail an examiner can walk.
Concretely, our evidence chain pins every transformation to a commit SHA: which tool (and version) proposed the change, which engineer reviewed and approved it, when, and against which gate policy. Analysis reports are versioned artifacts. Model access is retrieval-only — client code is never used to train anything, contractually and technically. The whole trail exports as a package your auditor can consume without us in the room. This is not compliance decoration on top of the method; it is the method. Teams that modernize this way answer the regulator's AI question in an afternoon. Teams that don't, reconstruct history for a quarter.
The number most business cases hide on slide nine belongs on slide one: during migration, you run two systems in parallel, and McKinsey's research puts the resulting overspend at roughly 14% annually through the transition — Gartner calls it the "migration bubble." So the honest cost curve is a J: up first (investment plus dual-run), then crossing below the status quo, then compounding in your favor. Present anything smoother and a competent CFO stops listening.
The destination justifies the J: benchmarks from McKinsey, Kyndryl, and Accenture consistently show 30–40% lower infrastructure and maintenance costs after modernization, and the budget ratio flips — from 60–80% of IT spend on keeping the lights on to roughly 20–30%, releasing the majority of the budget for building. Which yields the strategic conclusion this whole guide builds toward: the biggest lever in modernization economics is not the size of the investment — it is the length of the dual-run window. That is precisely what AI-accelerated delivery compresses: faster analysis, faster transformation, earlier domain cut-overs, a narrower and shallower J. The risks worth naming honestly: underestimated data migration, frozen-in-time scope creep on the legacy side, and organizational fatigue — all functions of time, all shortened by the same lever. Put your own numbers on it with the Business Case Calculator.
Deep dives · chapter 6 The dual-run bill: why time is the real cost of modernization - and how AI shrinks it.
future articles on this sub-topic will be linked here
Domain by domain: first cut-overs in months, full estates in one to three years depending on size and coupling. The honest unit of measurement is not the end date — it is time-in-dual-run per domain, because that is where the cost and the risk live. AI-accelerated analysis and refactoring shorten exactly that window.
Typically 60–80% of your IT budget locked into maintenance, escalating 10–15% a year on aging platforms — plus every initiative the old system quietly vetoes, from AI features to faster compliance responses. The status quo is not free; it is the most expensive option with the least visible invoice.
Yes — if you can prove its origin, review, and approval per change. Swiss regulation (FINMA Guidance 08/2024) is technology-neutral: it doesn't ban AI, it demands governance and evidence. Chapter 5 shows the evidence chain; the deep-dive article "Is AI-generated code allowed in a bank?" covers the bank-specific answer.