CRM Migration Guide: Five Phases from Discovery to Stabilize

A CRM migration is a forced event. Your Salesforce renewal is two quarters out, the quote came back 3x what you paid last year, and leadership wants a HubSpot proposal on the table by end of month. The good news: if you plan carefully, the cutover is a weekend, not a month. The bad news: if you wing it, you will lose pipeline visibility at the worst possible time.

This guide walks through an end-to-end CRM migration — from the decision checkpoint, through data preparation and cutover, to the back-office modules that CRMs don't cover natively. It is written for RevOps leads running a Salesforce → HubSpot migration but the pattern applies to any CRM swap.

If you haven't yet decided whether to migrate, start with how to select a CRM. This post assumes the decision is made.

The five-phase migration plan

Every successful migration we've seen follows the same arc:

The total calendar is 10–16 weeks for a mid-market company. Teams that skip Discovery always overrun in Build. Teams that skip Stabilize lose users and end up with two half-working CRMs.

Phase 1: Discovery

Before you touch the target system, document what you actually have in the source. A pre-migration audit covers the tactical detail — here are the strategic questions.

The four inventories

1. Objects. Which standard objects (Contacts, Companies, Deals, Tickets) carry real volume? Which custom objects are load-bearing? Anything with fewer than 50 active records is probably abandoned.
2. Fields. Every property, its type, its usage rate. A field used on <5% of records is a candidate for deletion, not migration.
3. Workflows. Every automation, its trigger, its downstream effect. Workflow rot is where migrations die — a "simple" CRM has 400 rules accumulated over five years.
4. Integrations. Every system that reads from or writes to the CRM. Marketing automation, billing, support desk, BI warehouse, analytics, data enrichment. Each one is a cutover task.

The usage matrix

For each object and each field, score:

• Criticality: does the business stop without this?
• Volume: how many records, how often updated?
• Owner: who actually maintains it?

This is your prioritization. Anything High/High/Named-owner migrates day one. Everything else goes into Phase 2 backlog.

Phase 2: Design

Schema mapping

Create a mapping document. One row per source field, five columns:

The "Transform" column is where reality lives. Salesforce picklists with 400 values need consolidation. HubSpot doesn't do formula fields the same way. Multi-currency amounts need normalization. Write the transform in plain English first, then in code.

Pick your migration tool

There are four paths:

1. Native import — CSV upload into HubSpot. Works for <10k records and simple schema. Free but brittle.
2. iPaaS (Workato, Zapier, Tray) — point-and-click ETL. Good for SMB. Expensive at volume.
3. Purpose-built migration tool — Import2, Trujay, Funnel. Fast for standard objects, awkward for custom schema.
4. Code — Python script against both APIs. Full control, most work. Right for anything with complex business logic.

We recommend starting with code for the hot path (Contacts, Companies, Deals) and native import for the long tail.

Decide the cutover strategy

• Big bang — one weekend, flip the switch. Lower cost, higher risk. Right for companies with <100 users.
• Parallel run — both systems live for 4–8 weeks. Higher cost, lower risk. Right for regulated industries and 500+ user teams.
• Phased — department by department. Only works if departments don't share pipeline.

Phase 3: Build

Load data in the right order

Dependencies matter. If you load Deals before their Companies exist, associations break.

# Correct load order
LOAD_ORDER = [
    "companies",      # no dependencies
    "contacts",       # associate to companies
    "deals",          # associate to contacts and companies
    "line_items",     # associate to deals and products
    "tickets",        # associate to contacts and companies
    "notes",          # associate to everything above
    "activities",     # associate to everything above
]

Load in test mode first. HubSpot lets you tag imports with a staging property — use it so you can bulk-delete if something goes wrong.

Rebuild workflows, don't port them

Resist the temptation to recreate every Salesforce Process Builder rule. Most are dead weight. Ask the rule owner: "does the business still need this?" Half the time the answer is no.

Rebuild the workflows that survive the interview, using HubSpot's native syntax. This is also when you find automations that never worked in the first place.

Handle the back-office gap

This is where migrations fail in the final mile. HubSpot is excellent at top-of-funnel but ships with gaps in:

• CPQ — quote lines, bundles, approval routing
• Billing — multi-entity invoicing, usage-based pricing, RevRec
• Inventory — for companies that sell physical goods
• Procurement — purchase orders, vendor management
• Multi-currency — beyond basic conversion

Salesforce covers these (at a price) via Revenue Cloud, CPQ, and third-party apps. HubSpot doesn't, natively. Plan for this before the cutover, not after. Sanka is the back office layer that completes HubSpot in these areas — billing, inventory, CPQ, and revenue operations, native to the CRM you just moved to.

Phase 4: Cutover

The cutover itself is a single weekend if you've done Phase 3. Standard checklist:

• Friday EOD — freeze writes on source system. Announce to users.
• Friday night — final delta sync. Move records updated since last full load.
• Saturday — validation. Spot-check record counts, association counts, field population rates.
• Sunday — switch integrations. Point marketing automation, billing, support at the new CRM.
• Monday AM — users log in, find bugs, file tickets.

The Monday AM bug list is normal. Expect 30–80 tickets in the first week. Triage them with a named oncall, not the admin's inbox.

Phase 5: Stabilize

The first four weeks post-cutover are the real test. You will find:

• Reports that relied on fields that didn't migrate
• Automations that fire twice because you forgot to disable the source-side rule
• Dashboards that show zeros because the BI warehouse still points at Salesforce
• Users who hate the new UI and are "still using Salesforce for now"

Address the last one head-on. Set a hard cutoff (2 weeks post-cutover) after which the source system is read-only. Otherwise you have two sources of truth and the migration has failed.

Common failure modes

1. Underestimating custom objects. Teams budget two weeks for "the data" and discover six custom objects with 80k records and circular dependencies.
2. Skipping the integration inventory. The BI team finds out you migrated three weeks after the fact when dashboards stop updating.
3. Copying dead workflows. The new CRM inherits every technical-debt automation from the old one. Fresh start > verbatim port.
4. Ignoring the back-office gap. HubSpot works for the CRM use case; billing and inventory need separate planning.
5. No cutover freeze. Users keep writing to the source system during the final delta sync. You lose a day of updates.

What to do this week

If your migration is <6 months out:

1. Complete the four inventories (Phase 1).
2. Start the field mapping document.
3. Identify the back-office gaps and scope how you'll fill them.
4. Pick a cutover strategy and commit to a date.

If your migration is already in Phase 3 or 4, make sure you have a named oncall for Phase 5 and a hard cutoff for source-system writes.

For a deeper tactical audit, see the HubSpot pre-migration audit checklist. For help scoping the back-office layer, see Sanka's migration service.