CRM migration

Plan a CRM migration from discovery through cutover, back-office checks, and post-migration stabilization.

Last updated: June 6, 2026

This tutorial walks through planning and running a CRM migration with Sanka in the operating layer. Use it when you are moving customer, company, deal, activity, and related back-office data between CRMs and need a controlled path from discovery to stabilization.

Before you start

Confirm the migration decision, source CRM, target CRM, and cutover window before changing production data.
  • Admin access to the source and target CRM
  • A named migration owner and business approvers
  • Export access for contacts, companies, deals, activities, and custom objects
  • A way to freeze writes during cutover
  • A list of connected tools such as billing, support, marketing automation, BI, and accounting
If your team is still selecting a CRM, start with Best CRM.

1. Ask AI to prepare the migration inventory

Start by asking Claude or Codex to organize the migration inventory before anyone imports data.
Sample prompt
/sanka Create a CRM migration inventory for our source CRM. Group records by objects, fields, workflows, integrations, reports, and owners. Flag anything that needs human review before migration. Do not create or update records yet.
Review the inventory with RevOps, sales leadership, finance, and support. The goal is to decide what must migrate on day one and what can be archived, rebuilt, or skipped.

2. Map the CRM data model

Create a mapping sheet for every source field that will move into the target CRM.
Source fieldSource typeTarget fieldTarget typeTransform
Account nameTextCompany nameTextCopy as-is
Deal stagePicklistPipeline stagePicklistMap only active values
Renewal amountCurrencyAmountCurrencyNormalize currency first
Use the mapping to find conflicts before import. Common issues include duplicate fields, unused picklist values, formula fields that do not exist in the target CRM, and records with missing owners.

3. Check the back-office gap

CRM migration usually touches more than the CRM. Before cutover, check whether the target CRM covers the downstream work that depends on CRM data.
  • Quotes, CPQ, and approval routing
  • Orders, subscriptions, and billing
  • Payments, revenue recognition, and accounting sync
  • Inventory, procurement, and fulfillment
  • Customer support and renewal workflows
If the target CRM does not cover one of these areas, decide whether Sanka will become the operating layer for that workflow before migration day. This prevents the team from moving CRM records while leaving quotes, invoices, inventory, or revenue context behind.

4. Run a test migration

Run the first import in a test workspace or staging environment.
  • Load companies before contacts and deals
  • Preserve source record IDs for traceability
  • Validate record counts and association counts
  • Check sample records with sales, finance, and operations
  • Confirm workflows are disabled until the test data is reviewed
Do not treat a successful import count as the final validation. Open sample records and confirm owners, amounts, stages, line items, notes, and history.

5. Freeze writes and cut over

Use a short, explicit cutover window.
  • Friday: freeze writes in the source CRM
  • Friday night: run the final delta sync
  • Saturday: validate records, associations, reports, and integrations
  • Sunday: switch connected systems to the target CRM
  • Monday: monitor user issues and migration exceptions
Keep the source CRM read-only after cutover. If users keep updating both systems, the migration creates two sources of truth.

Checkpoints

After cutover, confirm the new CRM and Sanka show the same operating context.
  • Customers, companies, deals, and activities are searchable
  • Quotes, orders, invoices, payments, and subscriptions link to the correct customer records
  • Reports use the new source of truth
  • Workflows do not run twice
  • Users know where to file migration issues