Migrations go wrong in three predictable places: the export, the mapping and the cutover moment. Plan those and the rest is mechanical.
Free Forever • No Credit Card Required
Quick answer
Almost every difficult migration fails at the export, the mapping or the cutover. Data corruption during transfer is rare. What is common is discovering that the old system will not export call recordings, that two fields were mapped to the same destination, or that half the team spent Monday morning working in the wrong system.
Do this before you have committed to a date, because what you find determines the plan. Export contacts, companies, deals, notes, activities and attachments as separate files, and confirm that each child record carries the identifier of the record it belongs to. Notes without a contact identifier are unattachable, and discovering that on migration day is a bad experience.
Check the awkward items specifically: call recordings, uploaded documents, email history, and any field that stores multiple values. These are the ones that either export in an unusual format or do not export at all, and knowing which applies is the difference between a plan and a hope.
| Old field | New field | Transformation | Notes |
|---|---|---|---|
| Contact number | Phone, normalised | Strip spaces and prefixes | Deduplicate on this after transform |
| Status | Stage | Map each value explicitly | Old values often outnumber new stages |
| Remarks | Notes | Keep as free text | Only for open deals |
| Owner name | Owner user | Match by email address | Names do not match reliably |
| Custom fields | Decide per field | Convert free text to fixed lists | Drop anything unused for a year |
| Created date | Created date | Preserve if possible | Otherwise record migration date |
Write this out fully before opening any import screen. Every unmapped field is a decision that will otherwise be made in a hurry by whoever is doing the import, and mapping decisions made under time pressure are how a status field ends up as prose in a notes box.
Normalise phone numbers and email addresses, deduplicate on the normalised values, drop records with no contactable detail, and standardise the two or three fields you will filter on. Doing this in the export file is far easier than doing it in the new system, and it means your new database starts clean rather than starting with a cleanup project attached.
Import a hundred records covering the variety of your data: a contact with several deals, a deal with many notes, a record with an attachment, a record with unusual characters in the name. Then inspect ten by hand against the source. Because migration errors are systematic, ten records will reveal essentially every category of problem you have.
Pick your quietest window, usually a Friday evening. Freeze the old system to read-only at a stated time and tell the team. Run the full export fresh, since the test export is now days old. Import in the correct order: contacts, companies, open deals, then notes and activities. Verify counts and spot check. Then open the new system and confirm the team can log in before anyone needs it in anger.
The freeze is the part people try to avoid and should not. A few hours where nothing can be edited is a small cost. Two systems accepting edits simultaneously, even briefly, produces records that exist in both places with different content, and reconciling that afterwards takes longer than the entire migration.
Keep the old system readable for a quarter and say so, because the fear of having lost something is what makes people hesitate to commit to a new system. Watch for missing data reports in the first week and fix them centrally rather than asking people to re-enter. Stamp every migrated record with the migration date, which six months later makes it trivial to distinguish inherited data from anything created since.
Then leave the process alone for a month. The instinct after a successful migration is to start improving stages, fields and automations immediately, and doing so mixes migration problems with configuration problems in a way that makes both harder to diagnose. Let the team settle, then improve deliberately.
Related reading: switching from Zoho, switching from HubSpot, moving off spreadsheets, CRM alternatives, features, and book a walkthrough.
Every team in this space loses revenue to the same recurring gaps. Here is what they cost you and how HelloGrowthCRM closes each one.
The export produced files nobody can match up, so notes belong to nothing.
Export identifiers alongside every child record and map them explicitly. Notes, activities and attachments all need the record identifier they attach to.Export identifiers
The import created thousands of duplicates because number formats differed.
Normalise phone numbers and emails in the export file, deduplicate there, and run a small test import before committing the full file.Clean the file first
Halfway through cutover, some deals live in the old system and some in the new.
Freeze the old system at a stated time, migrate, verify, then open the new one. A short freeze is far cheaper than a week of split reality.Freeze, migrate, open
Nobody noticed until later that owner assignments did not carry across.
Verify by hand: ten records checked across every field type, including owner, dates and custom fields, before the team is let in.Manual spot check
AI-powered CRM with the features you need to close more deals.
Common questions about using HelloGrowthCRM in your industry.
Join small businesses that close more deals with HelloGrowthCRM.
Free Forever • No Credit Card Required
Free Forever • No Credit Card Required
Prefer email? Write to sales@hellogrowthcrm.com