CRM migration: the playbook B2B teams actually need

A founder messaged me last quarter at 2am Berlin time. "We are halfway through a Salesforce to HubSpot migration. The deals imported but they are not associated with the right companies. Our forecast is broken. The board call is in 11 hours. What do we do."

I have had some version of this conversation maybe 30 times. Different CRMs, different stages, same panic. A team decided to switch tools, treated it like an IT project, ran the import, and discovered on the other side that half their pipeline data is now floating in the void with no associations.

CRM migration is one of the most consequential things a B2B company does and one of the worst executed. The data says 40% of migrations have meaningful data loss or corruption. 70% of failures trace back to inadequate cleanup before the move. Most teams find out which group they belong to on the day after cutover.

I want to walk through what actually works, what breaks, and the playbook I run when a Series A or B company asks me to move them off Salesforce or Pipedrive onto HubSpot. Or vice versa.

Why CRM migrations fail at the same five places

When a migration goes sideways, it almost always fails at one of five spots. The technical export and import are rarely the problem. People focus there because it is the most visible part. The actual damage happens before and after the data move.

The first failure is treating the migration as a tool swap instead of a process redesign. The new CRM is a chance to fix the broken parts of your sales motion. If you replicate every Salesforce field, every workflow, every custom object onto HubSpot, you have spent a quarter and six figures to end up with the same problems in a new logo. I have seen this more than once.

The second is moving dirty data. The typical B2B CRM has a 15 to 30% duplicate rate and 30 to 40% dead weight from inactive contacts, test records, and abandoned imports. If you bring all of it across, you have just paid HubSpot or Salesforce to store your trash and made every report less reliable from day one.

The third is wrong import sequence. You cannot import deals before the companies and contacts they associate to. You cannot import line items before products. Get the order wrong and the associations either break silently or fail loudly, and either way, somebody is rebuilding thousands of records by hand.

The fourth is enabling automation too early. Every workflow, every routing rule, every notification fires at every record as it imports. Reps get paged at 4am. Customers get re-onboarded. Deal stages get reset. This is the easiest mistake to make and the most embarrassing to recover from.

The fifth is no rollback plan. If something goes wrong on day one, what do you do. Most teams have not thought about it. The answer should be written down before the export ever runs.

The four phases of a real CRM migration

A clean CRM migration is not a one-week sprint. The teams that run it well treat it as a 60 to 90 day project with four distinct phases. Skipping any of them is how you end up in the 40%.

The mistake I see in 80% of botched migrations is collapsing phases two and three into a weekend. The team gets a quote from a migration agency, picks a date, and runs the import. The architecture work that should take three weeks gets done in three hours, because the team assumes the new CRM will tell them the right answer.

It will not. HubSpot has different opinions than Salesforce about how a contact relates to a deal. Pipedrive does not have companies as a first-class object the way the others do. Attio uses a totally different schema. If you do not pick a target architecture deliberately, you import yourself into a structure you did not choose, and you spend the next two years fighting it.

Phase one: the audit and clean

This is the part teams want to skip. Do not skip it. This phase decides whether the migration succeeds.

Start by exporting everything from the source CRM. Every contact, every company, every deal, every activity, every custom property, every workflow, every report. Put it in a Google Drive folder. This is your snapshot. If anything goes wrong later, this is what you go back to.

Then run the duplicate analysis. For contacts, the deduplication key is usually email address plus normalized phone. For companies, it is normalized domain plus name. I run this in a Python notebook or in Clay. Most teams find 15 to 25% duplicates on the first pass. A real client of mine, a Series B SaaS company, found 31% on contacts and 18% on companies. They had been running outbound campaigns to duplicates of their own customers for two years.

Next, find the dead weight. Contacts with no activity in 24 months. Companies with no contacts. Deals that have been in the same stage for more than 12 months. Activities older than three years that nobody references. Decide what to archive, what to delete, and what to keep but mark inactive. Almost always, 30 to 40% of records do not need to come along.

Document every custom field. What it is used for. Whether anybody actually uses it. Whether the value is ever filled in. I have audited Salesforce instances with 400 custom contact properties where 280 had data on less than 5% of records. Most were created for a one-time campaign in 2019 and never cleaned up. They will not all move. They should not all move.

The output of phase one is a clean export, a deduped dataset, and a property mapping spreadsheet showing every field in the source, whether it moves to the target, and what the target field is.

Phase two: architect the target

This is where the real value of a migration shows up. You do not move what you have. You move what you should have.

Before opening the target CRM, sketch the data model on paper. What objects matter. How they relate. Which properties drive routing, scoring, forecasting, and reporting. Which workflows you actually need on day one versus day 30 versus never.

