CRM Migration Checklist: What Every Revenue Leader Needs to Know

A CRM migration is one of the highest-stakes projects a revenue organization can undertake. It touches every team, every process, every report, and every customer interaction. Get it right and you unlock capabilities that transform how your GTM team operates. Get it wrong and you spend 18 months cleaning up the mess, assuming the project doesn't get abandoned entirely.

The failure rate is staggering. Gartner has consistently found that the majority of CRM implementations fail to meet their stated objectives. And having led or advised on more CRM migrations than I can count, I can tell you the reason is almost never the technology. Salesforce, HubSpot, Microsoft Dynamics, whatever platform you choose: they all work. The failures happen in planning, scoping, data preparation, and change management.

This is the checklist I wish someone had given me before my first CRM migration. It's the framework I use with every client now.

Phase 0: Before You Decide to Migrate

Should You Actually Migrate?

This is the question that doesn't get asked enough. Migrating CRMs is expensive, disruptive, and risky. Before you commit, make sure you've exhausted the alternatives:

Can you solve the problem with configuration changes? Many CRM frustrations are symptoms of poor implementation, not platform limitations. A re-architecture of your current instance might deliver 80% of the value at 20% of the cost and disruption.
Is the pain specific or systemic? If the complaint is "Salesforce is hard to use," that might be a training and UX optimization problem, not a platform problem. If the complaint is "our platform can't support product-led growth motions and our pricing model requires CPQ capabilities the system doesn't support," that's a legitimate platform gap.
Have you quantified the cost of staying? Migration has a cost. So does not migrating. Make sure you're comparing apples to apples. That means total cost of ownership over 3-5 years, including implementation, training, lost productivity during transition, and ongoing administration.

If you're unsure whether to migrate or optimize, the signals in 5 Signs Your RevOps Stack Is Costing You Revenue can help you calibrate.

Checklist item: Document the business case with specific, measurable outcomes the migration must achieve. If you can't articulate what success looks like in concrete terms, you're not ready.

Phase 1: Pre-Migration Assessment

Stakeholder Alignment

[ ] Identify executive sponsor with budget authority and organizational clout to push through resistance
[ ] Map all affected teams (Sales, Marketing, CS, Finance, Support, Product) and identify a champion in each
[ ] Document each team's top 3 requirements and top 3 fears about the migration
[ ] Establish a steering committee with real decision-making authority, not just an advisory role
[ ] Agree on decision-making framework: who has final say when requirements conflict (they will)

This isn't bureaucracy. I've seen migrations stall for months because Sales and Marketing couldn't agree on the lead object model and there was no clear escalation path. Decide the governance structure before you start, not when you're stuck.

Current State Documentation

[ ] Complete inventory of all objects, fields, and relationships in the current system (including custom objects)
[ ] Document all automation rules, workflows, process builders, and flows, including what they do, who owns them, and whether they're still needed
[ ] Map all integrations: what connects to the CRM, what data flows in which direction, what middleware is involved
[ ] Catalog all reports and dashboards, identifying which are actively used vs. created and forgotten
[ ] Document all user roles, permission sets, and sharing rules
[ ] Inventory all installed packages and managed apps

Checklist item: If you can't produce a complete system inventory, budget 2-4 weeks for a discovery phase before planning the migration. Migrating from a system you don't fully understand is a recipe for disaster.

Data Quality Assessment

[ ] Run a full duplicate analysis across all major objects (accounts, contacts, leads, opportunities)
[ ] Assess field population rates: which fields have meaningful data and which are empty shells?
[ ] Identify data quality issues: inconsistent picklist values, free-text fields that should be structured, data in wrong fields
[ ] Determine historical data requirements. How far back does each team need data? (The answer is never "everything" when you push on it.)
[ ] Flag any data compliance considerations (GDPR, CCPA, industry-specific regulations)

Checklist item: Clean your data before migration, not after. Migrating dirty data to a new system just gives you dirty data in a new system, with the added complexity of learning new tools while trying to clean up.

Phase 2: Architecture and Design

Data Model Design

This is the most consequential phase of the entire project. The data model you build determines what's possible in the new system.

[ ] Design object model from scratch based on current business requirements (not a replica of the old system)
[ ] Define the account/contact/opportunity structure (sounds basic, but the decisions here ripple everywhere)
[ ] Plan for hierarchy management: parent/child accounts, multi-entity customers, partner relationships
[ ] Map the full lead-to-cash object flow: Lead > Account/Contact > Opportunity > Quote > Order > Invoice
[ ] Define picklist values and validation rules upfront. Standardize before you migrate, not after
[ ] Plan for scale: will this model work when you're 3x your current size?

The cardinal rule: Do not replicate your old system's complexity in the new one. This is the single most common mistake in CRM migrations. Teams painstakingly recreate every custom field, every workflow, every automation from the old system. They end up with a new platform that has all the same problems as the old one, plus the added baggage of a traumatic migration experience.

Instead, start from business requirements. What does each team need to do? Build the minimum viable system that supports those requirements. You can always add complexity later. You can't easily remove it.

Integration Architecture

[ ] Prioritize integrations by criticality: which must be live on day one vs. which can wait?
[ ] Choose integration approach: native connectors, middleware (Workato, Tray, etc.), or custom API
[ ] Design data flow diagrams for each integration, covering source system, direction, frequency, and error handling
[ ] Plan for the transition period: how will integrations work during the cutover when both systems might be running?
[ ] Identify any integrations that should be retired rather than rebuilt
[ ] Build an integration testing plan with specific test cases for each connection

