Data migration is where good system projects go to die. Not in a dramatic crash, but quietly: duplicate customers, mangled dates, invoices that won't reconcile, and a team that stops trusting the new system in week one because the data inside it is wrong.
Almost all of it is avoidable, because migration rewards preparation like nothing else in a software project. Here's the checklist we work through when moving data into a new CRM or business system, in the order that keeps you out of trouble.
1. Appoint an owner. One person with the authority to make decisions about the data. Migration by committee produces duplicates with opinions.
2. List every source. The old CRM, yes, but also the spreadsheets, the exports, the folder called "FINAL v3". If it holds records people rely on, it's a source, and finding it in month two is expensive.
3. Decide what not to migrate. Dead prospects from 2014 and half-filled test records don't deserve a ticket. Archive them somewhere safe and readable, and move on lighter. This decision alone can halve the work.
4. Define the target structure, then map to it. Agree what a customer, a job and an invoice look like in the new world, and write a field-mapping document: this column goes here, this one merges, this one retires. It sounds bureaucratic. It's the migration.
5. Profile before you clean. Look at what's actually in the fields, not what should be. You'll find dates in text columns, phone numbers in notes, and at least one surprise per source.
6. Agree duplicate rules in advance. Is "J. Smith" at the same postcode the same person as "John Smith"? Decide the rule once, apply it consistently, and you avoid relitigating it record by record.
7. Clean at the right stage, and protect the sensitive stuff. Fix data where it's cheapest, usually during transformation rather than by hand afterwards, and treat personal and financial fields with the care they legally deserve throughout.
8. Build a repeatable import. If the migration only works once, it doesn't work. A scripted, repeatable process means every trial run makes the real one safer.
9. Run trial migrations, then reconcile. Load a copy, put real users in front of it, and count: records in, records out, totals that must match. Reconciliation is what turns "it looks fine" into "it is fine".
10. Plan the cutover, keep a rollback. A defined moment when the old system stops being the truth, a short freeze while the final load runs, and an honest route back if something surfaces late. Then review after launch, because something small always surfaces, and catching it in week one keeps trust intact.
If you're replacing a spreadsheet-based operation, this pairs with our guide to retiring a critical spreadsheet safely: same philosophy, wider lens. And if the list above looks like more work than you fancied, that's rather the point. It's the work that makes launch day boring, and boring launch days are the ones we aim for.
Preparing a migration and want a second pair of eyes on the plan? That's a conversation we're always happy to have.
We're proud to have been recognised as Wales' Most Trusted Web Design & Development Company for 2025. This award reflects our commitment to delivering exceptional digital solutions and outstanding client service that sets the standard for excellence.
