To migrate to a new system without losing customer data, take a full backup, list every data source, map each old field to a new one, clean and de-duplicate before moving anything, run at least one trial migration, check the results against the source, then switch over on a planned date with a rollback option. Most data loss happens when teams skip the trial run.
Migration is the least glamorous part of any new CRM, ERP or custom platform, and the part most likely to go wrong. The new system can be excellent and still fail if the team opens it on day one and can't find their clients, or finds them with half their history missing.
What usually gets lost in a migration?
Rarely whole records; usually the context around them. Names and phone numbers survive. Notes, history, attachments and relationships between records are what quietly disappear.
Watch for:
- Notes and activity history: years of call notes stored in a field the import ignores.
- Attachments: contracts, photos and quotes that live outside the main export.
- Relationships: which contacts belong to which company, which invoices to which deal.
- Custom fields: the "how did you hear about us" field someone added years ago.
- Consent records: who agreed to marketing messages, and when.
- Dates: created dates reset to the import date, wrecking every report that depends on age or trend.
- Owners: every record assigned to whoever ran the import.
What are the stages of a safe migration?
Seven stages, and the early ones take longer than the actual data move. The timings below are typical for a small or mid-size business moving a CRM; complex ERPs take longer.
| Stage | What happens | Typical share of effort |
|---|---|---|
| 1. Backup | Full export of every source, stored safely and untouched | Small |
| 2. Inventory | List every place customer data lives, including spreadsheets and inboxes | Medium |
| 3. Mapping | Match each old field to a new field, decide what's dropped | Large |
| 4. Cleaning | Fix formats, merge duplicates, archive dead records | Large |
| 5. Trial migration | Load a copy into a test version of the new system | Medium |
| 6. Validation | Compare counts, spot-check records, have users test | Medium |
| 7. Cutover | Freeze the old system, run the final migration, go live | Small, but scheduled carefully |
Never clean data in the only copy. Stage 1 exists so every later step can be redone if it goes wrong.
How do you find all the data that needs moving?
Ask every team where they look things up, not just which system is "official". The real data estate is almost always bigger than the system being replaced.
In businesses moving off spreadsheets, customer data typically lives in several copies of a master sheet, personal phone contacts, WhatsApp chats, email threads, the accounting package and a forms tool. If that sounds familiar, our checklist of signs you've outgrown spreadsheets will feel close to home.
For each source, record: what it holds, roughly how many records, who maintains it, how it can be exported, and whether it should be migrated, archived or left behind. Where a system can't produce a clean export, an API can often extract the data properly; our explainer on what an API is covers why that matters.
How should old fields map to the new system?
Build a mapping sheet with one row per old field, and get the people who use the data to sign it off. This is where business decisions get made, so don't leave it to the developer alone.
| Old field | New field | Transformation | Decision |
|---|---|---|---|
| Customer Name | First name + Last name | Split on first space; review exceptions | Migrate |
| Mobile | Phone | Add country code, strip spaces | Migrate |
| Status ("hot", "warm", "maybe") | Pipeline stage | Map to defined stages; "maybe" becomes Contacted | Migrate |
| Notes (one long text field) | Activity timeline | Import as a single dated note | Migrate |
| Fax | (none) | — | Drop |
| Source (free text, 40 variations) | Lead source (fixed list) | Group into 8 standard sources | Migrate |
| Marketing opt-in + date | Consent record | Keep original date | Migrate |
Keep the old system's record ID in a hidden field in the new one. When a question comes up months later, you can trace any record back to where it came from.
How do you clean and de-duplicate safely?
Standardise formats first, then match duplicates on reliable keys, then merge with a person reviewing borderline cases. Automated merging without review causes its own data loss.
- Standardise: phone numbers with country codes, lowercase emails, consistent city and state names.
- Match: exact matches on email or normalised phone are safe to merge; fuzzy name matches need a human.
- Merge rules: decide which value wins (usually the most recently updated) and keep the losing values in a note rather than discarding them.
- Archive, don't delete: records with no activity for years can go into an archive file rather than the new system, but keep them.
Big bang, phased or parallel: which cutover is safest?
For most small and mid-size businesses, a planned big-bang cutover over a weekend, after a successful trial, is simplest and safest. Running two systems in parallel sounds cautious but often creates two sets of half-updated data.
| Approach | How it works | Pros | Cons | Best for |
|---|---|---|---|---|
| Big bang | Everyone switches on one date | Clean break, one source of truth | Needs a solid trial and a rollback plan | Most SMB CRM moves |
| Phased | Move one team, region or data type at a time | Smaller risk per step | Temporary integrations between old and new | Larger or multi-site businesses |
| Parallel | Both systems run for a period | Easy to compare | Double entry; data drifts apart | Finance systems where reconciliation is required |
Whichever you choose, freeze changes in the old system before the final migration, then make it read-only rather than switching it off. Keep it available for reference for an agreed period.
How do you prove nothing was lost?
Check counts, check samples and let real users check their own records. All three catch different problems.
- Counts: total contacts, deals, invoices and notes in old versus new, broken down by status and owner.
- Totals: sums of invoice values and open pipeline value should match.
- Spot checks: pick 20–30 records at random plus your ten most important clients and compare every field.
- User acceptance: ask each salesperson to find five of their own clients and confirm the history looks right.
- Links and references: check that anything pointing at the old system has been updated.
That last point catches people out. On grww.tech we found and fixed canonical tags that still pointed at an old domain, a reminder that references to the old world linger in places nobody thinks to check. In a CRM migration the equivalent is email templates, automations and integrations still sending data to the old system. Our explainer on custom integrations covers how to re-point those connections.
What about privacy during a migration?
Treat migration files as the most sensitive data you own, because they're complete copies of it. A spreadsheet export of your whole customer base on someone's laptop is a serious risk.
Limit who handles exports, store them encrypted, delete working copies once the migration is signed off, and set up permissions in the new system before loading data, not after. Our guide to role-based access and permissions covers that design. India's DPDP Act 2023 and Australia's Privacy Act 1988 both expect reasonable safeguards for personal data, and a migration is a moment when those safeguards are easiest to forget.
How much does migration cost?
For a straightforward CRM move it's often part of the new system's build; complex or messy data turns it into a project of its own. The biggest cost driver is data quality, not volume.
As a typical estimate, a standalone migration with significant cleaning and multiple sources sits within the simple internal tool range, around US$6k–20k, ₹1.5–5 lakh or A$10k–30k, depending on scope. Budget it explicitly when comparing options. Our breakdown of custom CRM vs HubSpot vs Zoho vs Salesforce is a useful companion, and our guide to business systems that scale puts migration in the context of the whole systems roadmap.
Frequently asked questions
How long does a data migration take?
For a small business moving one CRM with reasonably clean data, a few weeks including mapping, cleaning and a trial run is common. Multiple sources, heavy duplication or an ERP with financial history can take much longer.
Should we migrate all our old data?
Not necessarily. Migrate active customers, open deals and the history people genuinely use, and archive the rest in a searchable export. Moving years of dead records just clutters the new system.
Can we keep using the old system during migration?
Yes, until the final cutover. Freeze changes shortly before the final run so nothing is created in the old system after its data has been copied, then make it read-only.
What if the old vendor won't give us a full export?
Check your contract and the vendor's export and API options first. If those fall short, records can sometimes be extracted through reports or, as a last resort, screen automation. Ask about exit routes before signing with any new vendor too.
Who should own the migration on our side?
One person who knows the data and has authority to make decisions about mapping and cleaning. Developers can move data, but only someone in the business can decide what "Status: maybe" should mean in the new system.
Planning a move to a new system?
We plan and run migrations as part of the systems we build, with trial runs and validation before anyone switches over. See our services or get a fixed-price quote.