- A successful import doesn't prove a successful migration. Records can arrive intact while their relationships, meanings, and downstream workflows quietly break.
- Before you move any critical field, answer five questions: what it means, which system owns it, what triggers a change, where it needs to go, and how you'll prove it works.
- Use the ten-area checklist below. Each check pairs what to verify with the evidence that shows you're ready.
- Test real customer journeys, not just record counts. "Cancellation scheduled" and "access ended" can be two different moments, and one combined field can get both wrong.
- You're ready to switch when critical scenarios pass, every discrepancy is explained, the owners sign off, and everyone knows what happens if something goes wrong.
Direct answer: Before switching CRMs, verify ten things: your business goals and scope, field and stage definitions, which system owns each piece of data, data quality and duplicate rules, relationships and history, automation behavior, integration behavior, reports and permissions, staff readiness on real customer scenarios, and your cutover and recovery plan. For each one, require evidence, not just a checked box.
I've spent years teaching CRM fundamentals in the classroom and training new employees on the systems we build. One pattern shows up every time: people can't use a pipeline stage or a status field consistently until they understand why it exists and what it controls. A new hire who doesn't know what "Qualified" means will move deals there on instinct, and the reports quietly drift.
A CRM migration exposes that same gap across an entire organization at once. The data moves, but the meaning doesn't automatically move with it. This checklist is built to carry the meaning across, too.
01 — The quick version
The Before-You-Switch CRM Migration Checklist
If you're heading into a migration meeting, start here. Each item gets its own "what to verify, why it matters, how to prove it" breakdown further down.
Ten things to verify before you switch CRMs
- Outcomes and scope: what the new CRM must improve, who owns the project, and what is explicitly out of scope
- Field and stage definitions: what every critical field, value, and stage means, in writing
- Data ownership: which system is the authority for each fact, and how updates flow
- Data quality and identity: cleanup, matching, and duplicate rules agreed before import
- Relationships and history: contacts, companies, deals, owners, and activities still connected
- Automation: workflows that should run, and protection against ones that shouldn't fire during the move
- Integrations: connected systems tested for updates, repeats, delays, errors, and recovery
- Reports and permissions: key numbers reconcile, and the right people see the right data
- People: staff complete real customer scenarios and can explain the key stages
- Cutover and recovery: a rehearsed launch plan and a clear answer to "what if it goes wrong?"
02 — The hidden risk
Why Can an Accurate Import Still Produce a Broken CRM?
Because a CRM isn't a spreadsheet of names. It's a model of how your business works. A few terms are worth getting straight before you verify anything:
- Records: the people, companies, and deals you track
- Fields: the individual facts on each record, like email or status
- Relationships (associations): the links that connect a contact to a company, a deal, or an activity
- Lifecycle stages: where someone is in their relationship with you, from lead to customer
- Pipeline stages: where a specific deal sits in your sales process
- Automations: the follow-ups, assignments, and alerts those values set off
Every one of those can survive an import "successfully" and still be wrong. The platform documentation is clear about how this happens:
- Relationships depend on matching rules. HubSpot's import documentation notes that without unique identifiers like email, company domain, or Record ID, "the import will create duplicate records instead of associating each to the same record."
- Associations and activity history need their own review. HubSpot's migration checklist calls for defining object mappings, preparing import files with associations, running a test import, and reviewing the results for field mappings, associations, and engagement data.
- Connected systems don't always deliver updates in order. Recurly's webhook documentation says an endpoint "must accept the same notification more than once and tolerate events arriving out of order," and recommends confirming current state through the API rather than trusting the notification alone.
That's why the rest of this checklist asks for proof instead of record counts.
03 — The framework
What Should You Know About Every Critical Field Before You Move It?
Not every field deserves a meeting. But the ones that drive follow-up, access, billing, or reporting do. For those, I recommend a simple rule:
Before moving a critical CRM field, explain what it means, who maintains it, what it controls, and how you will verify it.
We turn that into five questions. Think of it as a working framework for this checklist, not an industry standard: Meaning, Owner, Trigger, Destination, and Proof.
| Question | What it asks | Worked example: a "Status = Active" field |
|---|---|---|
| Meaning | What does this value actually describe? | Does "active" mean an active customer relationship, an active subscription, or eligibility for access? Those are three different facts. |
| Owner | Which system is the authority for this fact? | Billing owns subscription status. The membership platform owns access. The CRM shows both, but doesn't decide either. |
| Trigger | What changes it, and when does the change take effect? | A cancellation request, a failed renewal, or a scheduled end date, each on its own timing. |
| Destination | Which systems and people need it? | CRM, membership, support, email, and the revenue report. |
| Proof | What test shows it works after the switch? | Run a cancellation, a renewal, and a reactivation in the test environment and confirm every destination shows the agreed result. |
Here's the same worksheet, blank, for your own critical fields. Copy it into your migration plan and fill in one row set per field.
| Field: ____________________ | Your answer | Who confirmed it |
|---|---|---|
| Meaning | ||
| Owner | ||
| Trigger | ||
| Destination | ||
| Proof |
One more distinction matters here: a CRM can give you a consolidated view of the customer without being the authority for every field on that view. Sales, billing, accounting, and membership systems may each own different facts. Ownership should follow the rules your business agrees on, not whichever system happens to display the field.
Retain, redesign, archive, or retire
"Preserve everything" sounds safe, but it can carry broken processes into a brand-new system. For each field, stage, and automation, decide on purpose:
- Retain: it works and people use it correctly
- Redesign: the need is real, but the current definition is ambiguous or overloaded
- Archive: keep the history for reference, but stop using it going forward
- Retire: nobody can explain what it means or who relies on it
04 — The full checklist
Verify These Ten Areas Before You Switch
Each area follows the same pattern: what to verify → why it matters → how to prove it.
| Area | What to verify | Why it matters | Evidence you're ready |
|---|---|---|---|
| 1. Outcomes & scope | What the switch must improve, and what it won't touch | Without agreed scope, every request becomes "while we're at it" | A named owner, agreed improvements, and written exclusions |
| 2. Field & stage definitions | Meaning, allowed values, and entry criteria for each stage | People can't follow a process they can't explain | A documented definition for every critical field and stage |
| 3. Ownership & dependencies | Which system owns each fact and how updates flow | Two systems "owning" one fact will overwrite each other | A system map with authoritative sources and update rules |
| 4. Data quality & identity | Cleanup, matching keys, and duplicate-resolution rules | Missing identifiers create duplicates instead of links | Approved cleanup and matching rules, run against a test import |
| 5. Relationships & history | Contacts, companies, deals, owners, and activities stay connected | A contact without its company or history loses its context | Sampled records show correct associations and essential history |
| 6. Automation | Which workflows change, and which must stay off during import | Imported records can trigger real emails, tasks, or alerts | Agreed workflow changes and a tested "no surprise sends" control |
| 7. Integrations | Updates, repeat events, delays, errors, and recovery | Connected systems can resend or reorder events | Test cases for duplicate, late, and failed events, with expected results |
| 8. Reports, permissions & preferences | Key numbers, access levels, and communication preferences | A forecast or opt-out that changes in the move breaks trust fast | Reconciled business figures and verified access and opt-out behavior |
| 9. Customer journeys & staff | Real scenarios, run by the people who'll use the system | Training on screens isn't the same as training on decisions | Users complete representative scenarios and explain key stages correctly |
| 10. Cutover & recovery | Launch steps, final-change capture, monitoring, and rollback decisions | Changes made during the switch are the easiest to lose | A rehearsed plan with named owners for every recovery decision |
Notice how many of these overlap with integration work. If your CRM exchanges data with billing, eCommerce, or membership systems, the migration is an integration project too. Our guide to how CRM integrations work covers that side in more depth.
05 — A worked example
Following One Customer Across CRM, Billing, and Membership
Record counts won't catch meaning problems. Customer journeys will. Here's one subscription customer, followed through five moments, with the system that owns each fact:
- Purchase. Billing creates the subscription. The CRM moves the contact to "Customer." Membership grants access.
- Onboarding. The CRM tracks onboarding tasks and the owner assigned to the account.
- Failed payment. Billing retries the charge. Does access continue during the retry period? Does the CRM alert the account owner? Decide, then test it.
- Cancellation scheduled. The customer cancels, but keeps access until the end of the term. Recurly's documentation describes this exactly: a canceled subscription "enters a pre-expiry state and remains active until the selected end date."
- Reactivation or expiration. Recurly notes that a customer can reactivate before that end date. Once the subscription expires, it can't be reactivated, and a new subscription is needed.
Now picture the old CRM with a single "Canceled" checkbox, and an automation that removes access when it's checked. Migrate that field as-is, and a customer who canceled on the 3rd loses access on the 3rd instead of the 30th. Or the opposite happens, and access never ends. The import report shows 100% success either way.
Run through the same journey with the five questions and the problem surfaces before launch: Meaning separates "cancellation requested" from "access ended," Owner assigns each to billing and membership, Trigger ties access removal to the end date, and Proof is a test cancellation that shows access continuing until the right day. This is the same thinking we bring to Recurly integrations, where the webhook says something changed and the API confirms what actually changed.
06 — The decision gate
How Do You Know You're Ready to Switch?
Set a clear gate before launch day, and don't move until every item is true:
Ready-to-switch criteria
- Every critical customer scenario passes in the test environment, end to end
- Every discrepancy between old and new numbers is explained, not just noticed
- The owner of each area has reviewed the results and accepted them
- Recovery decisions are documented: who decides, what triggers a rollback, and what happens to changes made in between
On that last point: a CRM backup is necessary, but it isn't a recovery plan. Restoring records doesn't recall the emails your automations already sent, the invoices billing already issued, or the updates already pushed to connected systems. Plan for those downstream actions before cutover, not after.
07 — Getting help
When Is Outside Help Worth It?
Plenty of small, single-system migrations can be handled in-house with a careful plan. Outside help tends to pay for itself when:
- Your mappings involve custom objects, multiple pipelines, or overloaded fields that need redesigning
- The CRM exchanges data with billing, eCommerce, membership, or accounting systems
- Custom workflows or middleware need to be rebuilt, not just copied
- Leadership depends on reports that have to reconcile on day one
That's the work our CRM setup and automation team does every day: structure designed around how you actually sell, field mapping and clean, deduplicated migration, automation, connected systems, training, and a staged launch. When the CRM is one piece of a larger system, our system integration work covers the connections around it. If you're deciding whether a native connector will hold up after the move, When Does HubSpot Need a Custom Integration? walks through the warning signs.
08 — Common questions
Quick Answers
What should be verified before switching CRM systems?
Verify ten areas: outcomes and scope, field and stage definitions, data ownership, data quality and duplicate rules, relationships and history, automation, integrations, reports and permissions, staff readiness on real scenarios, and the cutover and recovery plan. For each, require evidence such as test results or reconciled reports, not just a checked box.
Do you have to move all of your CRM history?
No. Decide on purpose what to retain, redesign, archive, or retire. Keep the history people actually use for service, sales, and reporting, archive what you need for reference, and retire fields nobody can explain. Moving everything can carry old problems into the new system.
How do you test CRM integrations during a migration?
Test how connected systems behave, not just whether data arrives. Include normal updates, repeated events, delayed or out-of-order events, failures, and recovery, and confirm that each connected system ends up showing the agreed result.
How do you choose the source of truth for CRM data?
Choose it fact by fact, not system by system. Billing may own subscription status, a membership platform may own access, and the CRM may own the sales relationship. Document the owner of each critical fact and how updates flow, then test that the rules hold.
09 — Let's talk
Planning a CRM Switch?
A CRM migration is a rare chance to make your data mean something again: clearer stages, cleaner records, and workflows your team can explain. If you'd like a second set of eyes on your plan, or help mapping the fields and connections that matter most, we'd be glad to help.
Book a Discovery Call with me and the team, or email [email protected]. Discovery calls are free.
Jamie Lords ↗ LinkedIn is CEO of Virgo Development and teaches Business and Marketing at Southern New Hampshire University. Virgo Development designs, migrates, and integrates CRM systems for growing businesses, including connections to billing, eCommerce, and membership platforms. Sources: HubSpot Knowledge Base, "Set up your import file"; HubSpot, "CRM Data Migration Import Checklist"; Recurly documentation, "Overview: Webhooks" and "Expire/cancel subscription." The Meaning, Owner, Trigger, Destination, Proof framework is presented as a working method for this checklist, not an industry standard. Platform behavior changes over time, so confirm current documentation for your own CRM and connected systems. Compiled October 2026.