Reviving a legacy system without losing what it knows

Somewhere in most established businesses there is a system that everyone works around and nobody wants to touch. It might be the accounting package two versions behind support, the database a contractor built in 2009, the scheduling tool that only runs on one machine in the back office, or a spreadsheet that has quietly become software. It works. That is exactly the problem: it works well enough that replacing it never reaches the top of the list, and every year the number of people who can explain it goes down by one.

This guide is for the moment that changes — a retirement, an audit question, a vendor ending support, or a project that finally requires the old system to talk to something new. The goal is not to admire the old system or to rip it out. It is to read it, prove you read it, and replace its parts on purpose, without losing the business rules it has been enforcing all along.

“Legacy” is not about age

A system is not a problem because it is old. Double-entry bookkeeping is five centuries old and still correct. Your general ledger structure may be twenty years old and still exactly right.

A system becomes a problem when it is unread — when the reasons behind it are no longer written down anywhere and no longer live in anyone’s head. That distinction decides everything downstream, because an unread system cannot be safely changed, integrated, migrated, or handed to anyone new. You end up in one of three positions:

• Old and understood. Someone can explain every rule and where it came from. Low risk, and modernize on your own schedule.
• Old and unread. It runs, nobody can say why it does half of what it does, and every change is a gamble. This is the expensive one.
• Not that old and already unread. More common than people expect. A three-year-old custom build whose developer moved on is legacy by this definition.

If you are in the second or third position, the work below comes before any migration quote you accept.

This is not a small-business problem only

It helps to know the scale you are operating at. In July 2025 the United States Government Accountability Office (GAO) examined the eleven federal systems most in need of modernization and put them at about 23 to 60 years old; eight of the eleven still run on legacy programming languages, which GAO describes as languages that “have a dwindling number of people available with the skills needed to support them.”

If organizations with unlimited budgets carry systems like that, a business with twenty or two hundred people carrying one is normal, not negligent. What separates a manageable situation from an expensive one is whether anybody has written down what the system knows.

Step 1: Map what you actually have

Before any vendor conversation, build a one-page inventory. One row per system that the business would notice if it stopped. Five columns, and the fourth is the one that matters:

Anywhere the fourth column holds one name, you have a single point of failure that no backup protects, because what is missing is not data. Anywhere it holds no name at all, you have a system that can only be changed by experiment.

That column is your real risk register, and it tends to be short and alarming. Sort your list by it, not by age or by how much you dislike the software.

Step 2: Interview the people who remember, while they are still reachable

The system records what was done. The reasons went home with whoever did it. When you can still reach that person — on payroll, on a consulting retainer, or just willing to answer email — two or three recorded conversations are the cheapest insurance you will ever buy.

Ask for the why, not the how. The how is in the software and you can read it. Useful questions:

• What breaks if this runs an hour late? A day late? Not at all?
• Which fields hold something other than what their name suggests?
• What do the status codes mean, who decided, and is that still true?
• What did you decide not to build, and why?
• Who reads this report, and what do they do on the day it is wrong?
• What would you tell the next person before they change a single line?

Write the answers in plain text and keep them with the system’s documentation, not in someone’s inbox. Note who said what and when. An afternoon of this, recorded, is worth more than a month of reverse-engineering later, and it is also a courtesy: it says their judgment mattered, which it did.

Step 3: Decide what “the same” means before you move anything

This is the step most migrations skip and most migration disputes come back to. Before you replace anything, write down the specific numbers that must agree between the old system and the new one, and to what tolerance.

For a financial system that usually means a trial balance that ties out, an accounts receivable aging that matches to the penny, and an inventory valuation that agrees on the same date. For an operational system it might be order counts by status, or the same shipping labels for the same orders.

Then run both systems on the same data and compare, more than once, before anyone sets a cutover date. The first clean match is the real milestone — not the go-live party. It is the only evidence that the new system understood the old one rather than merely replaced it.

