Most legacy modernisation conversations start in the wrong place. Someone declares "we need to migrate," and the organisation spends three months building a roadmap for a multi-year programme. Twelve months later the roadmap exists, nothing has been migrated, and the legacy system has accumulated another year of workarounds. The problem is rarely a lack of planning. It is a lack of diagnosis.
Before you can decide what to modernise, how, or when, you need to know where the pressure actually is. Not all legacy systems need immediate attention. Not all technical debt creates equal friction. And — this is the part organisations consistently get wrong — the systems that feel worst to work with are not always the ones that block the most value. The system everyone complains about is sometimes stable enough to leave alone for another two years; the quiet one nobody mentions is the one strangling your AI ambitions.
This is what the Legacy Readiness Check is built to answer: where is modernisation pressure highest, and what should you do about it first?
Why this question now has a regulatory edge
For years, legacy modernisation in the Mittelstand was a discretionary efficiency play — worth doing, easy to defer. That has changed. Two pieces of EU regulation have quietly turned "we'll get to it" into a liability question.
Germany's NIS2 transposition, the NIS2UmsuCG, was passed by the Bundestag in November 2025 and amends the BSI-Gesetz to bring an estimated 29,000 German entities into scope — up from roughly 4,500 — including manufacturers, IT service providers and mid-sized suppliers that never previously thought of themselves as regulated. Crucially, Section 38 of the amended BSI Act makes the management body personally liable for cybersecurity risk management and bars full delegation of that oversight. An unpatched, undocumented legacy system that no current team member fully understands is no longer just operational risk. It is now a board-level exposure.
In parallel, the EU AI Act becomes fully applicable to high-risk systems on 2 August 2026. Under Article 26, deployers of high-risk AI must guarantee human oversight by competent staff and retain the system's automatically generated logs for at least six months. You cannot satisfy either obligation if the data feeding your AI lives in a system that exports nightly via FTP and produces no reliable audit trail. The legacy layer underneath your AI ambitions is now part of your compliance surface, whether you planned it that way or not.
The readiness check exists so you find this out on your terms, in days, rather than during an incident or an audit.
Who this is for
The readiness check is relevant if legacy systems are slowing your ability to ship changes; if support and maintenance effort is climbing year over year; if teams rely on manual workarounds to compensate for what the system cannot do; if modernisation has been discussed for years but never started because the scope felt too large; or if you want to deploy AI workflows but the underlying systems cannot feed them clean, timely data. If none of that describes you, your legacy stack is probably fine — keep running it. If three or more apply, you have modernisation pressure, and the only real question is where to focus first.
The six assessment dimensions
We assess legacy readiness across six dimensions. Each captures a different kind of friction, and each points toward a different intervention. The goal is not to score everything and produce a ranking nobody acts on. It is to surface the one or two dimensions where pressure is highest and action is most urgent — then move.
Dimension 1: System complexity and technical debt. The question is how much of the system logic is explicit versus implicit. Can a new engineer become productive in weeks, or does it take six months before anyone dares touch the code? The red flags are familiar: business logic buried in stored procedures and batch scripts nobody currently on the team wrote; no automated test coverage, or tests that exist but nobody trusts; deployments that require a precise manual sequence; the recurring phrase "nobody touches that module." Severity is low when the system is complex but understood and documented. It is high when the system is a black box, every deployment is a risk event, and the knowledge lives in one or two people's heads. Under the new BSI Act liability regime, that last condition is no longer just a bus-factor problem — it is something the Geschäftsführung is now personally answerable for.
Dimension 2: Operational bottlenecks and manual workarounds. Here you look for where teams wait for the system, work around it, or maintain parallel spreadsheets because the system's own data is unreliable. Count the processes that exist purely to compensate for something the system should do but does not — the Friday export, the monthly reconciliation, the one person who knows the trick. Severity is low when workarounds add friction without blocking value. It is high when the workarounds are the process: the system is nominally running, but the real work happens in spreadsheets beside it. When you find several full-time roles whose primary job is bridging two systems that cannot reliably share data, you are not looking at a staffing problem. You are looking at a modernisation signal that has been miscategorised as headcount.
Dimension 3: Delivery friction and change constraints. How long does a change take from idea to production, and how much of that is actual development versus deployment, testing, approval and coordination overhead? The warning signs are simple changes that take weeks or months, deployment windows confined to evenings and weekends, manual and unreliable testing, and a backlog of items deferred for years because the system cannot absorb them cheaply. Severity is low when changes ship in days to weeks. It is high when the system is effectively frozen and the organisation routes around it rather than through it — the clearest sign that the system has stopped being an asset and started being a constraint on the business itself.
Dimension 4: Integration and data dependencies. This dimension matters most for anyone planning AI. The question is how the system connects to everything else — point-to-point versus mediated through an integration layer — and how far the blast radius extends when one system changes. Red flags include integrations built on shared databases, file drops and FTP rather than APIs or event streams; no complete picture of which systems depend on this one; changes that routinely break something downstream; and data that can only be extracted by batch or custom script, never in real time. Severity is high when the system is a hub in a dependency web and integration failures are a regular operational cost. AI workflows need reliable, timely, well-governed data access — and, under EU AI Act Article 26, an auditable record of what the system did. If the legacy layer cannot provide that, the honest sequence is a stabilisation or decoupling intervention before the AI workflow, not after. This is the core of AI readiness: the model is rarely the bottleneck; the pipe feeding it usually is.
Dimension 5: Support burden and maintenance pressure. Track how much team capacity goes into keeping the system alive versus improving it, and — more importantly — the trend. Is the burden stable, or is it quietly compounding? The red flags are a maintenance-and-incident load that consumes a large and growing share of engineering capacity, incident frequency that is increasing over time, recovery that depends on a handful of specialists, and vendor support that has ended or is about to. Severity is high when support is the primary activity, the team is permanently reactive, and there is no capacity left for improvement. The tell is a team that is fully occupied yet delivering effectively zero net-new value — every hour spent holding the line instead of moving it forward.
Dimension 6: Modernisation blockers and opportunity areas. Understanding why modernisation has not happened is as important as understanding the technical debt. Is the blocker budget, knowledge-loss risk, an unclear target architecture, political ownership, or scar tissue from a previous failed attempt? Name it honestly, because the wrong diagnosis here sinks the whole effort. Then look for the opportunities the same assessment reveals: quick wins that can be stabilised or decoupled with minimal risk; strategic components where modernisation directly unlocks high-value AI or automation; knowledge preservation before key people leave; and AI-shift opportunities where creating value now and migrating later is the smarter sequence than a full rebuild.
What the readiness check delivers
The output is not a migration roadmap. It is a diagnostic with four parts. First, a severity map across all six dimensions, which shows where the pain is highest — and frequently surprises, because the loudest system is not always the most severe. Second, friction points translated into business impact: not "this system is old" but "this consumes roughly X hours per month in manual workarounds and blocks Y in value AI workflows could deliver, and it now sits inside our NIS2 and AI Act compliance perimeter." Third, where modernisation actually creates leverage — usually a specific component where a stabilisation or decoupling intervention unlocks disproportionate value, rather than a wholesale migration. And fourth, a recommended first step scoped in weeks, not a twelve-month programme. For the intervention options that follow, see Legacy Modernisation for AI.
Equally, it helps to be clear about what the readiness check is not. It is not a full architecture review and produces no target-state design. It does not include vendor selection, platform evaluation or migration planning — those are downstream activities that take the readiness check as input. And it is not a judgement on the people who built or maintain the system. Legacy systems are the result of rational decisions made under prior constraints. The check assesses the current situation, not the history.
How to use the results
The readiness check resolves to one of three outcomes. The system may need no immediate action — legacy in character, but low severity across the board, in which case you monitor and reassess in twelve months rather than modernise on principle. It may call for a targeted intervention, where one or two dimensions run hot and you address them specifically: stabilise the integration layer, decouple the data pipeline, harden the audit trail that AI Act logging now requires. That is weeks to months of work, not years. Or it may be a genuine migration trigger — three or more dimensions at high severity and worsening — in which case the check has given you the evidence to make that case to leadership in terms they can defend, including the regulatory exposure that now sits on the management body directly.
The most common failure mode in legacy modernisation is starting without diagnosis: committing to a large programme, scoping it on assumptions rather than assessment, and discovering halfway through that the real blocker was never the one everyone named. A readiness check takes days. Its cost is trivial against the cost of a mis-scoped modernisation programme — and against the cost of finding out, during an audit or an incident, that the system you deferred is now both your operational bottleneck and your compliance gap. The value is in focus: knowing exactly where to start, why, and what outcome to expect.
A Fit Call maps your highest-pressure legacy system across all six dimensions and names the one intervention worth scoping first — before NIS2 liability or the August 2026 AI Act deadline forces the decision for you.
References: NIS2UmsuCG / amended BSI-Gesetz, Section 38 (management-body liability), passed November 2025 — 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; Regulation (EU) 2024/1689 (EU AI Act), Article 26, high-risk obligations applicable 2 August 2026, https://artificialintelligenceact.eu/article/26/; European Commission, "AI Act," https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai.