The HubSpot Migration Playbook

Why this playbook exists

HubSpot migrations rarely fail on technical grounds. They fail on three predictable problems: leadership does not align on what HubSpot is for before the build starts, the data model gets bolted on instead of designed, and the team is not trained until the day before launch. This is the playbook INSIDEA uses across HubSpot Migration engagements to avoid those failures.

The methodology works for migrations from Salesforce, Pipedrive, Monday, Zoho, HubSpot CRM Free, or spreadsheets. The structure stays the same. The depth at each step shifts based on the source and the size of the GTM organization.

Phase 1: Discovery

Discovery is not a kickoff call. It is a structured exercise to surface every decision the build will later require. The output is a written architecture brief that the leadership team, sales head, marketing head, customer success head, and INSIDEA project lead sign before any property is created in HubSpot.

What Discovery captures

• Current state: which tool, which process, where the friction sits, what is working that we should not break
• Sales motion: deal stages, deal owners, territories, ICP segments, deal size bands, average sales cycle
• Marketing motion: lead sources, lifecycle definitions, lead-scoring expectations, nurture programs in flight
• Customer success motion: onboarding cadence, expansion play triggers, renewal motion, churn signals already in use
• Reporting requirements: what the CRO sees on Monday, what the board sees quarterly, what individual reps look at every day
• Integration scope: which systems sync, which become read-only, which retire entirely
• Compliance constraints: data residency, retention rules, role-based access, customer-data partition rules

Phase 2: Architecture

Architecture is where the build either earns its keep or breaks. The property model, lifecycle stage definitions, pipeline structure, and integration map all get designed before configuration starts. INSIDEA presents the architecture in a single design session, the leadership team signs off, and only then do we touch HubSpot.

The four architectural decisions that compound

• Property model: which properties exist, on which objects, with which types. Dropdowns where you will segment. Numbers where you will aggregate. No free text where you need to report. Field naming convention is enforced from day one.
• Lifecycle stages: written definitions of Subscriber, Lead, MQL, SQL, Opportunity, Customer, Evangelist. Each transition has criteria. Each transition has an owner. The transition is gated by a workflow that reads required properties on the contact.
• Pipeline structure: one pipeline or many. Stage names mapped to deal motion language, not the HubSpot defaults. Stage exit criteria as required properties. Workflow automation per stage entry and exit.
• Integration map: which systems push, which pull, which sync bi-directionally. The conflict resolution rule when both sides disagree on the same field, written down before the integration is built.

Phase 3: Build and migrate

The build happens in two-week sprints. Sprint one configures the data model: properties, pipelines, lifecycle automation, role-based views. Sprint two migrates data, wires integrations, builds dashboards and reports. The team reviews progress on a weekly working session with the INSIDEA project lead. The leadership team reviews at sprint boundaries.

The three-pass migration discipline

Data migration is the highest-risk part of the engagement. INSIDEA never migrates in one shot. We migrate in three passes.

• Pass 1 sample: about 50 representative records get migrated. We validate every field mapping, surface any encoding issues, and confirm the property types accept the data. Mappings are corrected before the full pass.
• Pass 2 full: every record migrates, with a delta-aware retry mechanism for any record that fails. The migration runs against a staging HubSpot environment first, then production.
• Pass 3 reconciliation: record counts get reconciled against the source. A statistically meaningful sample of records gets spot-checked for accuracy. Any exception is logged and either corrected or documented as known.

Phase 4: Enablement and launch

Enablement determines whether HubSpot becomes the team's daily home or stays a system they avoid. INSIDEA runs role-based training: separate sessions for sales reps, sales managers, marketing operations, and customer success. Each session is hands-on, recorded, and capped at one hour. We train on Tuesday or Wednesday so the team has the rest of the working week to use the system before the weekend break.

Launch is a controlled cutover. Usually it starts with one team or one segment. We watch the first day of activity, fix anything that surfaces, then expand. The team has a single Slack channel for questions and a named INSIDEA consultant on call.

The traps that kill HubSpot migrations

Across HubSpot Migration engagements at INSIDEA, the same five traps come up. Avoiding them is most of what makes a migration succeed.

• Trap 1: Building before deciding. The team configures HubSpot, then debates what each property means. Reverse the order.
• Trap 2: Copying the old data model. The old model is the reason you are migrating. Design the new one cleanly, then map source fields to it.
• Trap 3: Skipping data hygiene. Migrating dirty data into a clean system gives you a dirty new system. Clean at the source or explicitly skip the bad records and document the decision.
• Trap 4: One person owns it. The build needs a sales owner, a marketing owner, a customer success owner, and a leadership sponsor. One person cannot represent four functions.
• Trap 5: No post-launch support window. The first month after launch is when the model gets tested by real volume. Plan for it, do not hope for it.