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: "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.

The real blocker is not AI — it is infrastructure

Most conversations about AI readiness focus on models, prompts, and tooling. Those are solved problems. The unsolved problem in most DACH mid-market companies is the layer underneath: the systems that hold the data, execute the processes, and connect the business logic.

When we run discovery engagements, the first dimension we assess is data accessibility. Not data quality in the abstract — but whether the relevant data can actually be extracted, transformed, and fed into a workflow within a reasonable timeframe.

In roughly 60% of our engagements, the answer is: not without touching the legacy stack first.

What "legacy" actually means for AI

Legacy is not about age. A 20-year-old SAP installation with clean APIs and documented interfaces is not legacy in any meaningful sense. A 3-year-old custom application with hardcoded business rules, no test coverage, and manual deployment is.

For AI purposes, a system becomes legacy when it exhibits these characteristics:

Data is trapped. There are no APIs, no webhooks, no event streams. Getting data out means screen scraping, database views that break when someone changes a column name, or asking the one person who knows the export routine.

Process logic is implicit. Business rules live in stored procedures, spreadsheet macros, or the heads of long-tenured employees. There is no documentation, no specification, and no way to understand what the system does without running it.

Change is dangerous. Any modification requires weeks of planning, manual testing, and a deployment window on a Sunday night. The system has no staging environment, no automated tests, and no rollback mechanism.

Integration is fragile. Connections between systems are point-to-point, often through file drops, shared databases, or middleware that last received an update in 2018.

When AI workflows need to read from, write to, or integrate with such systems, the initiative stalls — not because of AI limitations, but because the foundation cannot support it.

The modernisation spectrum

The instinct when facing legacy systems is to plan a big migration: replace everything, move to the cloud, start fresh. This is almost always wrong for AI-first modernisation.

Instead, we work across a spectrum of interventions, each chosen based on the specific blocker:

Stabilize (weeks, not months)

Sometimes the legacy system does not need to be replaced. It needs a stable interface. An API wrapper around a database view. A message queue that decouples the legacy system from downstream consumers. A data pipeline that extracts what the AI workflow needs without touching the core.

This is the most common intervention. It is also the most underrated. Stabilization does not fix the legacy system. It makes it survivable while the AI workflow runs.

Decouple (1-3 months)

When the legacy system is tightly coupled to other systems — shared databases, synchronous calls, hardcoded integrations — the blocker is not the legacy system itself but the dependency web. Decoupling means introducing integration layers, event-driven architectures, or API gateways that allow the AI workflow to operate independently.

The pattern: legacy system continues to run exactly as it does today. A new integration layer sits alongside it. The AI workflow connects to the integration layer, not to legacy directly.

Modernize selectively (3-6 months)

Some components of the legacy stack need to be rebuilt — but only the ones that directly block the AI initiative. This is not a full migration. It is surgical modernisation: replace the claims intake module because the AI workflow needs structured data from it, but leave the policy administration system alone because no AI workflow touches it.

Migrate (6-18 months, parallel track)

Full migration is sometimes necessary, but it should run in parallel with AI delivery — not as a prerequisite. The AI initiative should not wait 18 months for a clean platform. Instead, the modernisation and the AI workflow advance simultaneously, with the stabilization and decoupling work providing the bridge.

For companies considering this path, the question of traditional migration vs. AI-shift timing is increasingly relevant.

The modernisation readiness assessment

Before choosing an intervention, you need to understand where the legacy pressure is highest. We assess six dimensions:

System complexity and technical debt. How much undocumented logic, how many dependencies, how fragile is the deployment chain?

Operational bottlenecks. Where do teams wait, work around, or manually compensate for system limitations?

Delivery friction. How long does it take to ship a change? What is the ratio of "building the feature" to "getting it deployed safely"?

Integration dependencies. How many systems connect to this one? How many of those connections are fragile, undocumented, or maintained by a single person?

Support burden. How much operational effort goes into keeping the system running versus improving it?

Modernisation blockers. What prevents the organisation from modernising today? Budget? Knowledge loss? Risk tolerance? Political ownership?

Each dimension gets a severity score and a recommended intervention. The result is not a roadmap — it is a clear picture of where to start and what to do first. See our Legacy Readiness Check framework for the detailed methodology.

What this looks like in practice

In an e-mobility engagement, the AI workflow needed billing data from a 12-year-old platform. The data existed, but extracting it required a chain of five stored procedures, two manual Excel adjustments, and a weekly batch run.

We did not replace the billing platform. We built a real-time data pipeline alongside it: a set of database change-data-capture events piped into a message queue, consumed by the AI workflow. The legacy system continued running unchanged. The AI workflow got fresh data every 15 minutes instead of once a week.

Total effort: 3 weeks for the data pipeline, 4 weeks for the AI workflow. The billing platform migration is now on a separate 12-month track — but the AI workflow has been in production for months.

That is the pattern. 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.

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 modern standards. The people who understand it get closer to retirement. The technical debt accrues interest.

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.

Where to start

If legacy systems are blocking your AI initiatives, start with a Readiness Check to identify where the pressure is highest. If you already know the blocker, a Fit Call can determine whether stabilization, decoupling, or selective modernisation is the right intervention for your situation.