Every transformation programme eventually reaches the same conversation.
The existing system is old. Changes take too long. Documentation is incomplete. Integration is difficult. The people who understand it are approaching retirement.
Someone suggests replacing it.
With AI now able to explain code, generate software, and assist with migration, replacement can appear more achievable than ever.
But before deciding how to replace a system, there is a more important question:
Do we understand what the business depends on it to do?
From a transformation consultant’s perspective, this is often the harder problem. An organisation may understand the limitations of its technology far better than it understands the business knowledge embedded within it.
Years of business decisions are inside the system
An established enterprise application contains more than code and data.
It contains decisions made over many years: how a customer qualifies for a benefit, how a financial exception is handled, how a transaction is reconciled, or how an institution interprets a particular policy.
Some of those decisions are documented. Others survive as conditional logic, database procedures, configuration settings, scheduled jobs, or manual workarounds.
A strange-looking calculation may exist because a contract requires it. A duplicated field may support a downstream reporting obligation. A batch process that appears unnecessary may close an operational gap nobody remembers discussing.
Some of this complexity is obsolete. Some of it remains essential.
The transformation challenge is to distinguish between the two.
Removing complexity before understanding its purpose can remove business capability along with it.
AI makes understanding more accessible—and verification more important
AI can help teams navigate unfamiliar code, summarise modules, identify dependencies, and generate hypotheses about business rules.
That creates a valuable opportunity. Work that previously required painstaking inspection can become easier to explore.
However, a plausible explanation of code is not the same as a verified explanation of the business.
A model may describe what a function does without knowing why it exists. It may infer the meaning of a field from its name even though the field has been repurposed. It may explain a workflow while missing a manual step performed outside the application.
The quality of the analysis depends on the evidence available.
Source code is one source. Production behaviour, transaction records, configuration, support tickets, operating procedures, and conversations with experienced users provide others.
AI-generated interpretations should become questions to investigate, not facts to migrate unquestioned.
Start with the business journey
Modernisation assessments often begin with a technology inventory: applications, languages, databases, interfaces, and infrastructure.
That inventory matters. It does not reveal the full operating model.
A more useful starting point is a business journey.
Follow a customer request, an insurance claim, a purchase order, or a student admission from beginning to end. Identify where information enters, which decisions are made, where approvals happen, and what must be true before the process is complete.
Then examine how the existing systems support that journey.
This approach exposes dependencies that an application-by-application assessment can miss.
A transaction may be technically complete in one system while still waiting for reconciliation in another. A successful status may depend on an overnight job. An employee may correct an exception in a spreadsheet before anyone notices it.
The application boundary rarely matches the business boundary.
The workarounds are part of the current system
Ask an experienced user how a process works, and the answer often includes a sentence such as:
“Normally, we do this. But in these cases, we handle it differently.”
Those exceptions deserve attention.
They may reveal a missing capability, an outdated policy, a data quality problem, or a legitimate business requirement the application never fully supported.
During transformation, manual workarounds are sometimes treated as noise to eliminate. Yet they can contain the clearest evidence of how the organisation actually operates.
A new platform that reproduces the documented process but ignores the real exceptions may look complete in testing and fail immediately after launch.
The consultant’s role is to make those exceptions visible and help the business decide which should be supported, redesigned, or retired.
Understand before giving an agent access
Enterprise AI often increases the importance of understanding existing systems.
An AI agent may retrieve information from an established application, recommend an action, or invoke an interface to update a record.
To do that reliably, it needs accurate meanings and clear boundaries.
What does “active customer” mean? Does an available balance include pending transactions? Can a status change be reversed? Is the interface safe to retry? Does updating one record trigger changes elsewhere?
These questions cannot be answered from an API description alone.
An agent connected to a poorly understood system can act quickly while making assumptions that experienced employees know to avoid.
Before enabling actions, teams need to establish the business meaning of the data, the preconditions for each operation, and the consequences of failure.
The existing system may remain central to the enterprise. The AI layer must respect its operating rules.
Replacement is one possible outcome
A transformation assessment should produce a reasoned decision about each capability.
Some capabilities may be stable, dependable, and worth retaining. Others may benefit from a new interface or integration layer. A particular workflow may need redesign. An unsupported component may require replacement.
The right choice depends on business value, operational risk, change frequency, and the cost of maintaining the capability.
A complete rewrite can be justified. It should not be the automatic conclusion of discovering old technology.
Understanding the system gives the organisation more choices. It allows investment to target the constraints that matter, instead of treating every component as equally urgent.
Validate outcomes, including the awkward cases
Modernisation success is often described in technical terms: a newer platform, a cleaner architecture, faster deployment, or reduced infrastructure costs.
The business also needs evidence that its essential outcomes still work.
Can invoices be reconciled correctly? Are historical records interpreted consistently? Do permissions preserve the intended access? Can the system handle reversals, incomplete transactions, and unusual exceptions?
Representative historical cases can help establish a baseline. Differences between old and new behaviour should be investigated and classified.
Some differences will be intentional improvements. Others will reveal requirements that were never captured.
The objective is to preserve the capabilities the business still needs while changing the behaviour it has deliberately chosen to improve.
Understanding is a transformation asset
One of the most valuable outputs of a transformation programme is a shared, verified understanding of the business and its systems.
That understanding should survive beyond the project—in clear business rules, data definitions, dependency maps, decision records, and meaningful validation cases.
AI can help create and maintain these assets. Business and technical owners still need to verify them.
Without that investment, an organisation can replace its technology and recreate the same knowledge problem on a newer platform.
Legacy systems continue to matter because enterprises continue to depend on the capabilities and decisions they contain.
The first transformation task is to make those dependencies understandable.
Only then can the organisation decide confidently what to retain, what to change, and where AI can make a useful difference.
