Follow these phases: charter, inventory, map, clean, test, cutover, hypercare, and require named owners and test sign-offs before any production load. Skipping sandbox testing or leaving go/no-go authority unassigned is how migrations stall mid-cutover or corrupt records nobody notices for weeks. Start with a one-page charter today, then move to inventory once scope and owners are written down.
TL;DR:
- Complete inventory of objects, fields, workflows, and integrations must be documented and validated before mapping or loading begins.
- Sandboxing and rigorous testing of edge cases, including duplicates and orphaned records, are essential to identify issues prior to production cutover.
- Clear sign-offs and detailed runbooks with rollback triggers are critical to ensure control and safety during migration execution.
- Daily hypercare checks focus on record counts, duplicate prevention, and workflow integrity, lasting two to four weeks post-migration.
- Using a unified platform reduces complexity, streamlines testing, and simplifies ongoing management by consolidating tools into a single system.
Table of Contents
- The step-by-step CRM migration checklist you'll actually run
- Pre-migration planning: goals, scope, owners, and acceptance criteria
- Inventory and mapping workbook: what to capture and how to sequence loads
- Data cleanup and ID strategy: dedupe, normalization, and survivorship rules
- Sandbox testing, validation methods, and test-run acceptance
- Cutover runbook and rollback triggers: the production execution checklist
- Post-migration validation and hypercare: daily checks and acceptance gates
- Practical tools, automation patterns, and where an all-in-one platform helps
- Three pragmatic lessons from running migrations
- How Aria simplifies what comes after migration
- FAQ
- Sources
The step-by-step CRM migration checklist you'll actually run
A migration succeeds or fails on sequencing. Each phase below produces a specific artifact, and each artifact needs sign-off before the next phase starts. Treat this as your execution run sheet, not a reference document to skim once.
- Charter and scope. Write the migration objective in one sentence, list what will and won't move, and name a single migration owner. Artifact: signed charter document. Exit gate: owner and scope approved by leadership.
- Inventory. Catalog every object, field, workflow, automation, integration, report, and permission set in the source system. Artifact: inventory spreadsheet. Exit gate: each item has an owner and a migrate/retire decision.
- Mapping. Build the field and object mapping workbook, including relationships and transform rules. Artifact: mapping workbook. Exit gate: every source field has a destination or a documented exclusion reason, a standard HubSpot recommends as part of a practical migration process.
- Backup and cleanup. Export a full backup of the source system, then dedupe and normalize records before anything moves. Artifact: timestamped backup file plus a cleanup log. Exit gate: duplicate rate and bad-data rate both documented and reduced.
- Sandbox test migration. Run a representative sample through the full pipeline in a sandbox environment. Artifact: test logs and a reconciliation report. Exit gate: record counts, relationships, and workflows validated against source data.
- Full migration (initial load). Move the bulk of historical data once the sandbox test passes. Artifact: load confirmation report. Exit gate: automated record-count comparison matches expected totals.
- Delta import. Capture and load records changed between the initial export and cutover. Artifact: delta log with timestamps. Exit gate: zero unaccounted changes between freeze and go-live.
- Cutover. Execute the final switch with a predefined load order and validation checkpoints. Artifact: cutover runbook with timestamps filled in. Exit gate: go/no-go authority signs off before users are redirected.
- Hypercare. Monitor daily for 2 to 4 weeks, the window HubSpot's migration framework treats as standard for catching late-surfacing issues. Artifact: daily reconciliation logs. Exit gate: error rates fall within agreed thresholds for a sustained period.
- Decommissioning. Archive the legacy system and revoke access once hypercare closes cleanly. Artifact: archive confirmation and access-revocation log. Exit gate: data owners confirm the new system runs the business without the old one.
Each line above needs more than a checked box. Here's what reviewers should actually look for before approving a phase:
- Charter: named owner, written objective, explicit exclusions list.
- Inventory: complete object and field list with an owner assigned to each domain.
- Mapping workbook: every field mapped or excluded with a documented reason, relationships preserved.
- Backup: a restorable file with a timestamp, stored separately from the live system.
- Test logs: record counts, spot-check results, and a list of failed associations with root causes.
- Cutover runbook: rollback triggers written down before cutover starts, not during a crisis.
Pro Tip: Test the weird records on purpose, duplicate emails, orphaned deals, contacts with no company, and preserve every legacy ID so a failed association can be traced back to its source row instead of guessed at.
Pre-migration planning: goals, scope, owners, and acceptance criteria
Most migration failures trace back to vague goals. A charter that says "move to the new CRM smoothly" gives nobody a way to measure success. Write the objective as one sentence with a number attached: "Migrate all active accounts, contacts, and open deals with zero data loss and full report parity by the cutover date."
Acceptance criteria need to be measurable before you touch a record. That means defining:
- Target record counts for each object, with an agreed tolerance for variance.
- A list of reports that must produce matching numbers in the new system.
- Core workflows (lead routing, deal stage automation, renewal reminders) that must function identically post-cutover.
Assign one migration owner who holds final authority, plus named data owners for each domain (sales, marketing, support, finance). This isn't bureaucracy for its own sake. As Vantage Point's migration planning guide points out, most migration failures are planning failures, not tooling failures, and unclear decision rights are a leading cause of planning breakdowns. Build a simple RACI: the migration owner is accountable for go/no-go, domain owners are responsible for validating their own data, and leadership is consulted but doesn't block daily decisions.
Decide history depth early. Do you need five years of closed deals, or does the business only reference the last 18 months? Archival candidates (closed-lost deals, inactive contacts, duplicate records) should be flagged for exclusion now, not discovered mid-import. Write down what will not migrate and why, since that list prevents scope creep later.
Pro Tip: Put the acceptance criteria in writing and get sign-off before inventory starts. A migration without a measurable finish line never quite finishes.
Inventory and mapping workbook: what to capture and how to sequence loads
Before any field gets mapped, you need a complete inventory of what exists in the source system. This step gets rushed more than any other, and it's where surprises during cutover usually originate.
Capture every one of these categories:
- Standard and custom objects (accounts, contacts, deals, tickets, custom objects specific to your business).
- Fields on each object, including hidden or rarely used ones.
- Workflows and automations, documented by trigger and action.
- Integrations with other tools (email platforms, billing systems, support desks).
- Reports and dashboards that stakeholders rely on daily.
- Permission sets and user roles.
- Attachments, notes, and file storage tied to records.
Once inventory is complete, build the mapping workbook. Vantage Point's best practices checklist recommends covering objects, fields, picklist transforms, ownership, and legacy IDs, with every source field assigned a destination or a documented reason for exclusion.
| Column | Purpose |
|---|---|
| Source object/field | Identifies exactly what's being mapped |
| Sample value | Shows a real example to catch formatting issues early |
| Target object/field | Where the data lands in the new system |
| Data type | Flags mismatches (text versus number, single versus multi-select) |
| Transform rule | Documents any conversion logic (date format, picklist renaming) |
| Owner | Names who validates this mapping is correct |
| Legacy ID | Preserves traceability for reconciliation |
| Acceptance test | Defines how this mapping gets verified post-load |
Load sequencing matters because CRM data is relational. Users load first, since every other record references an owner. Accounts come next, then contacts (which belong to accounts), then deals (which belong to contacts and accounts), then activities and attachments (which attach to all of the above). Loading parent records first preserves relationships instead of leaving orphaned child records that need manual reattachment. A partner resource on practical migration planning for IT leaders walks through inventory and mapping templates that follow this same parent-first logic for service-based businesses running multiple connected systems.
Data cleanup and ID strategy: dedupe, normalization, and survivorship rules
Clean data before you move it, not after. Migrating duplicates and inconsistent formatting just moves the mess into a new system where it's harder to find.
Start with dedupe keys. For contacts, email address is the most reliable match key. For companies, domain name works better than company name, since "Acme Inc." and "Acme Incorporated" are the same business but won't match on a text field. When two records represent the same entity, apply a survivorship rule: keep the record with the most recent activity, or the one tied to the larger revenue figure, and merge the rest into it rather than deleting them outright.
Normalization cleans up the small inconsistencies that cause matching failures and ugly reports:
- Lowercase all email addresses before matching or import.
- Standardize phone number formats to a single pattern across every record.
- Convert all dates to one format before mapping, since mixed formats cause silent misreads.
- Normalize picklist values so "New York" and "NY" aren't treated as different entries.
Legacy IDs deserve a deliberate decision. Preserve them in a dedicated field on the new record whenever the source system assigns stable IDs, since that field becomes your reconciliation key during validation. When the source system's IDs aren't reliable or portable, generate external IDs during the mapping phase and use them consistently across every related object, so a contact, its deals, and its activities all carry the same crosswalk reference.
Pro Tip: Run your dedupe logic against a test export first. A key that looks clean in the first 50 rows often breaks on record 4,000 once you hit a batch import or a shared company email address.
Sandbox testing, validation methods, and test-run acceptance
Never move production data through logic that hasn't been tested on a sandbox copy first. This is the single most common point where migrations go sideways, because teams test the easy records and skip the complicated ones.
- Pull a representative batch of 100 to 500 records, a range HubSpot's migration overview identifies as typical for a practical test batch, making sure it includes edge cases: duplicate emails, orphaned deals, multi-owner accounts, and records with missing required fields.
- Run the batch through your full mapping and transform logic in a sandbox environment, not a live system.
- Compare automated record counts between source and target to catch any records that silently failed to import.
- Spot-check 50 to 100 records per object manually, checking field values, relationships, and owner assignments.
- Run integration smoke tests to confirm connected tools (email, billing, support) still function against the migrated data.
- Have power users complete real workflows in the sandbox, logging a deal, closing a ticket, sending a campaign, before declaring UAT complete.
One reconciliation report should combine automated counts with manual spot checks. Vantage Point's best practices guide recommends validation that blends record counts, spot checks, automated comparisons, and UAT, rather than relying on visual inspection alone, since visual review misses silent field-mapping errors that automated comparison catches immediately.
Set exit criteria before testing starts: a maximum acceptable error rate, a reconciliation threshold for record counts, and a requirement that UAT sign-off is documented in writing, not verbal. If the test batch fails any of these, fix the mapping and retest. Moving to production on a failed test is how small errors become large ones.
Cutover runbook and rollback triggers: the production execution checklist
Cutover is where planning either pays off or falls apart in public. A written runbook with explicit timestamps and named owners is the difference between a controlled switch and a scramble.
- Announce a change freeze in the source system, stopping new edits at a specific time.
- Capture the final export immediately after freeze, timestamped and logged.
- Run the delta import, loading anything changed since the last full migration.
- Execute the production load in the parent-first order established during mapping.
- Run validation gates, the same reconciliation checks used in sandbox testing, now against live data.
- Get go/no-go sign-off from the named decision maker before redirecting users to the new system.
- Confirm post-import checks, including integration health and core workflow execution.
Rollback triggers need to be agreed before cutover, not debated during one. Reasonable thresholds include:
- More than 1% of critical fields showing corruption or mismatched values.
- Record-count variance exceeding 5% between source and target.
- A core integration (billing, support routing, email sync) failing smoke tests post-load.
When a trigger fires, the response is to pause new user access, restore from the preserved backup, and reassess rather than pushing forward and hoping the next batch fixes itself. Vantage Point's migration best practices frame rollback as a preapproved control tied to specific conditions, not an admission of failure, and recommend keeping the legacy CRM in read-only mode until the new system earns full acceptance. Don't decommission the old platform after the first successful load. Keep it accessible and frozen until hypercare closes, since that window is exactly when teams discover what the initial validation missed.
Post-migration validation and hypercare: daily checks and acceptance gates
Hypercare is the 2 to 4 week stretch after cutover when a migration either proves itself or reveals problems nobody caught in testing. Daily checks during this window matter more than the cutover day itself, since most data issues surface once real users start working in the new system.
Run these checks daily through the first two weeks, then taper to a few times a week:
- Reconcile record counts against the cutover baseline to catch drift.
- Monitor for new duplicates created by overlapping sync processes or manual re-entry.
- Confirm integrations (email, billing, support) are passing data correctly both directions.
- Verify scheduled workflows and automations are firing as designed.
- Check that reports match expected numbers, since report parity is often the last thing anyone verifies.
- Route support tickets related to missing or incorrect data to the migration team, not general support.
Set a reconciliation threshold going into hypercare: if error rates or variance exceed what you defined during sandbox testing, that's a signal to investigate immediately rather than wait for the weekly review.
Final sign-off requires three things: each data owner confirms their domain's records and reports are correct, business teams confirm core processes work without reverting to the old system, and the team agrees on an archive and decommission timeline for the legacy CRM.
Pro Tip: Keep a running issue log during hypercare, even for small fixes. Patterns that look like isolated glitches in week one often turn out to be a single mapping error once you see three or four similar tickets together.
Practical tools, automation patterns, and where an all-in-one platform helps
Every integration point in a migration is a place where data can drop, transform incorrectly, or get stuck in a sync delay. Fewer moving parts means fewer places for that to happen. When customer records, workflows, and communication tools live in one system instead of five connected ones, mapping gets simpler because there's one target schema instead of several, and testing gets faster because there's one data store to reconcile against instead of multiple sync points.
Automation patterns worth building into any migration:
- API-driven ETL scripts with retry logic, so a timeout doesn't silently drop a batch of records.
- Legacy ID preservation at every step, so failed records are traceable back to their source.
- Temporary middleware for field transforms that don't map cleanly, removed once the target schema is finalized.
We use a unified platform covering CRM, community management, courses, and marketing tools in one interface, which is relevant here because consolidating systems during a migration reduces the number of integration points you need to test and maintain going forward.
Three pragmatic lessons from running migrations
Three things hold up across every migration: map the full field and object list before writing a single transform rule, require a sandbox test that includes your ugliest edge cases, and name one person with final go/no-go authority.
The fix took longer than the original testing would have.
— Anastasia
How Aria simplifies what comes after migration
Once your data lands in a new system, the real work is keeping workflows, communication, and customer records from scattering back across separate tools. We use a platform that holds CRM functionality, email and SMS marketing, automations, and client management in one place, which means fewer sync points to monitor during hypercare and fewer subscriptions to reconcile against your new source of truth.
If you're planning a migration or just finished one, here's where to start:
- Review the Build, Grow, and Scale plans to see which tier matches your current tool stack.
- Request a walkthrough to map your existing CRM and marketing tools against one unified interface.
- Compare your current monthly software spend against a single consolidated subscription.
For ongoing data hygiene after cutover, a partner playbook on 30/90/180-day CRM data hygiene outlines monitoring patterns that pair well with a hypercare plan.
FAQ
How do you migrate from one CRM to another?
Follow a phased sequence: charter and scope, inventory, field mapping, data cleanup, sandbox testing, controlled cutover, and hypercare monitoring for 2 to 4 weeks, a timeline HubSpot's migration framework treats as standard. Each phase needs a named owner and a documented exit gate before the next phase starts.
What is a post-migration checklist?
A post-migration checklist covers the hypercare period: daily reconciliation of record counts, duplicate monitoring, integration health checks, workflow verification, and report parity confirmation. It closes with sign-off from each data owner and a plan to archive the legacy system.
What is meant by migration in CRM?
CRM migration means moving customer records, deals, workflows, and related data from one system to another while preserving relationships between those records. A safe migration protects links between companies, contacts, deals, activities, and reports, as outlined in CRM Software Guide's migration process, so the new system can run the business without the old one.
What are the six types of data migration?
Definitions vary across sources, but common categories include storage migration, database migration, application migration, cloud migration, business process migration, and data center migration. For CRM projects specifically, the practical distinction that matters most is between a full-system migration and a phased, object-by-object migration.