The worst thing about a failed CRM data migration is that it rarely looks like a failure. The import finishes, the record count looks right, and weeks later someone notices that a batch of contacts has no phone number or no owner.
That quiet loss is the thing to design against. A sound CRM data migration is ordered around it: decide what moves, clean it, map it, test a small batch, and then check the result field by field rather than by row count.
Why CRM data migration loses data without telling you
Import tools are built to finish. When a value doesn't fit its destination field, many of them keep the record and drop the value, which is far friendlier to the person clicking Import than to the person who needs that value in March.
HighLevel's own bulk import troubleshooting guide is explicit about this. For an invalid phone number, an unparseable date, an unknown dropdown option or an ambiguous owner name, its documented outcome is that the record imports without that value.
Only a handful of problems stop the whole import, such as a file with more than one sheet. Those are the easy ones, because you know immediately.
So the working assumption for any move is simple. A green "import complete" message tells you the rows arrived. It says nothing about whether the fields did.
Decide what moves before anything moves
Not every record deserves a place in the new system. Contacts nobody has touched in years, test entries and abandoned deals all cost you cleanup time on the way in and clutter every report afterwards.
Settle the scope of the CRM data migration in writing: which objects (contacts, companies, deals, notes, tasks), and how far back.
Then take a full export of the old system before you change a single thing in it, and keep that file untouched. It's your rollback plan, and it's also the reference you'll compare against later.
If your new platform is GoHighLevel, our walkthrough on migrating a CRM to GoHighLevel without losing data covers the platform-specific order of operations.
Clean the source data first
Fix problems where they start. HubSpot's CRM data migration pilot checklist puts "clean source data or clean export" as an early step, before any mapping happens, and the order is right: a CRM data migration mapped on messy data has to be re-mapped when the mess is found.
Three cleanups pay off most:
- Merge duplicate contacts and companies, so the new system doesn't inherit two histories for one person.
- Standardise phone numbers with a country code, and pick one date format for every date column.
- Replace free-text values with the exact options the destination dropdown will accept.
The third is the one people skip. If the old system let anyone type "Referral", "referral" or "Ref." into a source field, the new one has to be told which of them is canonical before the import, not after.
Map objects first, then fields
HubSpot's checklist sequences the work deliberately: define the object mappings first, then the field mappings. Contacts, companies and deals are each their own object, and how they relate has to be settled before you decide where individual columns land.
Choose one unique identifier per record
Duplicates during a move come from matching, not typing. HubSpot's import file requirements say that to update existing records or avoid duplicates you need a unique identifier, which for contacts is the email address and for companies can be the domain name.
The same page adds the consequence for linked data: without unique identifiers on each side of an association, the import creates duplicates instead of linking existing records. Contacts to companies, deals to contacts, notes to deals: every link needs a key that exists in both files.
Keep the old system's record ID in a column and carry it into a custom field in the new one. It costs a field and saves you when someone asks in six months where a contact came from.
Match the destination's formats exactly
The format rules are specific and they differ by platform. HubSpot accepts phone numbers as a plus sign, country code and number, wants multiple-checkbox values separated by semicolons with the options already created, and requires dropdown values to match an option's label or internal value.
HighLevel is similar. It expects phone numbers in E.164 format, and a date that doesn't match the format you selected during import is dropped, as the troubleshooting guide describes.
Two other details are worth writing into the map. HubSpot says to use an owner's email rather than name when names are duplicated, and it notes that blank cells in an import are ignored rather than clearing existing values. That second rule matters when you re-run a corrected file over records that are already loaded.
Write the transformations down
Anything that changes between systems belongs in the map: a single name field split into first and last, a status renamed, a stage collapsed into another. If it only lives in someone's head, it can't be reviewed, and nobody can explain a surprising value later.
Run a pilot import and read it properly
A pilot run of your CRM data migration is a small import you can afford to throw away. HubSpot's checklist makes it the seventh of eight steps and says what to review afterwards: imported test records should show correct field mappings, correct associations and correct engagement data.
Pick the sample on purpose. Include the strange ones: a contact with two emails, a company with ten contacts, a deal with a long note history, a record with an accent in the name. A random handful of tidy records passes everything and teaches you nothing.
Then open each pilot record next to its source and compare fields one at a time. Counting rows isn't a test.
One practical safeguard: tag everything you import with a batch label, if the platform allows it. A tag gives you a clean way to find, review or remove a batch if the pilot goes wrong, though you shouldn't treat it as an undo button.
Silent failures to check for, by error code
These are the HighLevel outcomes from the official error list where the import carries on and you lose something. Every platform has its equivalents, so read the destination's own list before you start.
| Error code | What triggers it | What you lose |
|---|---|---|
| 1002 | An owner name matches more than one user | The Owner field stays blank |
| 1005 | A dropdown or checkbox value isn't an existing option | The record imports without that value |
| 1013 | A phone number isn't in E.164 format | The record imports without a phone number |
| 1014 | A date doesn't match the selected format | The record imports without that date |
| 1011 | The same unique value repeats in the file | Duplicates may exist and association didn't occur |
Phone numbers are the one to watch for a business that sells by phone. A contact without a number is still a contact in every report and a dead end in every workflow.
Verify the full load against the source
Once the full CRM data migration has run, compare the new system with the export you saved at the start. Row counts come first, but they're the weakest check; follow them with field-level counts, such as how many contacts have a phone number in each system.
Those counts expose the silent failures above directly. If the old system had a phone number on most contacts and the new one has far fewer, error 1013 has been at work, and you know which column to fix.
Next, spot-check linked data. Open a handful of companies and confirm the right contacts and deals sit under each, then open a deal and look for its notes and activity. HubSpot's checklist asks for the same thing at pilot stage, and it's worth repeating at full scale because a different file can behave differently.
Last, test the automations that depend on migrated fields. A workflow triggered by a tag, a stage or an owner only proves itself on real records, and a sequence that quietly never fires is the kind of loss you won't notice for weeks.
Plan the cutover and keep the old system readable
A CRM data migration needs a cutover date. Freeze changes in the old CRM when you take the final export, or agree a short window in which updates are logged by hand. Records edited after the export are the ones that go missing in the move, because nobody remembers to carry them across.
Leave the old system in read-only mode for a while instead of cancelling it on cutover day. When someone finds a gap, you want to look at the original rather than a CSV.
If you want the connections rebuilt as well, such as forms, calendars, payments and follow-up sequences, that wiring is a separate job from the data move, and it's where AI and automation work pays off, and for a custom build rather than an off-the-shelf CRM there's our apps and SaaS development practice. If you're still choosing the destination, the GoHighLevel and HubSpot billing comparison shows how the two charge.
And finish by keeping your pilot map. The next move, or the next tool added to your stack, will start from a tested template instead of a blank sheet.
Frequently asked questions
How do I avoid duplicates when importing into a new CRM?
Merge duplicates in the old system first, then import with a unique identifier such as email. HubSpot's documentation says a unique identifier is what lets an import update existing records instead of creating new ones.
Should I migrate every record from my old CRM?
No. Decide scope up front and leave out test entries and records nobody will use. Keep a full export of the old system either way, so anything you left behind can still be found.
What should I test before running the full import?
Run a pilot on a small, deliberately awkward sample and check field mappings, associations and activity history record by record. That mirrors the review step in HubSpot's pilot checklist.
Why did my contacts import without phone numbers?
Most likely the numbers weren't in the format the platform expects. In HighLevel, a phone value that isn't in E.164 format triggers error 1013, and the record imports without a phone number. Correct the file and re-import.
Can I undo an import if something goes wrong?
Not reliably on every platform, which is why you tag imported records and keep the original export. Check your destination's current documentation before the full load, and rehearse the pilot first.
Cover photo by Mikael Blomkvist on Pexels
Sources
- CRM Data Migration Pilot Checklist — HubSpot
- Set up your import file — HubSpot Knowledge Base
