Moving off a failing system, without losing anything.

When it is time to move

Systems rarely fail all at once. They become a risk a little at a time.

The UK government’s guidance on legacy technology lists the usual reasons to migrate: the cost of keeping the old system exceeds the cost of replacing it, it stops you making changes you need, the supplier no longer supports it, the contract is ending, or the risk of keeping it has become too great. For small organizations, add:

• Only one person knows how it works, or the person who built it has left.
• There are several copies of the same spreadsheet and nobody is sure which is right.
• The software no longer receives security updates. The US Cybersecurity and Infrastructure Security Agency lists using unsupported or end-of-life software among its bad practices. Microsoft, for example, ended support for Windows 10 and for Office 2016 and Office 2019 on 14 October 2025.

Take an inventory

You cannot move what you have not found.

The same government guidance puts it simply: build a complete and accurate register of your data, because the data is the real value of the system. Write down:

• The data: each kind of record, roughly how many, and how far back it goes.
• The people: who uses it, for what, and who owns it.
• The connections: imports, exports, mail merges, linked spreadsheets, reports sent to funders.
• The hidden jobs: automatic reminders, calculations, numbering, the macro that runs on Fridays. These are what break after a move.
• The paperwork: contracts, licences, notice periods and any documentation.

Export everything, in formats that will last

Get your data out while the old system still works and someone still knows how.

• Tables as CSV. The common format for tabular data is described in RFC 4180. Use UTF-8 so names with accents survive, and keep one header row.
• Structured or nested records as JSON (RFC 8259) where the system offers it.
• Attachments as files, with a list linking each file to its record.
• The things people forget: notes and history, audit logs, the list of users and roles, field definitions and drop-down lists, and the definitions of your standard reports.
• For the long term, prefer open, widely used formats. The Library of Congress’s Recommended Formats Statement is one published guide to formats suited to keeping material for the long term.

Spreadsheet traps

• Leading zeros disappear from postal codes, phone numbers and IDs.
• Long reference numbers turn into scientific notation and lose digits.
• Dates are reinterpreted: 03/04 becomes 3 April or 4 March depending on settings.
• Accented characters turn into nonsense when the file encoding is wrong.

Open CSV files through your spreadsheet’s import option and set those columns to text, rather than double-clicking them. Never save over the original export.

Clean and map before you move

Moving is the best chance you will get to fix your data. It is also the easiest time to break it.

• Work on a copy. Keep the original export untouched.
• Remove duplicates and standardise names, addresses, dates and categories.
• Leave behind what you do not need. Check your retention schedule: records past their period should be disposed of, not migrated.
• Map every field: old field, new field, and any change made on the way. Keep the mapping sheet; it is how you will answer questions later.

Rehearse, reconcile, run in parallel

Do the move at least once before you do it for real.

• A test load with a sample, then a full rehearsal with all the data.
• Reconcile the numbers: record counts by type, totals such as money received by year, and the open cases or active members. They must match, or you must be able to explain the difference.
• Check records end to end: people who know the data pick records they know well and compare old with new.
• Run in parallel for critical processes, such as payroll, donations or case allocations, for a short, defined period, and compare the results.
• Agree exit criteria in advance: what has to be true before you switch, and who decides.

Cut-over day

Plan the day so that the old system is a safe place to go back to until you are sure.

1. Freeze the old system.Make it read-only and tell everyone.

2. Take the final export.Load anything that changed since the rehearsal.

3. Reconcile again.Use the same checks as in the rehearsal.

4. Switch the connections.Forms, imports, reports and integrations now point at the new system.

5. Decide at a set time.Go ahead or roll back. Write down in advance who makes the call.

6. Support people closely.For the first weeks, keep a list of problems and how they were fixed.

Keep an archive

You will be asked about old records after the old system has gone.

• Keep the final full export and a backup of the original system, read-only, with restricted access.
• Add a short note describing the files and fields, so someone who was not there can understand them.
• Keep it for as long as your retention schedule requires, then dispose of it securely.
• Check that you can open it, then check again a year later.

Switch the old system off properly

An old system left running is an unwatched door.

• Remove every user account and revoke connections, API keys and passwords the old system held.
• Cancel the contract, and ask the vendor to confirm in writing that your data has been deleted. Our before you sign guide covers exit terms.
• Sanitise or destroy old servers, computers and drives following NIST SP 800-88 or the NCSC’s guidance on secure sanitisation.
• If the old system held personal information, people may still ask for it. The ICO describes a good export as structured, commonly used and machine-readable: your archive should let you answer.
• Update your inventory and documentation, and record the date the old system was switched off.