How to replace an application nobody wants to touch

Every estate has one. It runs something important, it was written a long time ago, the documentation is wrong, and the one person who understands it is close to retirement. Nobody wants to touch it, so nobody does, and the risk grows.

Recover what it does, from evidence

The documentation will be wrong and the people will describe what they think it does. Work from evidence instead:

• The data. The tables and what is actually in them, including the fields that are populated and the ones that were abandoned.
• The behaviour. What goes in, what comes out, what it sends to other systems.
• The exceptions. What the users do when it does not work — the workarounds are where the real requirements hide.
• The interfaces. Every other system that depends on it, including the ones nobody remembers.

This phase is slower than anyone wants and it is where the project is won or lost.

Expect to find that much of it is unnecessary

Applications accumulate. Features built for a business line that closed, reports for a regulator who changed the requirement, a whole module used by one person who left.

Going through this honestly usually reduces the replacement scope substantially. It is also the point where the project stops being a rebuild and becomes a redesign, which is a better outcome.

Interview the person who knows, properly

If the one expert is still there, this is the most valuable window available and it closes. Structured sessions, recorded, working through the system rather than talking about it in the abstract.

Ask specifically about the things that are not in the code: why a rule exists, what the strange exception handles, which customer the special case was for.

Replace in slices where you can

A big-bang cutover on a system nobody fully understands is the highest-risk option available. Where the architecture permits, take functions out one at a time — new service, old interface, traffic moved gradually — so each step is reversible.

Where it genuinely cannot be sliced, the answer is a longer parallel run with reconciliation, not a shorter one with optimism.

The data migration is the project

This is where the timeline goes. Decades of data with changing rules, records that predate a required field, encodings that mean something only if you know the history, and duplicates created before anyone checked.

Start the data work early and run reconciliation continuously rather than at the end. The decision about what to migrate and what to archive is a business decision and it should be made explicitly.

Keep the old system available, read-only

After cutover, keep the original accessible for long enough that questions can be answered. Someone will need a record from before the migration, and being able to look rather than to guess is what keeps confidence through the first quarter.

Why this is worth doing before it becomes urgent

The cost of this work roughly doubles once the person who understands the system has gone, and it triples if it is being done in response to a failure. The replacement is ordinary engineering. The reason it is expensive is almost always that it was left until the options had closed.