CRM Migration Testing: From Rules to Go-Live

The most dangerous moment in a CRM migration is the first Monday after go-live, when users discover what testing missed: deals attached to the wrong accounts, a workflow that no longer fires, an integration sending duplicates, a report that no longer adds up. Thorough CRM migration testing finds these problems while they are still cheap to fix. It covers far more than checking that record counts match. This guide explains the layers of CRM migration testing, from transformation rules and data reconciliation to automations, integrations and user acceptance, how to write test scripts users will actually run, and how to decide when you are ready to go live, with a worked test plan.

The layers of CRM migration testing

LayerQuestion it answersWho testsTransformation testsDo mapping and cleaning rules produce the right values?Migration developersData reconciliationDid every record arrive, with correct values and relationships?Migration team with data ownersConfiguration and automation testsDo layouts, permissions, workflows and validation rules behave correctly?CRM administratorsIntegration testsDo connected systems send and receive the right data?Integration ownersUser acceptance testingCan users do their real work in the new CRM?Representative usersCutover verificationDid the final production load succeed?Migration team and key users

Each layer catches different problems. Skipping one usually means its problems surface in production.

Testing transformation rules

Most migrations transform data on the way: splitting names, mapping picklist values, standardising phone numbers, converting currencies or assigning owners. Each rule can be tested in isolation before any full migration runs, which is faster and more precise than finding errors in reconciliation. A simplified, untested illustration in Python, testing two mapping functions with pytest:

from mapping import map_stage, normalise_country

def test_stage_mapping():
    assert map_stage("Proposal Sent") == "Proposal"
    assert map_stage("Verbal Yes") == "Negotiation"
    assert map_stage("Dead") == "Closed Lost"

def test_unknown_stage_is_flagged():
    assert map_stage("Something new") is None

def test_country_normalisation():
    assert normalise_country("U.K.") == "GB"
    assert normalise_country("united kingdom") == "GB"
    assert normalise_country("") is None

The mapping module holds the team's own rules. Writing tests from the approved mapping document also exposes gaps, such as old picklist values nobody mapped.

Reconciling migrated data

After each trial migration, compare old and new systems:

• Record counts per object, with every difference explained
• Key totals, such as open pipeline value, won revenue by year and number of open cases
• Relationships, such as contacts per account and deals per account, for a sample
• Field-level spot checks on a random sample across every object, plus known tricky records
• Ownership, so each user sees the records they expect

Agree acceptable thresholds in advance. Some differences are intended, such as records deliberately left behind; each must be explainable.

Testing configuration, automations and integrations

For every rebuilt workflow, validation rule and approval, write a test with an input record and the expected result, and run it in the test environment with migrated data. Test permissions by signing in as users in different roles. For integrations, push realistic test data through each connection in both directions and confirm it arrives correctly, without duplicates, and that errors are handled.

User acceptance testing that works

User acceptance testing asks representative users to perform their real tasks in the new CRM using migrated data. It works best with written scenarios rather than "have a look around":

• Base scenarios on daily work: "Find your largest open opportunity, update its stage and log a call"
• Use each tester's own migrated records, so they can judge whether data looks right
• Give clear expected results and a simple way to record pass, fail and comments
• Cover every role and team, including managers' reports and dashboards
• Schedule time in testers' calendars; testing squeezed around normal work rarely happens

Triage issues daily into defects, data problems, training needs and change requests, and retest fixes.

Worked example: a test plan for a CRM migration

Suppose a manufacturing company with 80 CRM users runs two trial migrations before cutover. Its test plan:

TestScopePass criteriaTransformation testsAll 46 mapping rulesAll automated tests pass; unmapped values listed and resolvedReconciliationAccounts, contacts, opportunities, quotes, cases, activitiesCounts match or differences explained; open pipeline value matchesRelationship sampling200 random accountsContacts, opportunities and cases linked correctlyAutomation tests31 rebuilt workflows and validation rulesEach produces expected result on test recordsIntegration testsERP, website forms, marketing platformData flows correctly both ways; no duplicates on retryUser acceptance12 testers across sales, service and management; 40 scenariosAll critical scenarios pass; no open critical defectsPerformanceKey list views and reportsLoad within agreed times with full data volumeCutover verificationProduction loadCounts and pipeline value match final export; five key users confirm their data

The go-live decision rests on agreed criteria: no open critical defects, reconciliation fully explained and sign-off from the head of sales and head of service. The counts and criteria are this company's choices, shown to illustrate the approach.

Rehearsing cutover and rollback

The final trial migration should be a full rehearsal of cutover: the same steps, in the same order, with the same people, timed from the start of the data freeze to the moment users can sign in. Rehearsal shows whether the planned window is long enough and exposes manual steps nobody wrote down. Rehearse the rollback too. If the production load fails verification, the team must know exactly how to return users to the old CRM, how long that takes and who makes the call. A rollback plan that has never been tried tends to fail at the moment it is needed most. Record the timings and issues from each rehearsal and update the runbook before the real cutover.

Deciding you are ready

Define go-live criteria before testing starts, so the decision is objective. Typical criteria include reconciliation passed, no critical or high-severity defects open, user acceptance signed off by named owners, integrations tested end to end and a rehearsed cutover with a rollback plan. If criteria are not met, a short delay is almost always cheaper than going live and fixing in production.

Common mistakes

• Treating matching record counts as proof of success
• No automated tests for transformation rules
• User acceptance testing without scenarios or allocated time
• Testing with sample data instead of a full trial migration
• Ignoring permissions and reports
• No agreed go-live criteria

For the phase-by-phase checklist that these tests fit into, see our CRM data migration checklist. For what a full migration engagement includes, see our guide to CRM migration services.

Frequently Asked Questions

What should CRM migration testing include?

Transformation tests, data reconciliation, configuration and automation tests, integration tests, user acceptance testing and verification of the final cutover load.

How do we test that migrated CRM data is correct?

Reconcile counts and key totals, sample relationships and field values across every object, check ownership and have users review their own records.

How should user acceptance testing be run in a CRM migration?

With written scenarios based on real tasks, testers using their own migrated data, scheduled time, clear expected results and daily issue triage.

When is a CRM migration ready to go live?

When agreed criteria are met: reconciliation explained, no open critical defects, user acceptance signed off, integrations tested and a rehearsed cutover with rollback plan.

Test your migration thoroughly

We plan and run CRM migration testing, from automated transformation tests to user acceptance and cutover verification. See our Zoho CRM implementation services, or talk to us about your migration.

About the Author

Manav Sharma is the founder of Insyrge and a CRM solutions architect. He works across Zoho, Salesforce, HubSpot, Odoo and more, designing the CRM setups, integrations and automations that keep sales and operations teams working from the same data.