For two decades, the migration playbook has been clear: every month you delay platform migration, the cost goes up. Every feature you add to the old system expands migration scope. Every workaround deepens the dependency. The maths was simple. Migrate now, or pay more later.
That logic was correct. Under the assumptions that held until recently, it was the right advice. But one of those assumptions has started to move, and when an assumption moves, the decision built on top of it deserves a fresh look.
What changed
AI-assisted code transformation has crossed a threshold. The tooling that ports legacy code, translates syntax between languages, and reconstructs business logic is materially more capable than it was eighteen months ago, and the major cloud platforms have shipped agentic modernisation services built specifically for this work. In its first year, AWS reported that its Transform service processed 4.5 billion lines of code and saved an estimated 1.6 million developer hours across its customer base — with named outcomes such as Signaturit Group cutting a Windows .NET-to-Linux migration from six-to-eight months down to a few days, and Air Canada upgrading Node.js runtimes in days at an 80% cost reduction.
These are vendor-reported figures, and vendor figures are marketing until you reproduce them on your own code. But the direction is not in doubt. The cost curve of migration is no longer fixed. For the right kind of work, it is declining — and that single fact creates a strategic option that did not exist before.
Here is the counterweight, and you should hold it firmly. The most rigorous independent study to date found the opposite of the hype. METR ran a randomised controlled trial with experienced open-source developers working on codebases they knew deeply, and AI tools made them 19% slower — even though the same developers predicted they would be 24% faster and, after the fact, still believed AI had sped them up. The lesson is not that AI migration tools do not work. The lesson is that they work in specific conditions — mechanical, high-volume, well-bounded transformation — and quietly fail in others, especially where deep local knowledge and bespoke judgement dominate. Migrating two million lines of boilerplate COBOL is the good case. Untangling the one gnarly module that holds your pricing logic together is the bad one.
The traditional recommendation
The standard recommendation is to stop building on legacy immediately, freeze feature development on the old platform, redirect all available capacity into migration, absorb the productivity loss during transition, and resume feature delivery on the new platform after cutover.
Call this Option A. It is disciplined, and under the assumption that migration cost is constant or rising over time, it is correct. For many companies it remains the right path. But it carries a cost that is routinely understated: the business waits. For twelve to twenty-four months the organisation absorbs the drag of a frozen feature pipeline. Competitors who are not migrating keep shipping. Customers who need new capabilities are told to hold on.
For a DACH industrial supplier with a stable market position and patient customers, that cost may be entirely acceptable. For an insurer or a mid-market retailer losing ground to digital-first challengers, a year-and-a-half feature freeze can do more damage than the migration ever would.
Option B: the AI-shift
The AI-shift inverts the sequence. Instead of stopping everything to migrate, you continue building high-value features on the existing platform, invest in value-creating capabilities now — including AI workflows that pay back inside a year — accept that you are adding to migration scope, and plan migration for a later window when AI-assisted tooling has reduced the effort of the mechanical work. You are making one explicit bet: that the migration cost reduction on the portable parts of your estate will outweigh the scope you add in the meantime.
This is not the safe path. It is the higher-optionality path. And the framing matters: this is not a correction of the traditional advice. The traditional recommendation was correct under prior assumptions. The AI-shift is a new option made possible by a new variable. Both are valid. The only real question is which one fits your situation.
When the AI-shift makes sense
The AI-shift is not universally better. It is specifically better under a narrow set of conditions, and you need all of them, not most.
The business cannot afford a feature freeze. When a year of paused capability delivery would cost you market position, the competitive price of the freeze can exceed the migration savings outright. That is the whole case for moving value forward and migration back.
High-value opportunities exist on the current platform. If there are AI workflows, automation, or customer-facing capabilities that would deliver material return within twelve months, and they can be executed on the system you already run, then delaying them in order to migrate first actively destroys value.
The legacy platform is stable enough to carry the load. The AI-shift assumes the existing system can sustain continued development. If the platform is actively failing, support costs are spiralling, or key maintainers are walking out the door, migration cannot wait. The Legacy Readiness Check exists to force this assessment honestly rather than optimistically.
The migration target is well-defined. The strategy works only when you know what you are migrating to. If the target architecture is still vague, delaying migration is not strategy. It is procrastination with a strategic label.
When the AI-shift is wrong
Do not take this path if the legacy platform is operationally unstable with rising incident rates, if support burden is already consuming a large and growing share of engineering capacity, if critical system knowledge sits with one or two people approaching retirement, if a regulatory change demands platform capabilities the legacy system simply cannot provide, or if technical debt has reached the point where every new feature costs several times what it should. In those situations the traditional recommendation holds without qualification. Migrate now. The cost of waiting is real, compounding, and not offset by any future tooling savings — and on the modules that matter most, the METR result is a warning that the AI savings may not arrive at all.
The four guardrails
If you take the AI-shift, you need discipline. Without it, the strategy degenerates into "we'll migrate someday" — the same sentence enterprises have been repeating to themselves for a decade.
Guardrail 1: only approve high-value legacy development. Not everything gets built on the old platform. Every new feature passes through a value gate — does this deliver enough business return in the next six to twelve months to justify the migration scope it adds? Low-value work waits for the new platform; only work that creates measurable operating leverage gets approved. This is the hardest guardrail to enforce, because product owners will push for convenience features and sales will push for quick wins. The discipline lives entirely in saying no to anything that does not clear a high bar.
Guardrail 2: build reusable logic outside the old core. When you do build on legacy, architect for portability. New business logic belongs in API layers, integration services, and AI pipelines that sit alongside the legacy system, not inside it. An insurer deploying an AI-assisted claims-triage workflow should not embed that logic in a twenty-year-old claims system; it should build a service that reads from and writes to that system through an API wrapper. When the claims core eventually migrates, the triage service stays. This is the build-the-bridge-not-the-extension pattern we use in stabilisation and decoupling work, and it is what turns the AI-shift from a gamble into a hedge — the value you create survives the migration regardless of how the tooling bet plays out.
Guardrail 3: re-test the migration economics on your own code, quarterly. The AI-shift bet depends on the tooling continuing to improve on work like yours — and the gap between vendor headlines and the METR result is exactly why you cannot take that on faith. Every quarter, take a representative legacy module and run current AI migration tooling against it under realistic conditions. Measure the genuine effort reduction, not the demo. Track the trend. If it flattens, reverses, or only ever holds on the easy modules while the hard ones stay manual, the thesis weakens and you accelerate traditional migration. The companion piece, what AI-assisted migration actually delivers today, is built around structuring exactly this kind of honest benchmark.
Guardrail 4: maintain a hard migration decision gate. Set a date, twelve to eighteen months out, where the strategy faces a formal go/no-go. At that gate, ask plainly: has the value created on legacy justified the scope added? Have migration costs fallen as expected on your estate? Is the organisation still in a position to migrate, or has institutional momentum quietly made migration politically impossible? The gate is what prevents drift. Without it, the AI-shift becomes permanent deferral. With it, it stays what it was meant to be — a time-boxed bet with a defined moment of reckoning.
The Geschäftsführung conversation
If you are taking this to the Geschäftsführung or a board, keep the framing clean. The recommendation to migrate immediately was correct under the assumptions that held until recently. A new factor — AI-assisted modernisation that genuinely reduces the effort of high-volume, mechanical migration work — has shifted the economics for part of the estate. That gives you two valid options. Option A: freeze legacy development and migrate now. Option B: create value now and migrate the portable parts later, when the tooling has matured against your own code. The recommendation is Option B where the conditions hold — because the business value creatable in the next twelve months outweighs the incremental migration cost, and because the guardrails keep the migration viable throughout. You will re-test the economics quarterly and hold a hard decision gate at month eighteen.
This is not a technology argument. It is a capital-allocation argument. The question is not "should we modernise" — you will — but "what is the highest-value use of our engineering capacity over the next twelve months, and how do we keep that choice reversible?"
The risk you are actually taking
State the risk profile out loud; do not let anyone pretend the path is risk-free. The tooling may not improve as expected on your code — leaving you with more legacy scope and no offsetting saving; the quarterly benchmark and the decision gate are the mitigation, and the METR finding is the reason to run them seriously. The legacy platform may degrade faster than forecast, with operational burden eating the very capacity that was supposed to create value; readiness assessment and clear escalation triggers contain it. Institutional momentum may make migration politically harder the more you invest in the old system; an executive-sponsored decision gate and explicit communication that this is a time-boxed strategy, not a permanent one, keep that in check. And the talent market may tighten around legacy-specific skills over time; building reusable logic outside the core shrinks the legacy surface area you depend on. None of these are disqualifying. All are manageable with the guardrails above. But they are real, and anyone proposing the AI-shift should name them rather than sell around them.
One more piece of timing for DACH leaders specifically: regulatory deadlines are part of the migration calendar. Under the EU's late-2025 Digital Omnibus agreement, the application of high-risk obligations under the AI Act has shifted — Annex III stand-alone systems now move to 2 December 2027 — while 2 August 2026 remains an active compliance milestone. If your migration target is also the platform that will carry AI workloads into a regulated future, the decision gate is the right place to align the migration timeline with the obligations you will have to meet.
What to do next
Start with an honest assessment. Run the Legacy Readiness Check to establish whether your platform can actually sustain continued development, then review what AI-assisted migration delivers today to calibrate your expectations against evidence rather than vendor headlines. Then choose: Option A, or Option B with the four guardrails firmly in place.
A Fit Call pressure-tests your migrate-now-versus-create-value-first decision against your actual platform, scope, and regulatory calendar — before you commit a year of engineering capacity to the wrong sequence.
References: AWS, "AWS Transform: one year, 4.5 billion lines of code, 1.6 million hours saved," 2026, https://aws.amazon.com/blogs/migration-and-modernization/aws-transform-one-year-milestone/; METR, "Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity," 2025, https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/; European Commission, "Timeline for the implementation of the EU AI Act," 2026, https://ai-act-service-desk.ec.europa.eu/en/ai-act/timeline/timeline-implementation-eu-ai-act.