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 program. Twelve months later, the roadmap exists, nothing has been migrated, and the legacy system has accumulated another year of workarounds.
The problem is not a lack of planning. It is a lack of diagnosis. Before you can decide what to modernise, how to modernise, or when to modernise, you need to understand where the pressure actually is. Not all legacy systems need immediate attention. Not all technical debt creates equal friction. The systems that feel worst to work with are not always the ones that block the most value.
This is what the Legacy Readiness Check is designed to answer: where is modernisation pressure highest, and what should you do about it first?
Who this is for
The readiness check is relevant if any of these conditions apply:
- Legacy systems are slowing down your ability to ship changes
- Support and maintenance effort is increasing year over year
- Teams rely on manual workarounds to compensate for system limitations
- Modernisation has been discussed for years but never started because the scope felt too large
- You want to deploy AI workflows but the underlying systems cannot support them
If none of these apply, your legacy stack is probably fine. Keep running it.
If three or more apply, you have modernisation pressure. The question is where to focus.
The six assessment dimensions
We assess legacy readiness across six dimensions. Each dimension captures a different type of friction, and each points toward a different intervention. The goal is not to score everything and rank it. It is to identify the one or two dimensions where pressure is highest and action is most urgent.
Dimension 1: System complexity and technical debt
What to look for:
How much of the system logic is documented versus implicit? How many dependencies exist between modules? How fragile is the deployment chain? Can a new developer understand the system within a reasonable onboarding period, or does it take six months before someone is productive?
Red flags:
- Business logic lives in stored procedures, triggers, or batch scripts that no current team member wrote
- The system has no automated test coverage, or tests exist but nobody trusts them
- Deployment requires manual steps, specific sequences, or coordination across multiple teams
- "Nobody touches that module" is a phrase used regularly in team conversations
- The architecture diagram, if one exists, has not been updated in years
Severity indicators:
Low: The system is complex but understood. Documentation exists. Changes are possible with reasonable effort.
Medium: Key parts of the system are understood by few people. Changes require significant planning. Some areas are avoided because the risk of unintended effects is too high.
High: The system is a black box to the current team. Changes are made with fear. Every deployment is a risk event. Knowledge is concentrated in one or two individuals.
Dimension 2: Operational bottlenecks and manual workarounds
What to look for:
Where do teams wait for the system? Where do they work around it? How many processes exist purely to compensate for something the system should do but does not? How much time is spent on data correction, manual reconciliation, or "the Friday export"?
Red flags:
- Teams maintain parallel spreadsheets because the system's data is unreliable or inaccessible
- Processes that should take minutes take hours because of system limitations
- Specific team members are required for specific tasks because only they know the workaround
- Error correction is a routine part of the workflow rather than an exception
- End-of-month or end-of-quarter creates predictable crisis points
Severity indicators:
Low: Workarounds exist but are minor. They add friction without blocking value delivery.
Medium: Workarounds consume significant capacity. Teams have normalised inefficiency. Multiple FTEs worth of effort go into compensating for system limitations.
High: The workarounds are the process. Without them, the business function would not operate. The system is nominally running, but the real work happens outside it.
A DACH insurance company we assessed had 14 FTEs across three departments whose primary job was to bridge gaps between two systems that could not share data reliably. That is not a staffing problem. That is a modernisation signal.
Dimension 3: Delivery friction and change constraints
What to look for:
How long does it take to ship a change from idea to production? What percentage of that time is the actual development work versus deployment, testing, approval, and coordination overhead? How many changes are deferred because the effort of deploying them exceeds the value they deliver?
Red flags:
- Simple changes take weeks or months to reach production
- Deployment windows are limited to specific times, often evenings or weekends
- Testing is manual, slow, and unreliable
- The backlog contains items that have been deferred for years because the system cannot accommodate them easily
- Feature development has effectively stopped; all engineering effort goes to maintenance
Severity indicators:
Low: Changes ship in days to weeks. The process is somewhat slow but functional.
Medium: Changes ship in weeks to months. Delivery velocity is materially lower than it should be. The team is aware of the friction but has accepted it as normal.
High: The system is effectively frozen. Changes are avoided because the risk and effort are too high. The organisation routes around the system rather than through it.
Dimension 4: Integration and data dependencies
What to look for:
How does this system connect to other systems? How many of those connections are point-to-point versus mediated through an integration layer? What happens when one system changes? How far does the impact propagate? How accessible is the data for downstream consumers like reporting, analytics, or AI workflows?
Red flags:
- Integrations use shared databases, file drops, or FTP rather than APIs or event streams
- Nobody has a complete picture of all systems that depend on this one
- A change in one system regularly breaks another
- Data extraction requires custom scripts or manual intervention
- Real-time data access is impossible; everything runs on batch schedules
Severity indicators:
Low: Integrations exist and mostly work. Some are fragile but manageable.
Medium: Several critical integrations are fragile, undocumented, or maintained by a single person. Changes to one system create cascading issues.
High: The system is a hub in a dependency web. Touching it affects multiple downstream systems. Integration failures are regular and consume significant operational effort.
This dimension is particularly important for AI readiness. AI workflows need reliable, timely data access. If the legacy system cannot provide that, you need a stabilization or decoupling intervention before the AI workflow can run.
Dimension 5: Support burden and maintenance pressure
What to look for:
How much of the team's capacity goes into keeping the system running versus improving it? What is the trend? Is the support burden stable, increasing, or decreasing? What happens when the system fails? How long does recovery take?
Red flags:
- More than 40% of engineering capacity goes to maintenance and incident response
- Incident frequency is increasing over time
- Recovery from failures requires specialised knowledge held by few people
- The system requires regular "care and feeding" that is not visible in planning but consumes real capacity
- Vendor support has ended or is ending
Severity indicators:
Low: Support burden is manageable and stable. The team spends most of its time on value-creating work.
Medium: Support burden is significant and growing. The team is spending more time on maintenance than anyone planned for. Value-creating work is being squeezed.
High: Support is the primary activity. The team is in reactive mode. There is no capacity for improvement, and the trend is getting worse.
An industrial manufacturer in southern Germany had a legacy MES system where three of five engineers spent over 60% of their time handling system incidents and manual data corrections. The remaining 40% went to keeping the backlog from growing. Net new value delivered: effectively zero.
Dimension 6: Modernisation blockers, risks, and opportunity areas
What to look for:
Why has modernisation not happened yet? What has prevented the organisation from acting? Is it budget? Knowledge loss risk? Unclear target architecture? Political ownership? Fear of disruption? Understanding the blocker is as important as understanding the technical debt.
Red flags:
- Modernisation has been proposed and rejected multiple times
- The budget for modernisation is always "next year"
- Key stakeholders benefit from the current system and resist change
- The organisation does not know what it would migrate to
- Previous modernisation attempts failed, creating organisational scar tissue
Opportunity areas to identify:
- Quick wins: components that can be stabilised or decoupled with minimal risk
- Strategic value: areas where modernisation directly enables high-value AI or automation workflows
- Knowledge preservation: documentation and architecture recovery before key personnel leave
- AI-shift opportunities: areas where creating value now and migrating later may be the better option
What the readiness check delivers
The output of a readiness check is not a migration roadmap. It is a diagnostic:
A severity map across all six dimensions. This shows where the pain is highest and where action is most urgent. Often the result is surprising: the system that generates the most complaints is not always the one with the highest severity.
Friction points with business impact. Not just "this system is old" but "this system costs us X hours per month in manual workarounds and blocks Y in potential revenue from AI workflows."
Where modernisation creates leverage. Not everything needs to be modernised. The readiness check identifies the specific components where intervention unlocks the most value. Often, this is a stabilization or decoupling intervention rather than a full migration.
A recommended first step. Not a twelve-month roadmap. A specific intervention, scoped in weeks, that addresses the highest-severity dimension. For a fuller picture of the intervention options, see Legacy Modernisation for AI.
What the readiness check is not
It is not a full architecture review. It does not produce a target-state design. It does not include vendor selection, platform evaluation, or migration planning. Those are downstream activities that require the readiness check as input.
It is also not a judgement on the people who built or maintain the legacy system. Legacy systems are the result of rational decisions made under prior constraints. The readiness check assesses the current situation, not the history.
How to use the results
The readiness check creates three possible outputs:
No immediate action needed. The system has legacy characteristics but the severity is low across dimensions. Monitor, do not modernise. Reassess in 12 months.
Targeted intervention. One or two dimensions show high severity. Address them specifically: stabilize the integration layer, decouple the data pipeline, or modernise the specific component that blocks value. This is weeks to months of work, not years.
Migration trigger. Three or more dimensions show high severity, and the trend is worsening. This system needs a migration plan. The readiness check provides the data to make that case to leadership.
The cost of skipping diagnosis
The most common failure mode in legacy modernisation is starting without diagnosis. The organisation commits to a large program, scopes it based on assumptions rather than assessment, and discovers halfway through that the real blocker was not what they expected.
A readiness check takes days, not months. The cost of running it is trivial compared to the cost of a mis-scoped modernisation program. And the value is in focus: knowing exactly where to start, why, and what outcome to expect.
Next step
If legacy systems are creating friction in your organisation and you want a structured view of where the pressure is highest, start with a Readiness Check. If you already have a clear picture and want to discuss intervention options, book a Fit Call and bring your findings.
This article is part of the Legacy Modernization for AI series by Andreas Anding. For the migration timing question, see The AI-Shift Migration Strategy.