Guide · CRM & customer operations
Test a CRM Import Before You Commit to the Cutover
Build a small migration test that checks relationships, record behavior, and daily work rather than stopping at a successful upload.
"The import completed" is useful information. It doesn't tell you whether the right notes belong to the right customer or whether the team can continue an open job. A cutover test should answer those questions while the consequences are still small enough to inspect and fix.
Assemble a sample with awkward edges
Start with a test destination and data you're authorized to use there. Include the common record shape, then add the cases most likely to reveal a mistake: two similar names, a company with multiple contacts, missing fields, and an opportunity with related history. A sample made entirely of clean new leads won't tell you much about a lived-in CRM.
Keep the source identifiers with your sample. Record the expected destination for each item before importing it. If you decide what "correct" means only after looking at the result, it's easy to accept a plausible but wrong outcome.
Run three kinds of checks
First, reconcile counts. Explain what was imported, skipped, rejected, or retained only in an archive. A difference isn't automatically a failure, but it should have a reason that matches the migration plan.
Second, inspect meaning. Check field values, dates, notes, and relationships against the source. Open the records in the destination interface. A raw database row may exist while the application can't display it because a required relationship is missing.
Third, try a normal work task. Can the person responsible find the open opportunity, understand the history, and assign the next action? Use a task from the team's real day. This is where you'll notice that an import preserved the data but buried the information people need.
Confirm what stays quiet
Historical activity should not accidentally behave like new customer activity. Before the test, identify workflows, notifications, webhooks, or other integrations that could react to imported data. Use the documented test and migration controls for your actual tools.
Then inspect the result. Check the relevant logs and queues rather than relying on a setting's label. If you can't determine whether an external action could occur, resolve that uncertainty before moving live data. The point of the sample is to find those boundaries while the scope is still manageable.
Write the go-or-stop decision
Have someone from the business review the results alongside whoever ran the import. Technical completion and operational usefulness are related, but different people may be best placed to judge them. Record the exceptions they're accepting and the issues that block the larger move.
Keep the test report, input sample, and mapping version together. If you change the mapping afterward, repeat the affected checks. A test of yesterday's plan doesn't validate a different plan simply because the file has the same name.
- Expected and actual counts, with an explanation for differences.
- A few named records whose relationships were inspected.
- One daily workflow completed in the destination.
- Confirmation of the intended automation and notification behavior.
- A recovery plan if the larger import stops partway through.