CRM data migration: how to verify an import
Move customers and deals from spreadsheets or another CRM: map fields, handle duplicates, verify relationships and accept the result. Includes a migration checklist.
Accept a usable database, not a row count
Before migration, agree the dataset, mapping, duplicate rules and verification method. Run a trial import, reconcile the result and then switch the team over. A successful file upload does not establish that deals are linked to customers or that staff can continue their work.
List the objects first: companies, contacts, deals, products, tasks, files and conversation history. For each, record its source, volume, required fields, relationships and archive exclusions. Moving records does not automatically include attachments, conversations, automation settings or permissions.
Map fields and relationships
- Source identifier
- Keep a stable source key and its mapping to the new record ID. A spreadsheet row number is unreliable after sorting.
- Field and format
- For each column, specify the destination field, type, required status and transformation. Check dates, time zones, phone numbers and numeric values.
- Stage and owner
- Map old statuses to new stages and staff to active users. Agree a replacement for any unavailable owner.
- Related records
- Verify company, contact and deal relationships, plus any other required objects. A company name is not always a unique identifier.
- Errors and exclusions
- Record where rejected rows go, who resolves them and how to retry only the necessary part of the migration.
Rules depend on the platform
The standard Bitrix24 CSV import for linked records depends on upload order and exact matching names. This import does not update existing deals, so repeating it can create another deal. This is a limitation of that tool, not of every migration method. Bitrix24 import documentation
HubSpot uses unique identifiers to update and associate records. Build the mapping for your chosen tool rather than copying another CRM’s settings. HubSpot import concepts
Define a duplicate before importing
Matching names do not establish that two records represent one person. A shared phone may belong to a company, and a customer can have several legitimate deals. Define separate rules for contacts, companies and deals. Route ambiguous matches for human review.
Choose an action for each match: skip, create separately, fill empty fields or update agreed values. Define which source wins when values conflict. Do not merge distinct orders from the same customer. Test repeat-run behaviour on a separate copy before the production import.
Include difficult records in the trial
Choose an agreed sample covering the dataset’s variations: a returning customer, several company contacts, an optional empty field, an inactive owner, an ambiguous duplicate, a deal with a file and an invalid date. These are test scenarios, not a real customer dataset.
On a verification copy, disable outbound messages and other actions that should not run during import. Confirm that the owner can open a deal and see its customer, stage and next action. Check access under another role separately. Correct the migration rules and rerun the affected checks.
Reconciliation example: 100 rows do not mean 100 new customers
Hypothetical single-file example: of 100 source rows, 70 created records, 20 updated existing records, 5 were skipped under an agreed rule and 5 failed. Every row is accounted for, but errors, field values and relationships still need checking. Reconcile contacts and deals separately.
Agree when the team switches systems
- Retain the source export and the system’s supported backup. Record the date and a verified recovery procedure.
- Define where staff work before cutover and who captures changes made after the export. Agree an entry freeze or a separate changes transfer in advance.
- After resolving trial issues, perform the production import and reconciliation. Do not rerun a whole file to fix one row without checking the consequences.
- Verify new enquiries and agreed integrations after cutover. Keep the old source available until acceptance and archive access are agreed.
- If migration fails, follow the agreed recovery plan. Account for records created after import so recovery does not erase new work.
What the migration handover should contain
- Scope and reconciliation
- For each object: source rows, creations, updates, skips and errors, with explanations for differences.
- Quality and relationships
- Verified key fields, stages, owners and relationships across agreed scenarios, with remaining exceptions recorded.
- Team workflow
- The appropriate role can open and continue an active deal, and new enquiries reach the working system.
- Handover
- Field map, migration log, error list, repeat-run rules, archive access and an owner for outstanding issues.
For Krest-NN, we refined an existing Bitrix24 setup and verified specific workflow rules. This is evidence of CRM configuration, not a documented bulk data migration case. Your migration scope and acceptance criteria need a separate agreement. BYstudio’s initial workflow review is free.
Data migration questions
Can we just upload a spreadsheet?
A standard import may be enough for a small, prepared dataset. Check the template, required fields, mapping, duplicate rules and related records first. Confirm messages, files and change history separately if you need them.
What does data migration cost?
The estimate depends on objects, data quality, relationships, export capabilities and the import method. A thousand deals with files and history can involve different work from a thousand contacts. Start with the structure and an anonymised sample, then agree scope and acceptance.
Should we move every old record?
Not necessarily. Decide what is needed for current work and required retention. Historical material may remain in an accessible archive if that meets your requirements. Record exclusions and how the archive will be searched.
What happens to new enquiries during migration?
Define a cutover point and one working source for each phase. Specify how changes made after the first export will reach the new CRM. Otherwise, enquiries can remain only in the old system.
Is an import-completed message enough?
No. Check created and updated records, skips, errors, owners, relationships and whether staff can continue active deals. Retain the reconciliation and unresolved issues.