Age isn't the real blocker
Plenty of decades-old systems run reliably every day. The problem for AI is reach. The data sits in a database no modern tool can query, and the business rules live in code nobody wants to touch.
Step one: expose the data
Start with read access. Replicate the data your AI use cases need into a modern store, or put a read API in front of the legacy database. That alone makes reporting, search and question-answering possible without changing the core system.
Step two: wrap key actions in APIs
Next, identify the handful of actions that automation needs: create an order, update a customer, post a journal entry. Wrap each one in a well-documented API with validation and logging. Agents and new applications call the API; only the API talks to the old system.
Step three: modernise where it hurts
With data and actions reachable, you can see which modules actually slow the business down. Rebuild those first, behind the same APIs, and leave stable parts alone until there's a reason to change them.
A sensible sequence
Most of the organisations we work with follow roughly this order:
- Months 1–2: data replication and a read API for the first use case
- Months 2–4: action APIs for the workflows you want to automate
- Months 4 onward: rebuild the modules with the highest change cost
Inventory the workflow before the technology
Start with the task that needs better access, not a request to expose the whole legacy system. Identify the users, the records they need and the decisions or actions they perform today. Then map where the relevant facts are stored and who owns them. A field with the right name is not necessarily the authoritative source, particularly when years of exports and local spreadsheets have accumulated around the core application.
Talk to the people who operate the process and the people who maintain the software. Their explanations often reveal validation rules, reconciliation steps and exceptions that are absent from the documentation. Record what is known, what is assumed and what must be tested. The first useful outcome is a map that supports a bounded change. It should show enough to choose a safe read or action boundary without turning discovery into a requirement to understand and replace every component in the estate.
A read layer still needs a data contract
Replicating data or adding a read API changes who can see information and how current they expect it to be. Define the record identifiers, field meanings, access rules and expected freshness before connecting a new consumer. The new layer should preserve the distinctions that matter to the business instead of flattening every historical state into the latest visible value.
Choose how deletions, corrections and delayed updates propagate. A chatbot answering from yesterday's data may need to disclose the source time or refuse a time-sensitive question. A reporting pipeline needs a way to distinguish no activity from a failed refresh. Tests should include missing records, permission changes and reconciliation with the core. These are part of making the data usable, not optional work after the first successful query. The legacy system can remain the source of truth while a controlled interface makes the required information reachable.
Expose actions with stricter boundaries than reads
Writing back to a legacy system creates a different risk from reading it. Define a small operation with validated inputs and an explicit result, rather than handing a new application or agent general database write access. The interface should enforce the business rule and authorization even when the caller is wrong. Sensitive or difficult-to-reverse actions need the agreed review step before execution.
Plan for uncertainty after a request. A network timeout does not prove that the operation failed; the core may already have accepted it. Operation identifiers, status lookup and reconciliation help avoid repeated actions. Record enough information to investigate without copying unnecessary sensitive data into logs. Tests should include duplicate requests, rejected inputs, unavailable dependencies and partial failure. A well-defined action boundary supports both conventional software and later AI features. It is valuable even if the business eventually decides that the action should never be delegated to an agent.
Choose the migration boundary that can be checked
Incremental modernization works when responsibilities can move across a clear boundary. Choose a module or workflow whose inputs, outputs and acceptance criteria can be examined. Keep compatibility with the parts that stay in place and define which system owns a record during the transition. A new implementation should not quietly create two competing sources for the same business fact.
A trial migration or parallel comparison can reveal discrepancies before cutover. Agree the checks, the people who accept the result and the conditions that trigger rollback. Historical records, identifiers and downstream reports may matter even when the new user interface works perfectly. Retire old components only after their responsibilities have moved and the agreed evidence is available. The point is to reduce the cost of change while preserving the operating business, rather than declaring a rewrite finished because a new application has deployed.
Keep the AI boundary separate from the core
An AI feature should use the controlled data and action interfaces rather than become a new reason to bypass them. For document questions, retrieval needs the approved sources and access rules. For an agent, tools need the allowed operations, approval paths and failure handling. The model's output is one input to the system, not permission to ignore the legacy application's rules.
Version prompts, retrieval settings and evaluations alongside the integration code. Include cases where information is absent, stale or restricted, and where an action cannot be completed safely. The user needs a useful explanation and a fallback route. This separation also makes model changes less disruptive: the underlying contract remains inspectable even when the model or assistant experience changes. It lets the business judge the AI feature against a real task without making the core system depend on an opaque conversational decision.
Handover is an operating requirement
The new layer needs an owner after the project. Document the source mappings, permissions, release procedure, alerts and recovery steps. Someone should know how to investigate a stale dataset, an action with an uncertain outcome or a change to the legacy interface. Your maintainers need access to the code and configuration, with credentials kept in the agreed server or platform controls.
The sequence in this roadmap is a planning example, not a universal calendar. The first scope depends on the estate, interfaces, data quality and operating constraints. An audit can determine whether to retain, wrap, repair or replace a component and what to validate first. Compare that bounded scope with the approved modernization and integration ranges in the pricing guide, then confirm the commitment in a written proposal. You do not need a promise to rebuild everything before you can make one useful workflow accessible, observable and maintainable.
Rehearse the handover on a real task
Before sign-off, ask an operator who did not build the integration to follow the runbook through a representative task. Include an unavailable dependency or an uncertain result and check whether that person can identify the state, find the relevant record and take the agreed recovery action. Record gaps in the instructions as delivery work rather than assuming the team will remember a demonstration. Keep a short decision record explaining why the chosen boundary, source and rollback condition were accepted. This gives the next maintainer the reasoning behind the configuration and helps the business change the system without reopening every earlier decision.
