Every modernisation vendor now sells the same dream: point an AI model at your legacy COBOL, Java 8, or monolithic .NET estate, and it regenerates the equivalent in a modern stack. Years compressed into weeks. Eighty per cent less effort. The marketing is loud, the slide decks are confident, and for a Geschäftsführer staring at a modernisation budget that keeps growing, it is dangerously seductive.
The honest picture is both more encouraging and more sobering than the pitch. The tools are real and the acceleration is real. GitHub made Copilot app modernisation generally available for both Java and .NET in September 2025, promising that you can "assess applications, apply code transformations, patch builds, and containerize services, all in days instead of months." McKinsey, in its December 2024 analysis of AI for IT modernisation, reports that generative AI can accelerate modernisation timelines by 40 to 50 per cent and cut technical-debt-related costs by around 40 per cent. Those are credible numbers from serious sources. But read them precisely: they describe the code-and-upgrade phase. Code porting is the cheapest, most tractable, most automatable part of an enterprise migration. The expensive parts — the parts that put your operating licence and your data integrity at risk — are barely touched. For DACH mid-market companies, the discipline is to capture the real gain without believing the dream.
Where the acceleration actually comes from
The genuine productivity comes from a narrow band of work that is mechanical, repetitive, and pattern-dense — exactly where current models are strong and exactly where augmentation outperforms full automation.
Syntax and framework translation is the headline use case. Converting idiom for idiom, mapping libraries, rewriting a Struts-era Java module into a Spring Boot equivalent or a VB.NET batch job into a modern service. This is the work that historically consumed the largest block of porting hours, and it is the work GitHub's modernisation agent now assesses, transforms, and patches in a structured pass. Repeated-pattern conversion compounds it: a legacy estate is full of near-identical data-access methods, validation blocks, and serialisation routines, and a model regenerates twenty variants in the time a developer reviews one. Scaffolding and boilerplate — configuration, dependency declarations, deployment descriptors, test harnesses — is generated reliably and saves the tedious setup that quietly accumulates across a large programme. And documentation extraction delivers a genuine bonus: pointing a model at undocumented legacy code to infer intent produces readable documentation of what the system actually does, an asset that frequently never existed in the first place.
McKinsey's own examples sit squarely in this band. It cites a case where modernising 20,000 lines of code was estimated at 700 to 800 hours and an orchestrated set of gen-AI agents cut that estimate by roughly 40 per cent — the relationship-mapping step alone fell from 30 to 40 hours to about five — and a top-15 global insurer that improved code-modernisation and testing efficiency by more than 50 per cent. Impressive — and confined to the translate-and-upgrade phase.
Why porting is the cheap part
Here is the discipline the vendor pitch skips: porting code is not the same as migrating a system, and porting is rarely where enterprise migration cost concentrates. Strip out translation and you are left with the work that genuinely consumes the programme.
Testing and behavioural validation dominate. A model can generate test scaffolding, but it cannot tell you whether the migrated claims engine still calculates the correct reserve for a partial-liability case, or whether the order system still applies the right discount tier for a framework-contract customer. Those are domain validations that demand business knowledge, and code that "looks right" is not code that is right in production. Regression risk is structural and, if anything, sharper with generated code: subtle drift in floating-point precision, date handling, character encoding, or concurrency can seed data inconsistencies that surface weeks after cutover — and the engineer who reviewed generated output often holds less edge-case insight than the engineer who wrote it would have. This is not hand-waving. METR's randomised 2025 trial found that experienced developers were 19 per cent slower when allowed to use AI tools on mature codebases they knew well — having expected a 24 per cent speed-up going in, and still believing afterwards that the tools had sped them up by around 20 per cent. On exactly the kind of complex, high-context work that enterprise migration consists of, the perception gap runs the wrong way, and a programme planned on felt speed rather than measured speed will overrun.
Integration validation is untouched by code translation. Legacy systems live inside a web of APIs, database links, file exchanges, and message queues; porting the module does not port the proprietary interface to the reinsurance platform or the nightly file drop to the ERP. Data reconciliation — moving data across schemas, transforming formats, proving completeness — is irreducibly domain-specific; a model can suggest a schema mapping, but the reconciliation depends on what the data means. Security and permission redesign is where this becomes a board matter in Germany right now: legacy access models are decades of role-based rules tangled with individual overrides and checks buried in business logic, and the new platform needs a coherent architecture, not a literal transcription of the old one. Germany's NIS2 transposition — the amended BSI Act, published in the Federal Law Gazette in December 2025 — obliges a sharply expanded population of essential and important entities to put appropriate, proportionate technical and organisational security measures in place under a managed information-security regime, with responsibility pinned to individual members of the management body who cannot fully delegate it away. The expansion is not marginal: legal analysis of the new act estimates the number of regulated entities rising from roughly 4,500 to around 29,000. A migration is precisely the moment those obligations are tested, and an AI that faithfully reproduces a legacy permission model reproduces its liabilities with it.
And the work no tool reaches at all: process redesign and production stabilisation. The migrations that pay back do not transcribe a manual-era workflow into a modern stack; they redesign it for digital intake and automated triage — a judgement call a model cannot make. The first weeks after cutover, when issues no test environment caught surface under real load, demand experienced engineers who know both systems. AI does not help there. Julia Kordick, who leads modernisation work at GitHub, puts it plainly: full automation is "probably at least five years away," and "everyone who's currently promising you, 'hey, I can solve all your mainframe problems with just one click' is lying to you."
The honest economic read
Put the two halves together. AI is genuinely compressing the porting phase — McKinsey's 40-to-50 per cent timeline acceleration and ~40 per cent technical-debt cost reduction are real, and you should plan to capture them. But porting is a slice of total programme effort, and the dominant slices — testing, integration, data, security, stabilisation — are not falling at anything like the same rate, because they turn on business judgement, domain knowledge, and organisational coordination that no model supplies. A 40 per cent cut on a phase that is a fraction of the whole is a meaningful improvement to the modernisation business case. It is not a transformation of it.
So the bottom line is unglamorous and correct: AI lowers one significant cost line and will lower it further over time. It does not retire enterprise migration risk. It does not change the fundamental character of migration as a complex, risk-laden programme. Anyone selling you the eighty-per-cent number is selling you the easy 30 per cent of the work and quietly omitting the hard 70.
What this means for DACH planning
Three practical consequences follow for a Mittelstand modernisation roadmap.
Porting cost is now a declining variable, so sequence accordingly. Traditional estimates treat cost-per-module as fixed; AI makes the translation component cheaper every quarter. That argues for deferring modules that can safely wait until the tooling is better, while moving now on the work that creates value regardless. This is the logic behind the AI-shift migration strategy: when a cost is falling, creating value first and migrating later can beat migrating immediately.
Bank the gain that exists; do not borrow against the gain that might. Building a programme on the assumption that automation will reach 70 or 80 per cent in two years is speculation against an uncertain curve — and against the "at least five years" estimate for full automation from the team building these very tools. Building on today's verified porting acceleration, improving modestly, is conservative and defensible. Use current capability now, monitor the trajectory, and never let a future tool become an excuse to defer action.
Measure on your own code, because published numbers will not hold on your estate. Every benchmark — McKinsey's, GitHub's, and any vendor's — reflects specific codebases, languages, and tool versions. What accelerates a Java retail system may stall on a COBOL insurance core dense with domain logic. The only number that governs your plan is the one you produce by taking a module you have already migrated manually, running today's tools against it, recording the effort, and tracking the trend across quarters. That is the data that should drive your migration decision gates — not a figure from someone else's slide.
Guardrails that keep the gain from becoming a liability
If AI is already in your migration, a few non-negotiables protect the downside. Review generated code with the same rigour as human code, validated by engineers who understand the business logic rather than merely checking that it compiles. Resist the reflex to test less because code arrived faster — given the regression and perception-gap evidence, generated code warrants more scrutiny, not less. Avoid betting on a single tool: capabilities diverge sharply by module type, so test several and route each to its strengths. Keep a genuine manual-migration capability for the idiosyncratic, poorly documented, tightly coupled modules that no agent will handle cleanly; a programme assuming 100 per cent coverage will break on the 15 per cent that resists. And keep the decision gates honest — every two quarters, confirm the approach is delivering the measured effort reduction you assumed, and adjust before the assumption silently becomes a cost overrun.
The trajectory is positive. The next generation of tools will reach further into business-rule extraction, test generation from observed legacy behaviour, and integration mapping — capabilities in research today, not production. As they mature, the porting gain will grow and the economics will shift again. Plan for that as incremental improvement, not revolution. Use what works now, watch what is coming, and never lose sight of the fact that code is the part a machine can write — and the part that was never where your migration risk lived.
A Fit Call pressure-tests where AI genuinely cuts your migration cost — and where it would quietly hand you NIS2 and data-integrity risk dressed up as savings — before you commit the budget.
References: McKinsey, "AI for IT modernization: Faster, cheaper, and better," 2024 (https://www.mckinsey.com/capabilities/quantumblack/our-insights/ai-for-it-modernization-faster-cheaper-and-better); GitHub Changelog, "GitHub Copilot app modernization is now generally available for Java and .NET," 2025 (https://github.blog/changelog/2025-09-22-github-copilot-app-modernization-is-now-generally-available-for-java-and-net/); GitHub Blog, "How GitHub Copilot and AI agents are saving legacy systems" (Julia Kordick), 2025 (https://github.blog/ai-and-ml/github-copilot/how-github-copilot-and-ai-agents-are-saving-legacy-systems/); 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/); Greenberg Traurig, "NIS2 in Germany: The New BSI Act Makes Cybersecurity a Board-Level Issue," 2025 (https://www.gtlaw.com/en/insights/2025/12/nis2-in-germany-the-new-bsi-act-makes-cybersecurity-a-board-level-issue).