There is a pattern we see in almost every DACH enterprise engagement. The AI initiative is well-scoped. The workflow is identified. The business case is clear. Then someone asks the only question that matters: "Where does the data come from?" And the answer involves a 15-year-old ERP module, a nightly batch export, three Excel files maintained by one person in accounting, and an FTP server that nobody remembers configuring.
The AI project has not failed. It has collided with the legacy stack. And in most mid-market companies, the legacy stack — not the model — is the binding constraint.
The real blocker is not AI — it is infrastructure
Most conversations about AI readiness focus on models, prompts, and tooling. Those are largely solved problems. The unsolved problem in most DACH mid-market companies sits in the layer underneath: the systems that hold the data, execute the processes, and encode the business logic.
When we run discovery engagements, the first dimension we assess is not data quality in the abstract — it is data accessibility. Can the relevant data actually be extracted, transformed, and fed into a workflow within a reasonable timeframe, reliably, and without a human babysitting a batch job? Surprisingly often, the answer is no, and the reason has nothing to do with AI.
This is not a niche complaint. McKinsey's CIO research puts a number on the drag: organisations divert an estimated 10 to 20 percent of their technology budget for new projects into servicing technical debt, and CIOs estimate that debt amounts to 20 to 40 percent of the value of their entire technology estate before depreciation. AI does not escape that tax. It pays it first, because an AI workflow is only as good as the data plumbing feeding it.
What "legacy" actually means for AI
Legacy is not about age. A 20-year-old SAP installation with clean interfaces and documented integration points is not legacy in any meaningful sense. A 3-year-old custom application with hardcoded business rules, no test coverage, and a manual Sunday-night deployment is.
For AI purposes, a system becomes legacy when its data is trapped — no APIs, no webhooks, no event streams, so getting anything out means screen scraping or a database view that breaks the moment someone renames a column. It becomes legacy when its process logic is implicit, living in stored procedures, spreadsheet macros, and the heads of long-tenured employees, with no specification and no way to understand what it does without running it. It becomes legacy when change is dangerous, requiring weeks of planning and a deployment window because there is no staging environment and no rollback. And it becomes legacy when integration is fragile — point-to-point connections through file drops and middleware that last received an update years ago.
When an AI workflow needs to read from, write to, or integrate with such a system, the initiative stalls. Not because of an AI limitation, but because the foundation cannot bear the load.
The compliance clock changes the calculus
There is a second reason the data layer can no longer be treated as an afterthought, and it is regulatory. The EU AI Act's data-governance obligations under Article 10 require that high-risk AI systems be trained, validated, and tested on data that is relevant, sufficiently representative, and "to the best extent possible, free of errors and complete" for the intended purpose — with documented data collection, preparation, and bias-examination practices that can be produced as evidence. Those obligations for high-risk systems apply from 2 August 2026.
If your data originates from a 15-year-old module with no provenance, no version control, and undocumented transformation logic in a stored procedure, you cannot evidence any of this. The legacy stack is not just a delivery problem; under the AI Act it becomes a documentation problem you are obliged to solve. For DACH operators in regulated sectors, the NIS2 implementation in Germany compounds the pressure — the German transposition entered into force in late 2025 and mandates structured risk management, supply-chain due diligence, and incident reporting across the IT estate. Undocumented, unmaintained integration layers are exactly what those measures are designed to flush out.
The modernisation spectrum
The instinct when facing legacy systems is to plan a big migration: replace everything, move to the cloud, start fresh. For AI-first modernisation this is almost always wrong. A two-year platform programme is not a prerequisite for a workflow you could ship this quarter. We work instead across a spectrum of interventions, each chosen for the specific blocker in front of us.
Stabilise. Often the legacy system does not need replacing — it needs a stable interface. An API wrapper around a database view. A message queue that decouples the legacy system from downstream consumers. A pipeline that extracts what the AI workflow needs without touching the core. This is the most common intervention and the most underrated. Stabilisation does not fix the legacy system. It makes it survivable while the AI workflow runs against it.
Decouple. When the legacy system is tightly bound to others through shared databases, synchronous calls, and hardcoded integrations, the blocker is not the system itself but the dependency web. Decoupling introduces an integration layer, event-driven messaging, or an API gateway so the AI workflow can operate independently. The pattern is consistent: the legacy system keeps running exactly as it does today, a new integration layer sits alongside it, and the AI workflow connects to that layer — never to legacy directly.
Modernise selectively. Sometimes a component genuinely must be rebuilt — but only the one that directly blocks the initiative. This is surgical, not wholesale. Replace the claims-intake module because the AI workflow needs structured data from it; leave the policy-administration system untouched because no workflow goes near it. The discipline is in resisting scope creep, where "while we're in there" quietly turns a four-week intervention into a four-quarter programme.
Migrate. Full migration is sometimes necessary, but it should run in parallel with AI delivery, never as a precondition for it. The AI initiative should not wait eighteen months for a clean platform. Modernisation and the workflow advance simultaneously, with the stabilisation and decoupling work serving as the bridge between the two. For organisations weighing this, the question of traditional migration versus AI-shift timing is the one to settle early.
The modernisation readiness assessment
Before choosing an intervention, you need to know where the legacy pressure is highest, because the right move for an undocumented stored-procedure tangle is not the right move for a fragile point-to-point integration. We assess a handful of dimensions and score each for severity.
The first is system complexity and technical debt — how much undocumented logic, how many dependencies, how fragile the deployment chain. The second is operational bottlenecks: where teams wait, work around, or manually compensate for what the system cannot do. The third is delivery friction — how long a change takes to ship, and the ratio of building a feature to deploying it safely. The fourth is integration dependencies: how many systems connect to this one, and how many of those connections are undocumented or maintained by a single person. The fifth is support burden, the share of effort spent keeping the system alive versus improving it. And the last is modernisation blockers — what actually prevents change today, whether budget, knowledge loss, risk tolerance, or political ownership.
The output is not a roadmap. It is a clear picture of where to start and what to do first. Our Legacy Readiness Check framework sets out the full methodology.
What this looks like in practice
The shape of the work is consistent across engagements. An AI workflow needs data from an ageing platform; the data exists, but extracting it depends on a chain of stored procedures, a manual spreadsheet adjustment, and a weekly batch run. The wrong response is to put the workflow on hold until the platform is replaced. The right response is to build a data pipeline alongside the platform — change-data-capture events into a message queue, consumed by the workflow — so the legacy system keeps running unchanged while the workflow gets fresh data continuously instead of once a week.
The platform migration then proceeds on its own track, decoupled from delivery, while the AI workflow is already in production earning its keep. That is the pattern worth internalising: do not let modernisation become a prerequisite for AI. Make it a parallel track, and build the bridge that lets AI run while modernisation progresses underneath it.
The cost of waiting
The most expensive decision is doing neither — not modernising and not deploying AI. Every month of inaction compounds the problem. The legacy stack drifts further from current standards and, after August 2026, further from what the AI Act expects you to be able to evidence. The people who understand the system get closer to retirement, taking the only documentation that exists with them. The technical debt accrues interest, and as McKinsey's CIOs report, it is already consuming a meaningful slice of every new project's budget.
Meanwhile, competitors who solved the integration problem — even messily, even with workarounds — are running production AI workflows that compound value every week. The question is not whether to modernise. It is whether to modernise strategically, in service of AI delivery, or reactively, when the legacy system finally breaks on a Sunday night with no one left who remembers how it works.
A Fit Call pinpoints the one legacy blocker standing between your AI initiative and production — and names the lightest intervention that clears it — before another quarter compounds the debt.
References: EU AI Act, "Article 10: Data and Data Governance," 2024 (https://artificialintelligenceact.eu/article/10/); McKinsey & Company, "Tech debt: Reclaiming tech equity," 2020 (https://www.mckinsey.com/capabilities/tech-and-ai/our-insights/tech-debt-reclaiming-tech-equity); Freshfields, "Germany implements NIS2 — what you need to know now," 2025 (https://www.freshfields.com/en/our-thinking/blogs/technology-quotient/germany-implements-nis2-what-you-need-to-know-now-102lwz4).