In HubSpot, the four core objects are companies, contacts, deals, and tickets. Anything else lives as a custom object, an association, or a property. In Salesforce, you have accounts, contacts, opportunities, leads, and a much richer custom object model. The two systems do not map one-to-one. The lead object in Salesforce, for example, has no direct equivalent in HubSpot. You either treat unqualified contacts as a lifecycle stage on the contact object, or you build a custom object. Each choice has consequences. Decide before you migrate, not after.

Build the pipeline structure next. Most teams have too many deal stages. Five to seven is the right range for a B2B sales process. If you have 12, you are either tracking activities as stages, which kills your conversion math, or you have not actually agreed on what a stage means. A migration is the natural place to fix this.

Then map workflows. For every workflow in the source system, ask three questions. Does it still solve a real problem. Does it solve it the way we want now. Does the target CRM have a better way to do this. About half of migrated workflows should be rebuilt rather than copied. The other half should not exist at all.

The output of phase two is a written target architecture document. Property mapping. Pipeline definition. Workflow inventory. Permission model. Integration list. This is what your migration partner builds against. If you cannot write this down, you are not ready to migrate.

Phase three: migrate in waves

The actual data movement happens last and in a specific order.

The standard order is companies first, contacts second, deals third, activities fourth, attachments fifth. Tickets and custom objects fit in based on their associations. If a deal is associated to a company that does not exist in the target yet, the association breaks silently. If you build it in the wrong order, you get a CRM that looks complete but is structurally hollow.

Run the first pass in a sandbox. HubSpot and Salesforce both let you create test environments. Push a 10% slice of your data, validate it, then break it deliberately to test the rollback. I have learned more from sandbox migrations that I broke on purpose than from any vendor documentation.

When you go to production, do it on a Friday afternoon. Lock the source system at 5pm. Run the import overnight. Validate Saturday morning. Do user acceptance testing Saturday and Sunday. Cutover the team Monday at 9am with all hands available. This is the standard pattern and it works. Doing it in the middle of a quota week is asking for trouble.

A note on automation. Every workflow in the target system should be paused while data is moving. Lifecycle stage changes, lead scoring updates, internal notification emails, deal stage automations, all of it. If you import 50,000 contacts with workflows live, you have just sent 50,000 internal "new lead" notifications and triggered 50,000 sales sequence enrollments. I have seen this happen. It is bad.

The same applies to integrations. Pause the Salesloft sync. Pause the Outreach sync. Pause the marketing automation. Pause Zapier and n8n. Validate everything in the new system before you turn on a single outbound connection. Read more about how I think about this on the n8n automation playbook.

Phase four: cutover and validate

The day after cutover is the day most teams declare victory and move on. That is the wrong call. Day one is when validation actually starts.

Run object count validation first. If you had 47,231 contacts in the source and 47,210 in the target, where did the 21 go. Usually it is records that failed validation rules in the new system. Sometimes it is a silent timeout on the import API. Either way, you need to know.

Then run association validation. For every deal, does it have a company. For every contact, are they associated to the right company. For every activity, is it linked to the right object. These checks catch most of the silent corruption that surfaces in a board meeting two weeks later.

Then run workflow validation. Turn on one workflow at a time, watch what it does, then turn on the next. Most teams turn on everything at once and discover three days later that the new lead alert is firing for every imported record because nobody set the enrollment trigger to "creation date after cutover."

Keep the source CRM read-only for 90 days. Do not delete it. Do not cancel the contract until you have closed a full quarter of business in the new system and validated the forecast against the source. The cost of two extra months of Salesforce is far less than the cost of losing a quarter of pipeline visibility.

Document everything. Every decision, every property mapping, every workflow change, every integration. Hand it to whoever is going to run the system next. CRM migrations create institutional knowledge that lives in three people's heads. Write it down or you will pay for it again the next time something breaks.

Common migration paths and what to watch for

Every migration has its own quirks. Here are the four I run most often and what to expect.

Salesforce to HubSpot. The big trap is the lead object. Salesforce treats leads as a separate object until they convert. HubSpot treats them as contacts with a lifecycle stage. You either redesign the funnel to use lifecycle stages, or you build a custom object. Most teams pick lifecycle stages because it is simpler and matches how HubSpot reports work. The other trap is custom objects. HubSpot has them but they are weaker than Salesforce. If you have heavy custom object logic, plan for some real architecture work.

Pipedrive to HubSpot. The big trap is companies. Pipedrive treats organizations as optional. HubSpot expects every contact to associate to a company. You will need to enrich missing companies during the migration, usually with Clay waterfall enrichment. Plan for it. The other trap is product line items. Pipedrive's are simpler. You will need to redesign quotes if you used them.

HubSpot to Salesforce. Less common but real, usually because a company gets acquired or moves upmarket. The big trap is reporting. Salesforce reports are more flexible but less out-of-the-box. Budget two months of report rebuild after cutover. Workflow Builder logic also does not move directly. You are rewriting in Process Builder or Flow.

