What has changed
Legacy systems were always awkward. AI raises the cost of inaccessible data specifically — because automation that could be reading your order history, your inventory, your customer records simply cannot reach them. The constraint is no longer usability; it is access.
The modernisation question has a new priority order. Data accessibility now matters more than user interface age.
Reframing what "legacy" costs you
| Problem | Cost before AI | Cost now |
|---|---|---|
| Dated user interface | Training time, some frustration | Roughly unchanged |
| No API or data access | Manual re-entry between systems | Automation cannot reach it at all |
| Undocumented business rules | Knowledge concentration risk | Cannot be encoded into automation |
| Data trapped in reports | Analysts export manually | AI cannot use it |
| No audit trail | Compliance difficulty | Blocks AI deployment approval |
Notice which row barely moved. Interface modernisation — the most visible and most commonly proposed project — is the one AI changes least. Data accessibility, the least visible, is now the binding constraint. Modernisation budgets frequently point at the wrong problem.
The priority order
- Programmatic data access. An API, database views, or an export mechanism. Everything else depends on this.
- Data quality. Duplicates, orphans and inconsistency reach automation and get surfaced confidently.
- Documented business rules. Rules living only in people's heads cannot be automated or verified.
- Audit capability. Required before most organisations will approve automated access.
- Integration between systems. Removing the manual re-entry that currently bridges them.
- User interface. Genuinely last, unless it is causing errors.
The access layer approach
You rarely need to replace the system to make its data usable:
| What exists | Access approach | Effort |
|---|---|---|
| Modern API | Use it directly | Low |
| Database, no API | Read-only views plus a small service | Low–moderate |
| Scheduled file exports | Ingest into a queryable store | Moderate |
| Terminal or screen access only | Data extraction to a replica | High |
| Nothing programmatic | Vendor engagement, or replacement | Highest |
Read-only views over a replica are the highest-value, lowest-risk first step. No change to the legacy system, no write risk, no vendor negotiation — and it unlocks reporting, integration and AI access simultaneously. Many organisations get most of the value they wanted from modernisation without modernising anything.
Why replacement usually goes badly
- Undocumented rules. Decades of edge cases encoded in code nobody has read recently.
- Scope discovery during build. Every month reveals behaviour nobody knew about.
- Parallel running is expensive and nobody wants to switch off the old system.
- Data migration from an inconsistent source is its own project.
- User resistance to changing something that works.
The legacy system is not just software. It is a written record of how your business actually operates, including the parts nobody remembers deciding.
Strangler pattern, practically
Replace incrementally rather than all at once:
- Put an access layer in front of the legacy system.
- Build new capability against that layer, not against the legacy system directly.
- Move one function at a time to new implementation, with the layer routing appropriately.
- Verify each move by running both and comparing outputs.
- Retire legacy components only once their replacement is proven.
Slower than a rewrite in theory, faster in practice, and the business keeps running throughout.
What AI specifically requires
If enabling AI is part of the motivation, these are the requirements beyond raw access:
- Narrow, described operations — "get order status by ID", not "query the database".
- Permission mapping to the requesting user, which legacy systems frequently make difficult.
- Reasonable response times. An agent waiting thirty seconds for a query is unusable.
- Trimmed responses rather than full records.
- Audit logging of access.
Legacy permission models are frequently the hardest part — many older systems have coarse roles or a shared application account, which makes per-user scoping genuinely difficult.
Where to start
- Inventory what data exists and what access mechanism each system offers.
- Identify the highest-value inaccessible data — usually orders, inventory or customer records.
- Build read-only access to that subset first.
- Prove value with reporting or a narrow AI use case.
- Expand access guided by what proved useful.
- Consider replacement only where the legacy system is genuinely unsupportable.
Have systems holding data your automation cannot reach? Tell us what the systems are and what access exists. See our web application service, API integration, and MCP servers.