A safe CRM data migration starts by counting everything before you import: inventory the full export, and match every dropdown value against the new system’s options first. In one contact migration into Coevera (formerly Pipeliner CRM), skipping that check would have left a single status field blank on 579 of 3,432 records, 17%, with no error at all.
The problem: migrations fail without telling you
On paper, moving contacts is a mapping job: decide which old column goes into which new field, press import, move on. The system even tells you it worked.
Structural problems, like a broken row or a malformed email address, get caught. Value problems do not. When a dropdown value in the old system has no matching option in the new one, the record still imports, and that one field lands empty. Later, nobody can tell a value that was lost from one that never existed.
For a sales leader, this is not a technical detail. Ownership drives who sees which records and how they show up in reports. Consent flags carry legal consequences. If either arrives wrong, you find out later, in a report nobody trusts.
Why a sample export misleads you
The obvious approach is to design the new setup from a small sample of the data. As the blueprint puts it, “the sample lies, and it lies in both directions.”
- In a 71-row sample, 59 columns looked unused. Across all 3,432 records, only 26 were.
- One column was empty in every sample row yet filled on every record in the full file. Built from the sample, that data would have had nowhere to go.
- The sample had no repeated email addresses. In the full file, 10 records shared an address with another record. Removing duplicates by email would have merged different people.
The reason is ordinary. Samples tend to come from recent records, and newer records are filled in differently from older ones.
The principle of a safe CRM data migration
Two habits carry most of the load. Profile the entire export rather than a slice. And for every dropdown field, compare the values in the export with the options in the new system before importing, not after.
That comparison surfaces three different causes, and each needs a different fix:
- Missing options. List every value the old system actually holds, rather than trusting its documentation, and add the ones the new system lacks.
- Casing variants. “Unlimited” and “unlimited” are the same value. Adding a second option would split your reports in two. Fix the casing in the file instead.
- Spreadsheet damage. Somewhere along the way, a spreadsheet turned size ranges like 2-4 and 5-10 into dates: 4-Feb and 10-May. To catch it, count the distinct values and read through the list yourself.
A practical example
Here is what the count found on one export, before any correction:
- Contact status: 579 of 3,432 records would have been blank (17%). Five source values had nowhere to land, one of them used on 335 records.
- Product tier: 117 of 418 records would have been blank (28%), mostly because of casing variants.
- Team size band: 39 records, from one missing option plus spreadsheet date damage.
Two checks catch what the count misses. Before the full import, write one real record from the export end to end, read it back, compare every field, then delete it. After the import, compare each field’s fill rate with the source. If a field should hold 3,432 values and shows 2,853, it is missing 579, and no error message will point that out.
Limits worth knowing before you start
- The CRM sets some dates itself. An import can’t write the creation date or the last-contacted date. To keep the original dates, create separate custom date fields, and decide this up front. In this export, last-contacted was filled on all 3,432 records.
- Map owners by email, not by name. Every record needs a valid owner. In this export, one rep’s name was tied to two email addresses: 2,432 records under one, 15 under the other.
- Pick your duplicate check carefully. Import the old system’s own record ID into a custom field. It is unique in the old system and stays the same across exports, so if the import has to run twice, you don’t end up with two of everything.
- An export can be filtered without saying so. In this export, not one contact was marked anything other than “Subscribed”, which almost certainly means only subscribers were exported. Taking it as complete would have thrown away the unsubscribe list, the one mistake here with legal consequences.
Key takeaways
- CRM imports report success even when data is lost. Plan for silence, not errors.
- Inventory the complete export. A sample hides the columns and duplicates that matter.
- Compare every dropdown value with the new system’s options before importing.
- Test with one real record, then check fill rates field by field after the import.
- Use the old system’s record ID, not email, to prevent duplicates.
The full import sequence, the cleanup table and the verification checklist are in the Coevera blueprint How do you migrate contacts from another system without silently losing data? Share it with whoever runs your CRM migration before the first import, not after.
PLANNING A MIGRATION?
Let us run the count for you
Whether you’re coming from Salesforce, HubSpot, or a CRM your team stopped trusting, our migration team handles the heavy lifting. We inventory the full export, reconcile every dropdown before the first import, and check fill rates field by field afterwards. Then we rebuild your pipelines and configure automations before day one. Most teams are fully operational within four weeks, not months.
Comments