Spreadsheet to HubSpot. More common than people admit. Series A teams running their pipeline in Notion or Airtable for 18 months and finally giving up. The trap here is structure. Spreadsheets do not enforce associations. You will spend the audit phase building associations that did not exist before. This actually goes faster than most CRM-to-CRM migrations because there is less legacy mess to undo.

For the architecture choices behind these paths, see how I think about HubSpot vs Salesforce and HubSpot vs Pipedrive.

What a real migration timeline looks like

For a Series A or B B2B company with 20,000 to 100,000 contacts, three to six pipelines, and 10 to 30 sales users, the timeline is usually 8 to 12 weeks of work plus 4 weeks of validation.

Weeks 1 to 3, audit and clean. Weeks 4 to 6, architect the target. Weeks 7 to 9, build in sandbox and migrate in waves. Weeks 10 to 12, cutover and stabilize. Weeks 13 to 16, validate, train, and refine.

If somebody quotes you a four-week full migration for a real B2B company at this size, ask which phase they are skipping. There is always one.

The cost depends on the complexity. A clean Pipedrive to HubSpot move with 30,000 contacts and one pipeline is probably 25 to 50 hours of expert work. A Salesforce to HubSpot move with custom objects, multiple pipelines, marketing automation, and 80,000 contacts is closer to 200 to 400 hours. The agency price ranges accordingly.

How to pick a migration partner

Most CRM migration agencies are good at the technical export and import. Few are good at the architecture. The difference shows up six months after cutover, when your team is either running smoothly or fighting the system.

Three things to ask before you sign with anyone. First, can they show you the property mapping document from a previous migration. Not the dashboard, not the marketing case study. The actual spreadsheet they used. If they cannot, they are running migrations from a template instead of from a plan.

Second, do they require a sandbox phase. If they are willing to skip straight to production to save time, they are willing to break your business to save their own. Walk away.

Third, do they have a written rollback plan. What happens if something goes catastrophically wrong on day one. If the answer is "we will figure it out" or "that will not happen," they have not run enough migrations.

For more on how Ziel Lab approaches CRM work, see our CRM RevOps page and the broader CRM service.

Frequently asked questions

How long does a typical B2B CRM migration take?

For a company with 20,000 to 100,000 contacts and 10 to 30 sales users, plan for 8 to 12 weeks of active migration work plus 4 weeks of post-cutover validation. Smaller migrations from a spreadsheet or simple Pipedrive instance can finish in 4 to 6 weeks. Enterprise Salesforce migrations with heavy custom logic often take 4 to 6 months.

Should we migrate to HubSpot or Salesforce in 2026?

Depends on the team. HubSpot wins on speed of setup, ease of use, and unified marketing plus sales plus service in one tool. It works well for B2B companies up to about 200 sales users. Salesforce wins on flexibility, custom object depth, and enterprise governance. It is the right answer for complex, multi-product, multi-region orgs. Most Series A and B SaaS companies I work with are better served by HubSpot.

Can we do a CRM migration ourselves without an agency?

You can if you have a strong RevOps lead, a clean source system, and a simple data model. You probably should not if your CRM has years of accumulated mess, multiple pipelines, integrations into marketing or finance, or active sales motion that cannot pause. The cost of getting it wrong, in lost pipeline visibility and rep productivity, is almost always higher than the agency fee.

What is the biggest risk during CRM migration?

Silent data corruption. The import looks fine. The counts look right. But associations are broken or workflows are firing on stale data, and nobody notices for two weeks. The fix is rigorous validation in a sandbox before production, then full object count and association validation after cutover.

How do we avoid losing pipeline visibility during migration?

Three things. Keep the source system read-only for 90 days. Do a parallel forecast for the first month, comparing pipeline numbers in both systems. Validate every deal in active stages by hand before cutover. The combination catches almost every silent corruption case before it costs you a quarter.

What to do this week

If you are thinking about a CRM migration, do this before you talk to a single vendor. Run a duplicate analysis on your current contacts. Find your dead records. Count your custom properties and how many actually have data. List every workflow and integration. Write down what your sales process actually looks like, not what your CRM thinks it looks like.

Most of the value in a migration comes from the cleanup and the architecture. The data move itself is mechanical. If you do those two parts well, almost any agency can handle the rest. If you do them badly, no agency can save you.

The team that messaged me at 2am ended up fine. We rebuilt the broken associations over a 36-hour weekend, paused every workflow, validated the data set, and walked back the cutover by 48 hours. The board call happened. The forecast was right. They closed the quarter at plan.

But that is the second-best outcome. The best outcome is the one where the migration just works because the work was done before the import ever ran. That is the playbook. It is not exciting. It is not fast. It is what saves the company.

If you want help with any of this, book an audit and I will tell you exactly where you stand and what to fix first.