This is how a manufacturer moved [[From Mfg/Pro to QAD Enterprise Edition without losing data]]: trial migrations reconciled back to the old system until the numbers agreed, so go-live was an anticlimax. That is the goal. A migration with no defined tie-out is a translation nobody checked.

Step 4: Separate the idea from the housing

Old systems hold two very different things, and modernization goes wrong when a project treats them the same.

Interrogate every rule with one question: is this old because it is right, or old because nobody has looked? Carry the first kind forward deliberately. Replace the second kind deliberately. A modernization that discards the ideas along with the housing rebuilds, at current prices, the mistakes the old system already solved.

Step 5: Replace one piece at a time, with a way back

You do not need a weekend where everything changes at once, and you should refuse any plan that requires one. The established alternative is to put a modern layer in front of the old system and move one capability at a time behind it, so the old and new run side by side until the old one handles nothing. Martin Fowler’s description of the strangler fig application is the clearest statement of why incremental beats big-bang.

In practice, for a business owner, that means asking for three things in any modernization plan:

1. A first slice that is small and reversible. One report, one interface, one workflow. Shipped, watched, and kept if it holds.
2. A period where both systems answer the same questions and every disagreement is written down. Silence here is what earns the cutover, not a demo.
3. A rollback that costs nothing. If going back requires a deployment, a data migration, or a meeting, it is not a rollback. It should be a setting.

The deep version of these patterns, for the practitioner doing the work, is in [[Integration architecture: APIs, events, legacy]].

Step 6: Leave it readable for whoever comes next

Everything you build this year becomes somebody else’s old system. The difference between one that gets modernized smoothly and one that gets guessed at is not the technology. It is whether the reasons were written down where the next person will look.

At minimum, when the project is done, you should own: a one-page diagram of what talks to what, a short runbook covering how to run it, how to check it is right, and how to roll it back, and a record of every non-obvious decision with the reason and the alternatives that were rejected. Ask for these as deliverables in the contract, not as a favor at the end.

What this costs, and what to demand from a vendor

The reading work is much cheaper than people fear, and skipping it is what makes migrations expensive.

• The inventory is a couple of days of someone’s attention, mostly asking questions.
• The interviews are a few hours each, and they expire when the person does.
• Defining the reconciliation is typically days, and it is the highest-return step on this list.
• The migration itself is where the real money goes, and its range depends entirely on how much of the above was done first.

When you put the work out to a vendor, four questions separate a serious proposal from an optimistic one:

• What is your plan for finding out what the current system does, and how many days is it?
• Which numbers will you reconcile, on which dates, and how many times before cutover?
• What is the first slice, and how do we roll it back?
• What documentation do we own at the end, and can we see an example from another engagement?

A proposal that answers all four is a plan. One that goes straight to a platform and a go-live date is a quote with the risky part left out.

Watch-outs

• “We’ll document it after go-live.” Nobody ever does, and by then the people who knew are gone. Documentation is a deliverable with a date, or it does not exist.
• Trusting an assistant’s reading of an old system. Artificial intelligence (AI) tools are genuinely good at explaining unfamiliar code and terrible at knowing what they cannot know. They produce fluent, confident, plausible accounts of what a system means, and the wrong ones look exactly like the right ones. Use them to generate questions fast, then confirm every answer against a real run or a real person.
• Rebuilding the workarounds. The spreadsheet that exists because the old system could not do something is not a requirement. Ask what it is compensating for before you recreate it.
• One-person projects. If the same person maps, migrates, and verifies, the verification is worth nothing. Whoever checks the tie-out should not be the person who built the new thing.

Your next step

If you are staring at a system whose only reader is planning a farewell lunch, or at a migration quote with no reconciliation in it, the useful next move is smaller than a project: map the strata and write down what the system knows while someone can still confirm it. Our [[IT strategy]] work starts exactly there. Tell us what is in the oldest layer and we will help you read it before you replace it.