Leaving legacy software without losing your data

Ask why a business is still on software that everybody complains about and the answer is almost never that it works well. It is that the alternative involves moving twelve years of records, and nobody wants to be the person who lost a year of history.

That fear is rational. Migrations do go wrong. But they go wrong in a small number of predictable ways, all of which can be designed out.

Get the data out before you decide anything

The first job is not choosing the new system. It is establishing whether the old one will let go of your data at all, and in what state.

Export everything you can, early, before any commitment. You are looking for three things: whether an export exists, whether it contains the fields that matter, and how bad the contents are. Doing this first is what turns migration from an unknown into a scoped piece of work, and occasionally it changes the plan entirely, because a system that cannot export cleanly needs a different approach.

Decide what genuinely has to move

Not all of it should. Instinct says bring everything, because everything feels like it might matter. That instinct makes the migration larger, slower and riskier for records nobody will open again.

A workable split:

• Migrate: anything operationally live, plus the history you routinely refer to. Usually two to three years for most businesses.
• Archive as searchable records: older history you must be able to produce on request but never work with.
• Archive as-is: everything else, kept in a labelled export you can restore if you ever need it.

This one decision typically removes most of the volume and most of the risk, and it costs nothing except a conversation about what you actually use.

Agree the cleaning rules in writing

Old data is messy in specific ways: the same customer entered three times with different spellings, dates in two formats, a notes field that people used for structured information because there was nowhere else to put it.

Every one of those needs a rule, and the rule needs to be yours, not the implementer's guess. Which of these three duplicate customers is the survivor? When a required field is empty, does the record get flagged for a human or filled with a default? These decisions look small and they determine whether the new system starts trustworthy.

Reconcile with control totals

This is the step that converts hope into evidence, and it is the step most often skipped. Before the migration, take counts and totals from the old system: how many customers, how many open jobs, the sum of outstanding invoices. After the migration, take the same numbers from the new one.

They should match exactly, and where they do not, every difference should be explained by a rule you approved. Insist on seeing this as a document you can read. A supplier telling you the migration went fine is not the same as a report showing that it did.

Run in parallel, and rehearse the switch

Keep the old system readable, not writable, for a period after go-live. Readable costs almost nothing and removes the fear entirely, because any question about what the old system said can be answered by looking. Writable is what you must avoid, because two live systems means two versions of the truth within a week.

Then rehearse. Do the full migration on a copy, time it, and have your team work in the result for a day on real data. The rehearsal is where you find the exception nobody mentioned. Finding it on a Tuesday rehearsal is a note. Finding it during the real cut-over is a crisis.

None of this is clever. It is just deliberately unexciting, which is exactly what you want from a migration. Done this way, the cut-over is a day when the team logs into a different address and the numbers still add up.