The reason most businesses put off switching systems
It's rarely the new system that worries people. It's the old one — specifically, everything sitting inside it. Ten years of invoices. Every customer note since the business started. Job histories that prove work was done to a standard, in case anyone ever asks. The thought of that disappearing, or turning into a mess of duplicate contacts and missing dates, is enough to keep businesses on software they've outgrown.
That hesitation is reasonable. A badly handled migration can genuinely lose information, break reporting continuity, and create weeks of manual clean-up. A well-handled one doesn't have to be risky at all. The difference is almost entirely in the preparation.
What actually gets lost in a bad migration
Most data loss during a system switch isn't dramatic. It's quiet and it shows up months later.
- Customer history gets flattened. Contact details move over, but the notes, past jobs and communication trail don't — so staff are suddenly dealing with customers as if they're new.
- Financial records lose their audit trail. Invoices import as numbers with no link back to the job, quote or customer they belonged to.
- Duplicates multiply. The same customer exists under three slightly different spellings across old spreadsheets, and all three come across as separate records.
- Dates and statuses get scrambled. A job marked "complete" in one system becomes "open" in the new one because the status fields don't match up.
- Attachments and documents go missing. Photos, signed contracts and compliance certificates often live outside the main system and get forgotten entirely.
None of this is inevitable. It happens when data gets moved without a proper plan for how the old structure maps onto the new one.
Before you move anything: audit what you actually have
Migration goes wrong when businesses assume they know what's in their old system. Start by listing where information actually lives — because it's rarely in one place.
- The CRM or contact database
- The accounting package
- Job or project spreadsheets
- Shared drives full of PDFs, photos and signed paperwork
- Individual staff inboxes, where a surprising amount of business history quietly sits
Once you know where the data is, decide what's actually worth bringing across. Not everything needs to move. A supplier you haven't used in six years doesn't need a migrated record — but a customer with an active contract absolutely does.
A practical migration checklist
1. Map your fields before you touch the data. Work out how customer names, job statuses, invoice numbers and dates in the old system correspond to fields in the new one. This single step prevents most of the scrambling that happens during a rushed move.
2. Clean duplicates at the source, not after. It's far easier to merge three versions of the same customer while they're still in the old spreadsheet than to untangle them once they're live in a new system with jobs and invoices attached.
3. Decide how far back you need full detail. Most businesses don't need granular data from a decade ago — they need it to exist, searchable, in case it's needed. Recent history (typically the last two to three years) usually needs to be fully active and linked; older records can often be archived rather than fully rebuilt.
4. Keep financial records intact and traceable. Invoices, payments and job costs should move across linked to the customer and job they relate to, not as a standalone list of numbers. This matters for cash flow reporting and for anyone checking figures later — always confirm treatment of historical VAT and tax records with your accountant or current HMRC guidance.
5. Don't forget the documents. Photos, signed quotes, compliance certificates and contracts need a migration plan of their own. If they're not attached to the record they belong to, they become unfindable within weeks.
6. Run both systems in parallel briefly. Before switching off the old system entirely, check that a sample of migrated records — a mix of old and recent, big and small — matches exactly. Spot-checking catches problems before they become permanent.
7. Keep a read-only copy of the old system. Even after a clean migration, keep the legacy system accessible (even if just for viewing) for a defined period. It's a safety net, not a sign the migration failed.
Why this matters more than it looks like it does
Historical data isn't just a record of the past — it's what makes a new system useful on day one. A CRM with no job history behaves like a stranger meeting your customers for the first time. Accounts without linked invoice history can't produce a proper year-on-year comparison. A migration that only moves the surface data leaves the new system looking complete while actually being hollow.
Done properly, migration is also a chance to fix problems that had built up in the old system for years — duplicate contacts, inconsistent job naming, invoices that were never quite linked to the right customer. It's far easier to clean this up once, during a planned move, than to keep patching around it indefinitely.
How this fits into moving to N Six Hub
This is exactly the problem Migration AI is built to handle — mapping your existing customer records, job history and financial data into CRM, jobs and projects and accounting as connected records rather than disconnected imports. The aim isn't just to move data, it's to move it so that history, jobs and invoices stay linked the way they were meant to be, inside one platform instead of scattered across the tools you're leaving behind.
Next step
If you're weighing up a move away from spreadsheets or legacy software, start by mapping where your data actually lives — then talk through what a proper migration looks like at /migration.