For a broader perspective on how integration architecture fits into your overall stack strategy, see Building a RevOps Tech Stack for 2026 That Drives Revenue.

Workflow and Automation Design

[ ] Audit all existing automations and categorize: keep (rebuild), modify, or retire
[ ] Design new automations based on current process requirements, not historical precedent
[ ] Document trigger conditions, actions, and expected outcomes for every automation
[ ] Plan automation deployment sequence, since some workflows depend on others
[ ] Build a testing protocol for each automation (input scenarios, expected outputs, edge cases)

Checklist item: If an automation exists in your current system and nobody can explain why, do not rebuild it. Archive the documentation and move on. If it was important, someone will notice it's missing, and then you can build it properly with clear requirements.

Phase 3: Data Migration

Field Mapping

[ ] Create a complete field-by-field mapping document: source field > target field, with transformation rules
[ ] Identify fields that need data transformation (format changes, picklist value mapping, currency conversion)
[ ] Plan for fields that exist in the old system but not the new (intentional retirement vs. oversight)
[ ] Map record relationships and lookups (these are the hardest part of any migration)
[ ] Document the migration sequence: which objects must be loaded first due to relationship dependencies?

Migration Execution Plan

[ ] Choose migration approach: big bang (everything at once) vs. phased (team by team or object by object)
[ ] Build a staging environment and run at least two full test migrations before the real thing
[ ] Define data validation checks: record counts, spot checks, relationship integrity, calculated field verification
[ ] Plan rollback criteria: what specific failures would trigger a rollback to the old system?
[ ] Schedule the migration window and communicate it broadly. Expect 24-48 hours of reduced access for a mid-market migration
[ ] Assign someone to own the go/no-go decision and give them explicit authority

Historical Data Decisions

This deserves its own section because it's where projects get bogged down.

[ ] Define retention requirements by object type with input from compliance, finance, and operations
[ ] Decide activity history approach: migrate all? Last 12 months? Summary records only?
[ ] Plan for attachment and file migration (often the most time-consuming part)
[ ] Consider an archive strategy: keep the old system in read-only mode for historical reference rather than migrating everything

My strong recommendation: migrate the minimum historical data needed for current operations. Every historical record you migrate increases complexity, cost, and risk. If a sales leader needs to reference a deal from 2019, they can look it up in the archived old system. They don't need it cluttering the new one.

Phase 4: User Adoption and Enablement

This is where most CRM migrations succeed or fail. I'm putting it as its own phase because too many teams treat it as an afterthought. A few training sessions the week before launch and call it done.

Change Management

[ ] Develop a communication plan that starts 8-12 weeks before launch, not the week of
[ ] Address the "what's in it for me" question for each team, because people adopt tools that make their lives easier
[ ] Identify likely resistance points and develop specific mitigation strategies
[ ] Recruit power users from each team as champions and give them early access
[ ] Create a feedback mechanism that's visible and responsive. People need to feel heard

Training Program

[ ] Build role-specific training paths, because a sales rep's training is very different from a marketing ops person's training
[ ] Create training in the actual system with real (anonymized) data, not a generic demo environment
[ ] Provide quick reference guides for the 10 most common tasks per role
[ ] Schedule training sessions as close to launch as possible. Training done 4 weeks early is forgotten by launch day
[ ] Plan reinforcement training at 30, 60, and 90 days post-launch
[ ] Budget for ongoing training as the system evolves (this isn't a one-time investment)

Adoption Metrics

[ ] Define adoption KPIs before launch: login frequency, record creation rates, data quality scores, feature utilization
[ ] Set up dashboards to track adoption in real-time from day one
[ ] Establish a threshold below which intervention is triggered (e.g., if any team's adoption drops below 70% in the first 30 days, escalate immediately)
[ ] Plan for the "trough of disillusionment." There will be a period 2-4 weeks post-launch where frustration peaks and adoption dips. This is normal. Having a plan for it is what separates success from failure.

Phase 5: Post-Launch Support

Hypercare Period (First 30 Days)

[ ] Staff a dedicated support channel (Slack, email, whatever your org uses) with extended hours for the first two weeks
[ ] Triage and resolve issues within defined SLAs: critical (4 hours), major (1 business day), minor (1 week)
[ ] Run daily stand-ups with the migration team for the first two weeks, then move to weekly
[ ] Document every issue and its resolution, because patterns will emerge that point to systemic fixes

Optimization (Days 31-90)

[ ] Review adoption metrics and address any teams or individuals lagging behind
[ ] Implement Phase 2 features and integrations that were deferred from initial launch
[ ] Conduct retrospective with all stakeholder groups: what worked, what didn't, what's still needed
[ ] Begin building the reporting and analytics layer: basic reports at launch, advanced analytics by day 60-90
[ ] Document the system architecture, including all customizations, automations, and integrations. Future you will thank present you

The Meta-Lesson

Every CRM migration I've been involved with has confirmed the same truth: the technology is the easy part. The hard parts are decisions (what to build, what to leave behind), data (cleaning it, mapping it, validating it), and people (getting them to adopt the new system and abandon their workarounds).

If you invest disproportionately in the hard parts (and specifically in user adoption, which is the #1 predictor of migration success) your odds improve dramatically.

We help companies navigate this process through our CRM & Platform Migrations practice. Whether you're moving from HubSpot to Salesforce, Salesforce to HubSpot, or consolidating multiple CRMs after an acquisition, the checklist above applies. The details change. The principles don't.

A CRM migration done right is a once-in-a-generation opportunity to rebuild your revenue operations foundation. Don't waste it by recreating the same problems in a shinier package.