CRM Migration Services: How to Move Data Without Losing Leads
by Michael Santiago, Fullstack Developer & SEO
A CRM Migration Is a Revenue Risk Project
It gets scoped as an IT task. It is not one.
The system being moved is the one your sales team works in every day, and the things that go wrong are commercial rather than technical: an open opportunity that lost its owner, a follow up that never fired, a customer history that no longer shows the last three conversations, a form quietly posting into an inbox nobody reads.
The goal is not to move records. Records move fairly easily. The goal is to preserve business continuity while they move, and that is a different and harder problem.
What a CRM Migration Actually Includes
Ten phases, in this order:
Discovery. What the CRM is used for, by whom, and which parts are ignored. This alone often changes the plan, because teams routinely discover that half the workflows have not run in a year.
Data inventory. Every object, field, record count, custom property, and integration, documented.
Field mapping. Source to destination, including the honest list of fields that have no equivalent and a decision about each one.
Data cleanup. Duplicates, dead records, orphaned deals, inconsistent values. Do this before the move, not after.
Workflow mapping. Which automations exist, which matter, and how they get rebuilt.
Integration planning. Everything connected on either side, including the things that only create records occasionally.
Test migration. A full rehearsal into the destination.
User acceptance testing. The sales team works in the new system before it becomes the only system.
Final migration. During a planned freeze, with a rollback path.
Post launch monitoring. Watching lead flow and record creation rather than assuming.
The two steps that get cut under deadline pressure are the test migration and user acceptance testing. They are also the two that catch nearly everything.
What Usually Moves
| Object | Notes |
|---|---|
| Contacts | Usually straightforward, watch for duplicates on merge |
| Companies | Relationships to contacts need explicit mapping |
| Deals and opportunities | Stage definitions rarely match between systems |
| Activities | Calls, meetings, logged interactions. Often partially lost |
| Notes | Usually move, sometimes truncated or reformatted |
| Tasks | Open tasks and their owners need verifying |
| Custom fields | The most common source of silent data loss |
| Lifecycle stages | Definitions differ, so values need translating not copying |
| Tags and lists | Often restructured entirely in the destination |
| Email history | Frequently the hardest item and sometimes not feasible |
| Documents and attachments | Volume and file size limits can bite |
| Ownership assignments | Must be explicit or everything defaults to the importer |
| Consent and opt out records | Legally significant. Verify rather than assume |
The row worth pausing on is consent. Opt out and consent records carry legal weight, and losing them during a migration is not merely inconvenient. Confirm they carried across before the first send from the new system.
What Commonly Breaks
Duplicate contacts when two sources merge. Custom field values dropped because no destination field existed. Ownership defaulting to whoever ran the import, so every rep sees an empty pipeline. Lifecycle stages that mean something different in the new system, quietly corrupting every report built on them. Missing activity history, so a rep calls a customer without knowing about last week's complaint. Email history that did not carry. Automations that no longer fire. Attribution that no longer traces. Form submissions arriving nowhere. Lead notifications going to an address nobody monitors. Pipeline stages renamed in ways that change what the forecast means.
Most of these are silent. That is the defining characteristic of CRM migration failure: the system looks fine, the dashboard loads, and it takes days or weeks before someone notices the follow ups stopped.
The Cutover Checklist
The practical list that protects revenue during the transition:
- Freeze significant workflow changes in the source system before cutover. Moving a target is harder than moving a static one.
- Export and retain a full backup of the source CRM. Keep it well beyond launch.
- Define the temporary lead capture path. Where do inbound leads land during the gap, and who is actively watching it?
- Test every form and integration end to end on the destination, with real submissions.
- Reconcile record counts immediately after migration. Contacts, companies, deals, and activities, against the source.
- Verify open deals specifically. Count, stage, value, and owner.
- Assign owners explicitly rather than relying on an import default.
- Test notifications. Not that they send, but that they arrive with the people who act on them.
- Confirm consent and opt out data before any send from the new system.
- Keep the rollback plan documented and current. It only helps if the decision can be made fast.
If you do nothing else from this article, do numbers three and eight. The temporary lead path and the notification test are where leads actually disappear.
CRM Migration Versus Website Migration
These are separate projects and treating them as one is the most common scoping error in this category.
A website can move while the CRM stays. A CRM can move while the website stays. Both can move in one coordinated replatform, and doing so increases complexity considerably rather than proportionally.
The practical argument for sequencing them: if leads drop after a combined launch, you cannot tell whether the cause was a form on the new site or a routing rule in the new CRM. Diagnosis becomes guesswork at exactly the moment you can least afford it.
A very common and sensible arrangement is moving the website to WordPress while keeping HubSpot as the CRM. The CMS constraint gets solved and the systems your sales team depends on are untouched. That path is covered in HubSpot to WordPress migration, and the decision itself in replatforming versus redesign.
Platform Specific Considerations
HubSpot. Contacts, companies, deals, and tickets map reasonably to most destinations. What causes trouble is workflow logic, lifecycle stage definitions, and marketing automation, none of which have clean equivalents elsewhere. Attribution reporting is particularly hard to reproduce outside HubSpot, and teams that rely on it should establish what the replacement looks like before committing. One specific move we have documented in detail is HubSpot to GoHighLevel.
Salesforce. The object model is the project. Standard objects, custom objects, record types, page layouts, validation rules, and permission sets all have to be understood before anything moves. Opportunity structure and sharing rules are where scope hides, and permissions are routinely underestimated because they are invisible until someone cannot see a record they need.
GoHighLevel. Pipelines, subaccounts, campaigns, forms, and automations are the moving parts. The subaccount structure is the decision to get right early, because restructuring it afterwards is painful. Agencies moving multiple clients should plan the account architecture before migrating the first one.
We take on what we can do properly and say so when a project needs a specialist in a system we do not work in daily. Learning a platform on a client's live pipeline is not a service.
What Drives CRM Migration Cost
Record volume, the number of objects and custom fields, how much cleanup the source data needs, workflow and automation count, integration count, reporting and permission complexity, compliance and consent requirements, and how much testing and user training the team needs.
The largest and least predictable of those is cleanup. Moving clean data between two well matched systems is a fraction of the work of untangling years of inconsistent field usage across three connected tools, and you usually cannot tell which situation you are in until someone looks.
How to Choose a Migration Partner
Look for: data mapping discipline, meaning they document the mapping and show you the fields with no equivalent rather than discovering them at cutover. A backup and rollback process stated before you ask. Integration testing as a named phase, not an assumption. Business process understanding, because someone who does not know what a lifecycle stage means to your sales team will map it wrong. Website and form expertise, because that is where leads physically enter the system. Post launch monitoring with a defined duration. And clear responsibility boundaries, so you know who owns what when something breaks at 6pm on a Friday.
The question that separates good from bad quickly: ask what happens to a field in the source system that has no equivalent in the destination. A good answer involves showing you the list and asking you to decide. A bad answer is that it will be handled.
Frequently Asked Questions
What is included in a CRM migration?
Discovery, data inventory, field mapping, data cleanup, workflow mapping, integration planning, a test migration, user acceptance testing, the final migration, and post launch monitoring. The steps people skip under deadline pressure are the test migration and user acceptance testing, and those are the two that catch almost everything. A migration that goes straight from field mapping to final cutover is not a project plan, it is a hope, and the failures it produces surface in sales meetings rather than in a dashboard.
What breaks most often during a CRM migration?
Not the contact records, which is what people worry about. What breaks is everything attached to them: duplicates created when sources merge, custom field values that had no destination equivalent and were silently dropped, record ownership defaulting to whoever ran the import, lifecycle stages that mean something different in the new system, activity and email history that did not carry across, and automations that no longer fire. The most expensive failure is the quietest one, where forms keep submitting into a system nobody is watching any more.
How do you avoid losing leads during a CRM migration?
Plan the gap instead of hoping there is not one. Freeze significant workflow changes before cutover, export and retain a full backup of the source system, define where inbound leads land during the transition and name who is watching that destination, test every form and integration end to end on the destination before go live, reconcile record counts and open deals immediately after, confirm notifications actually reach the people who act on them, and keep a documented rollback path. The rollback decision has to be made quickly or not at all.
Should a CRM migration happen at the same time as a website migration?
Usually not. They are separate systems with separate risks, and combining them means that if leads drop after launch you cannot tell whether the cause is a form on the new website or a routing rule in the new CRM. Sequencing them with a period of stability in between makes each problem diagnosable. The exception is a genuine consolidation, such as a merger or a full replatform where the two systems are so entangled that moving one without the other creates more work than doing both.
How much does a CRM migration cost?
It is scoped individually because the drivers vary enormously between projects that look similar. What actually moves the number is record volume, how many objects and custom fields are in play, how much cleanup the source data needs, the number of automations and integrations to rebuild, reporting and permission complexity, compliance and consent requirements, and how much user training and testing the team needs. Moving clean data between two well matched systems is a fraction of the work of untangling years of inconsistent fields across three connected tools.
Get a Migration Risk Review Before Moving Any Data
The expensive failures in a CRM migration are the quiet ones, and nearly all of them are findable in advance.
Get a CRM migration risk review and we will map what moves cleanly, what has no equivalent in the destination, where leads could go missing during cutover, which forms and integrations create records, and whether the website should move too. Related reading: the HubSpot to WordPress guide, WordPress migration, and the SEO migration checklist. Book a strategy call or call us at 321-401-7016.