Business ·
Rehearse before moving the database
A successful file upload does not establish that a salesperson can continue working. Test a CRM data migration with a small rehearsal: find the customer, open the deal and account for what happened to every source record.
Define the work that must continue
Start with people's tasks after the move. Salespeople need open deals and the next contact. A manager needs clear owners and stages. Some historical material may need preservation without participating in daily work. This distinction helps separate an operational dataset from an archive before uploading anything.
Record the source, export date, object types and the person who can resolve questions about each disputed field. Keep the original export separate from the prepared copy. Avoid unrecorded manual cleaning: if something differs later, you need to distinguish a source-system change from an import preparation change.
Agree on fields and identifiers
For each field, document its source, destination, transformation and treatment of empty values. “Owner” might be a name in a spreadsheet and a user account in the new CRM. “Stage” might describe different events in the two systems. Moving matching words without checking their meaning produces a misleading appearance of order.
Define the keys that let the destination recognise a record. For example, HubSpot's import documentation describes different unique identifiers and association rules. It illustrates why you need the chosen CRM's rules: an email address cannot be assumed to identify every customer universally. One contact may have several deals, and two records may share an email address.
Build a small but difficult sample
Include a normal record and cases likely to challenge the mapping: similar company names, a missing owner, several deals for one customer and an empty required field. Use an approved environment and the smallest useful dataset. Deliberately constructed examples can test the logic without using real customer records.
Before importing, write the expected outcome for each case. An example customer has two deals; one is closed and one remains active. After the move, both should link to the correct customer, and the active deal should retain a clear next step. This tests relationships and operational meaning, not just a row count.
Account for every record
After uploading, distinguish created, updated, skipped and rejected records according to the importer's rules. Each rejection needs an understandable reason and a decision: correct it, exclude it or ask the data owner. If one source row creates several objects, reconcile those separately. Equality between overall totals is no longer enough.
Check relationships and a few working journeys with a future user. Then repeat the prepared import on the test copy if the selected tool supports that scenario. Record whether duplicates appear, the intended fields update and the second run can be distinguished from the first. Recovery through a repeat run needs to be designed before a failure happens.
Agree on the cutover
A rehearsal does not cover new records created in the old system before the final migration. Agree on when editing stops, who obtains the final export and how changes since the trial will be handled. If work cannot pause, design a separate way to transfer changes; this expands the scope.
Review the destination CRM's automated actions. Importing a test deal should not unexpectedly email a customer or assign a task to an employee. Before the live run, establish how an incorrect batch can be reversed and changed records restored, where supported. Deleting newly created contacts will not restore earlier values in updated objects.
Accept the ability to continue working
The rehearsal produces a field map, example dataset, reconciliation, exceptions log and cutover plan. Acceptance finishes with someone finding the right deal, understanding its state and taking the next step. Retain the date and version of the checked mapping: rule changes require another check of the affected cases.
Choosing the system is covered separately in [ready-made versus custom CRM](/en/apocrypha/custom-crm-or-ready-platform). Ongoing exchange is another task, explored in [API integration](/en/apocrypha/api-integration-for-business). Here, the outcome is a checked, one-off migration that lets work continue.
When spreadsheets, website forms and the CRM disagree about fields and relationships, [digital product development and automation](/en/dialogue) can begin with this rehearsal. Bring the data structure, process description and disputed examples to the first discussion; there is no need to send the complete customer database in advance.
From an idea to a digital product
If the task calls for a service or internal tool, we can define the first complete journey and a path to a working release.