An organisation adds an AI assistant to an existing application. The demo looks promising. In daily use, the assistant answers confidently, sometimes incorrectly, and struggles to act. The application underneath still works as it always did: built before anyone expected a software agent to read its data, call its functions, or explain what happened afterwards.
That foundation matters. A Harvard Business Review Analytic Services report published in March 2026, sponsored by Cloudera, found that just 7% of respondents considered their organisation’s data completely ready for AI adoption. Seventy-three per cent said their organisation had found preparing and processing data for AI challenging. The survey covered more than 230 respondents involved in AI data decisions and was conducted in October 2025.
For an established business, the question is practical. How do you make an ageing application ready for AI while the company continues to depend on it?
At Runbaze, we approach that work one capability at a time. The order matters, because every agent inherits the conditions of the system it works inside.
What an agent needs underneath it
Three conditions shape whether an AI layer can do useful work.
The first is data it can reach through a consistent, governed access layer: current, coherent, and owned by someone who can answer for it. The second is a bounded interface: a way to perform one specified task, with access limited to what that task requires. The third is governance: rules for access, a record of decisions, and a person responsible for approving the actions that matter.
When one of these is missing, the weakness passes into the output. An agent works from an old figure, reaches further than it should, or proposes something nobody can trace back to its source. The failure may stay quiet until someone relies on the result.
Systems of record stay in place. The foundation is built once and reused by every agent.
Stale data fails visibly. It never quietly becomes an AI answer.
Why a full rewrite is a large bet
An application carries years of accumulated business knowledge. Some of it is documented. Much of it survives only in the code: exceptions, checks, and rules added because something once went wrong.
A full rewrite puts that knowledge at risk while setting a moving target. The business keeps operating, the existing system keeps changing, and the replacement has to catch up with both.
Joel Spolsky made this argument about Netscape in 2000. Replacing a codebase can also mean discarding the lessons embedded in it. That remains a useful warning: a rewrite commits substantial time and money before the replacement has proved itself in the business.
Replace one capability, then the next
Martin Fowler described the strangler fig approach in 2004: grow a replacement around an existing system, moving functionality across gradually.
A common implementation puts a routing layer in front of the application. One capability is built as a new service, and requests for that capability are redirected to it. The rest continue to the existing system. Once the replacement is validated and its dependencies are resolved, the old code for that capability can be retired.
Each step is small enough to finish, release, and assess. Reversal is planned before the switch, while the old capability and the necessary data remain available. Retirement comes after the evidence supports it.
A routing layer sits in front. Each capability moves to a new service, then the old code is retired.
Each step is small enough to finish, release and reverse. Agree early what will be switched off.
The sequence starts with data
For this approach, we use a fixed sequence. First establish what the agent can rely on. Then decide what it may do.
1. Check the data first.
Before building, we take snapshots from the priority systems and establish the first connections. We check which identifiers line up, how current each source is, and where the records disagree. The work ends with a plain decision: go or no go for the proposed first slice.
2. Build the shared foundation once.
The systems of record stay in place and remain authoritative. Above them sits a governed layer for access and interpretation, with a common set of identifiers and a canonical model for the data the workflows use.
Every figure carries its quality state: live, provisional, or reconciled. A provisional figure must remain recognisable as provisional wherever it appears. When a source falls behind, the screen shows it, and the same freshness checks apply to the agent. Stale data must trigger a visible failure or exception before it can be presented as a current answer.
3. Keep critical rules outside the model.
Safety rules and financial calculations run as deterministic checks, separately from model-generated reasoning. These checks remain available when the model is down. Their enforcement does not depend on the agent remembering an instruction.
4. Add agents one at a time.
Each agent starts as a copilot: analysing and recommending. It can then progress to preparing actions for approval by a named person. Controlled autonomy comes later, for tasks with limited risk.
Progression depends on evidence. Before taking live action, the agent runs in shadow alongside the existing process, with its results measured against a number the business already tracks. Each increase in responsibility has to be earned.
Each stage ends in a decision. Each agent earns autonomy on evidence.
Snapshots, first connections, a plain go or no go.
Governed data, common identifiers and the decision record.
Safety and money as fixed checks.
Shadow run first, then live.
Nothing safety-critical is autonomous at the start. High-value spend, financial postings and safety decisions always need a person.
Keep the record through every change
Every agent run is recorded: what it read, which rule checks it passed, what it proposed, and who approved it. The record stays in your environment, giving a manager, an auditor, or a regulator a traceable account of how a decision was reached.
The model sits behind a replaceable interface. The design keeps agent definitions and the decision record independent of that choice, so changing the model does not require rebuilding them. A replacement model still has to pass the relevant evaluations before it is trusted with the same work.
The benefit accumulates. The second agent can reuse the connections and governed data layer established for the first. Each completed slice leaves the next one with less foundation work to do.
Choose the first slice from the workflow
Start with the workflow you want AI to support. Trace the data it reads and the functions it needs to call. That reveals which part of the application needs to change first.
A useful first capability has a clear boundary, a benefit the business can see within months, and limited financial or regulatory exposure. Core billing and payroll usually come later, once the team has established a reliable rhythm for migration, validation, and release.
The first slice should be narrow enough to understand fully and useful enough for the business to notice.
What the gradual approach costs
For a period, the old and new systems run alongside each other. Someone has to decide which system owns each record at every stage, how changes pass between them, and when that responsibility moves. This is often the hardest part of the work.
There is also a cost in discipline. The last parts of the old application tend to be the least interesting to replace. They can remain for years unless retirement is agreed early, with clear conditions for when each capability can be switched off.
A gradual approach makes the work manageable. It still requires someone to finish it.
Where we would start
We begin with five questions:
- Which workflow should AI support first?
- Where does the authoritative data live, and who is accountable for it?
- What should an agent be able to do, and what should it be unable to reach?
- Which capability has the clearest boundary?
- Who owns the routing layer?
The answers usually reveal a first slice that is smaller and safer than expected. They also give the work a practical shape: a sequence of releases, each with a defined boundary and evidence for the next decision.
If you are preparing a legacy application for AI, let’s look at the first workflow together: what it depends on, what needs to change, and how to modernise it without a full rewrite.