Switching software without losing your data

Nobody plans a migration badly on purpose. It goes wrong because the work is invisible until it is urgent: the export nobody tested, the attachments that turned out to be file paths, the balances that were migrated as invented historical transactions, the parallel run everyone quietly abandoned on day four.

This is the sequence that avoids most of it. It applies whether you are moving between two vendors, off a spreadsheet, or off paper.

Rule one: prove the export before you sign anything new

The whole migration rests on getting your data out of where it is now. Establish that first, in writing, while you are still a paying customer of the old vendor and therefore still interesting to them.

• Request a full export of every table in CSV or XLSX. Not a PDF report pack, which is a picture of your data rather than your data.
• Request attachments as actual files, in an archive, with a manifest mapping each file to the record it belongs to.
• Ask whether the audit trail — who changed what, when — can be exported at all. Often it cannot. Better to know now.
• Ask how long your data is retained after you cancel, and how long you have to retrieve it. Get a number of days.
• Ask whether any of this carries a fee.
• Get a named person and a date, by email.

What migrates cleanly, and what never does

Clean the data before you move it, not after

• De-duplicate in the old system. Merging two records is a decision that needs a human who recognises the names.
• Standardise phone numbers to one convention, including the country code. This is the field every later feature depends on, and the one most likely to be a mess.
• Standardise names: one spelling, one casing, initials handled the same way throughout.
• Define what "inactive" means, mark those records, and decide whether they migrate at all.
• Delete test records, staff-created dummy entries and the one customer called "asdf".
• Agree the unique key — the one field that identifies a record across both systems. Every reconciliation afterwards runs on it.

The parallel run

Running both systems side by side is the only honest test, and it costs real staff time on top of a normal working day. So make it short, make it narrow, and make one named person accountable for the comparison.

• Choose a period that includes at least one full billing cycle and one month-end close. A parallel run that never sees a close has tested nothing.
• Narrow the scope: one department, one counter, or one class of transaction entered into both. Do not attempt everything.
• Compare a small number of figures daily — the day's total collection, the count of transactions, and the closing balance. Three numbers checked every evening beats a full audit nobody does.
• Keep a written defect list with an owner and a severity against each item. Verbal defects get forgotten by Thursday.
• Agree in advance what "good enough to cut over" means, in numbers, so the decision is not made on the mood in the room.

Cutover

The first thirty days

• Keep the old system available and read-only. Resist every request to "just enter this one there".
• Delete nothing. Retention periods are set by your accountant and by your regulator, not by a software migration.
• Reconcile at day seven and again at day thirty, against the frozen closing figures.
• Keep the defect list alive and visible. A closed defect list after a week means people stopped reporting, not that everything works.
• Put the decommission decision in the diary as a dated meeting. Old systems otherwise stay licensed for years because nobody was willing to be the one who said stop.

The rollback you hope not to use

• Define the trigger before cutover: what specifically would make you go back? Write it as a sentence, not as a feeling.
• Name who decides, and make sure that person is not the one who chose the new vendor.
• Know what would have to be re-entered into the old system, and how long that takes.
• Keep the old system licensed until the rollback window closes — and decide that date in advance.

Written down like this, a rollback plan looks pessimistic. In practice it is the thing that lets everyone stay calm on day one, because the worst case has a name, an owner and a procedure instead of being an unspoken fear in the room.