---
title: "CRM Migration"
type: playbook
evidence_type: method
category: "Migration"
publisher: "LeanScale"
date_modified: 2026-07-27
word_count: 5882
topics: ["revenue-operations"]
canonical_url: https://knowledge.leanscale.team/playbooks/crm-migration-playbook/
source: "LeanScale Knowledge Hub — https://knowledge.leanscale.team"
license: "Free to quote and cite with attribution to LeanScale."
---

# CRM Migration

**Evidence type:** method (what we prescribe)

Every migration moves through the same four phases. The weight sits in phase one — get the Blueprint right and the other three go smoothly. 1 Blueprint Inventory every tool, every field, every function. Flag what needs a specialist. This is where the project is won or lost.

## Four phases, one motion.

Every migration moves through the same four phases. The weight sits in phase one — get the Blueprint
right and the other three go smoothly.
1
Blueprint
Inventory every tool, every field, every function. Flag what needs a specialist. This is where the project is won or lost.
Output Fully-scoped map + field mapping
2
Build
Field-by-field audit, right object sequence, change sets over API, config kept off page layouts until you deploy.
Output Staged new instance, QC'd
3
Enable
Phased rollout — stakeholders, then a pilot, reps last. QA checklists per component. Cutover run like a blackout.
Output Cutover, no business interruption
4
Maintain
You will find broken things — bake in the fix time. Stabilize, reconcile, and size the extras honestly.
Output A stable, trusted instance
The First Fork · Before You Scope

## Which mode are we playing on?

Before a single object moves, settle one question: what kind of migration is this? It sets the whole plan —
the discovery depth, the timeline, and what you show up recommending. There are three modes. Name it out loud
with the customer up front.
Lift & Shift
Move it, don't touch it
Push everything across as-is and figure out the rest later
Fastest on paper — but you're carrying the old mess into the new house
We can do it. We just don't lead with it (see below)
Migrate & Optimize
Our default
Use the migration as the forcing function to fix what's been broken for years
GTM lifecycle, attribution, routing, hygiene — done properly on the way over
Barely more work: we're already moving the data and rebuilding the config
Merger / Acquisition
Two of everything
Reconciling two orgs — stages, scoring, definitions, licensing, dupes
Accept some duplication in V1 ; pick the one couch, keep two gravy boats for now
Its own bag of nuances — sandbox becomes crucial (see Build)
The opinion we lead with
We never actually recommend lift-and-shift. We're already moving every record and rebuilding
the config — so enhancing the go-to-market lifecycle, tightening attribution, and laying in the automations and
CRM best practices we'd want for a friend is barely extra work . Show up recommending the enhanced version
and let the customer opt down — don't offer them the cheap version and hope they upgrade.
The optimization rides on playbooks you already have
"Optimize" doesn't mean inventing anything. It's our existing motions running inside the migration —
GTM Lifecycle , Attribution , Lead Routing , Territory Design . If the customer takes
our recommended defaults, it adds zero time. What burns the clock is bikeshedding — arguing whether a
stage is called "Negotiation" or "Economic Buyer Confirmed." Give an opinion, let them push back, move on.
Sequencing the extras
Each optimization workstream is quoted post-Blueprint and runs during the build —
e.g. attribution ≈ two weeks, kicked off once the Blueprint is signed. They don't stall the migration; they
ride alongside it. Only genuine strong opinions from the customer (a lifecycle they want to redesign,
not just rename) extend the timeline — and that's a Blueprint conversation, not a build one.
Start Here

## Kick off a migration in one paste.

Don't dig through the GitHub repo. Copy this prompt, drop in the customer name, and send it to your Claude.
It clones the template, reads the AGENTS.md , and walks the scoping checklist with you.
paste into Claude
Copy prompt
# CRM Migration — kick off
Clone the LeanScale CRM Migration template repo for my customer [Customer Name] .
Then read AGENTS.md and run the kickoff checklist:
0. Set the MODE (lift-shift / optimize / merger) and the DIRECTION (HubSpot↔Salesforce). Default: optimize.
1. Confirm access to the source and target systems (HubSpot and/or Salesforce).
2. Inventory EVERY integrated tool — treat each as its own mini-project, not a reconnect.
3. Flag components that need a specialist (CPQ, marketing automation, billing / RevRec).
4. Scope every function — sales, marketing, CS, finance, product, data — and find the hidden dependencies.
5. Draft the Blueprint — field-by-field map, object sequence, and the cutover plan.
6. Produce the Blueprint Review — a two-column source→target mapping I can present for the green light.
Ask me anything you need before you start.
What you get

### A customer-specific repo

The clone becomes part of the customer's brain — the source and target schemas,
the field map, the tool inventory, and every cutover decision live here and inform their agent going forward.
Inside it

### Skills + an AGENTS.md

Per-platform skills for both Salesforce and HubSpot , the scoping checklist, and the
gotcha library from every migration we've run. The AGENTS file makes kickoff a guided walkthrough, not a scavenger hunt.
1
Phase 1

## Blueprint.

This is where a migration is won or lost. On MediaFly,
nearly every fire traced back to something the Blueprint never found. Scope thin and you pay for it at the end —
one month there, we logged 400 hours on a project we'd priced at 100 .
The case study
MediaFly acquired Epitium and merged the two orgs. The mechanics were doable. What hurt was everything scoping
missed — a tool everyone thought would "just reconnect," a specialized system nobody had built, and a whole function
of the business we never looked at. ~$75k of overrun — a whole extra engineer — that a thorough
Blueprint buys back.
1.0 · How to Run It

### The hard part isn't the data. It's alignment.

The mechanics of a migration are knowable. The esoteric part — the thing that quietly sinks projects — is
stakeholder alignment: getting everyone to agree on how the system behaves in the new world. That's where the
hours go, so run the Blueprint to collapse that, not feed it.
1
Open on the end state, not the current state
Ask one question first: "What does your ideal end state look like?" Consolidated automations, better marketing coverage, whatever it is. Then show them where they are today and how they adapt to get there. It frames everything that follows.
2
Show up opinionated. Don't run open-ended discovery
"Tell me about your flows" and "what objects do you want in Salesforce?" open a can of worms — half the time they don't even know. Be two questions deep on your own, then show up with a plan and a design for them to poke holes in. "You're doing a migration — here's how we'll do it." Let them push back. That's faster than a dozen workshops.
3
Get an explicit green light before the build clock starts
Nothing moves to Build until the customer signs off the Blueprint. Say it plainly: "We can't start until we get a green light." If they're not ready, we're still in Blueprint — that's fine, it just pushes the timeline out.
The project-slot discipline
A migration stuck waiting on stakeholder alignment holds a project slot — sometimes for months, sometimes before
the Blueprint even concludes. That's the customer's choice of how to spend their time, not a delivery
failure. We push them, hard. But we don't own an outcome we don't control: if they can't decide how to
price and package, that's not on the CPQ consultant. Frame the whole engagement so the clock we're
accountable for starts at green light.
1.1 · Integrated Tools

### Inventory every tool. None of them "just reconnect."

Every integrated tool is its own mini-project — not a checkbox. Gainsight, HubSpot, Apollo all told us the
rehook-up was easy, "a couple hours." Every single one had errors and nuances that drew it out for weeks .
1
List every tool touching the CRM — and who owns it
Enrichment, CS platform, marketing automation, billing, dialers, data warehouse. If it reads from or writes to the CRM, it's on the list.
2
Get to someone technical on each vendor's side
The CSM's "super easy, we just swap the instance ID" was never true — it was always the full implementation plus more. Push past the account rep to their solutions engineer and ask what actually has to be rebuilt.
3
Assign one engineer per one or two tools for cutover
Cutover day is a blackout : each engineer owns monitoring and troubleshooting their assigned tools. No one spread across everything.
1.2 · Flag the Specialists

### Which components need a specialist.

The single biggest root cause of a bad migration is the wrong personnel on a specialized component . A generalist
can't scope what they've never built — they don't know what they don't know. In the Blueprint, name the components that
need a specialist and staff them.
If · CPQ, RevRec, or marketing automation is in scope
Bring in a specialist to scope it
These aren't "an admin can figure it out" systems. The person who scopes the cutover has to have lived in it before.
Else · a generalist scopes a black box
The 11th-hour cleanup path
What actually happened on MediaFly — a generalist scoped CPQ, missed what it silently owned, and we were fixing it up to the last day.
Why CPQ is the canonical trap
CPQ builds your custom objects — quote object, approvals, price rules, product rules. The new org has none of it.
You migrate the old quote object to the standard quote object , and re-set opportunity products, formula fields, and roll-ups from scratch.
All the Apex and calculations that came with CPQ are effectively gone.
HubSpot is notoriously weak at standard CPQ — going that direction, this is a big chunk of the build.
Marketing automation is its own project
On MediaFly it surfaced as an afterthought — "can you fix our attribution reporting?" — which unpacked into
no equivalent lead stages, no scoring, no shared MQL definition between the two orgs. It could have been a
devoted project. Which is why you'll almost always run a GTM Lifecycle project inside a migration.
1.3 · Scope Every Function

### Talk to every department — not just the obvious three.

Entire functions surfaced mid-project that were never in scope. Sales, marketing, and CS are the easy ones to
remember. It's the others that bite.
Sales
Obvious
Pipelines, quotas, deal desk
Reps go in last — see Enable
Marketing
Obvious
Scoring, lifecycle, attribution
Nearly always its own workstream
Customer Success
Obvious
Health, renewals, CS platform sync
Finance
Missed
RevRec — formula & roll-up logic
Billing integration, ARR reporting
Product
The killer
Licensing / provisioning off the CRM
App Exchange product in both orgs
Data / RevOps
Missed
Warehouse syncs, reverse-ETL
Reporting that reads the schema
The war story that could have been a lawsuit
MediaFly hosted customer product licensing in both the Epitium Salesforce and their own
App Exchange product — in both instances. We didn't learn it until the week of cutover . If we'd truly lost
access to the old instance the day they said we would, their customers would have lost access to the tool.
That's the class of dependency the Blueprint exists to find — before it can hurt anyone.
1.4 · Data & Duplicates

### Sync-created dupes

HubSpot was syncing prospects to the old org that weren't in the new one, and its database wasn't complete versus Salesforce. The moment you connect, that mismatch spawns new duplicates. Reconcile inclusion lists and databases first.
1.5 · Normalize while you're in there
A migration is the one moment you get to clean house. Consolidate every pick list , unify page
layouts and record pages, and standardize naming. Do it once, deliberately — not field-by-field under fire at cutover.
Blueprint output
A signed-off package: the tool inventory (with vendor technical contacts), the specialist flags ,
the function-by-function scope , the data-reconciliation plan , and — the heart of it — the
field-by-field mapping that Build runs against. Nothing moves to Build until the customer approves it.
1.6 · The Deliverable

### The Blueprint Review — one artifact to get the green light.

This is what you show up with . Not a questionnaire — a compare-and-contrast map : everything they
have today on the left, exactly what it becomes on the right, and the handful of things that won't come over
flagged in red. Tabs for the optimization layers (lifecycle, attribution) show current → recommended → mapped, with
names they can tweak. They poke holes in this — and that's the green light.
Objects & data
Automations & tools
Lifecycle & routing
HubSpot · today Salesforce · new world
Companies → Accounts
Contacts → Contacts Contacts-only model — recommended unless a heavy PLG motion needs Leads
Deals → Opportunities
Line items → Opportunity Products
Tickets → Cases
Native lead score email clicks, form fills, events ⚠ Rewire — or keep scoring in HubSpot and sync the score into Salesforce
HubSpot · today Salesforce · new world
Workflows (hygiene / field-fill) → Flows + validation rules proposed per object from your workflow audit
Forms on web pages → Kept in HubSpot, or Web-to-Lead a real discovery item — where do forms & email live?
HubSpot marketing / email → Stays as the MAP keep it, sync to Salesforce — makes the whole move easier
Gong · Apollo · Gainsight → Re-point & verify each ≈ 10 hrs, its own mini-project — never "just reconnect"
Custom-coded workflow logic ⚠ Manual review going SF→HS, the code node is license-gated and Apex has no equivalent
Current stage Recommended lifecycle · yours to rename
Subscriber / Lead → Inquiry
MQL → MQL shared definition + scoring threshold
SQL → SAL → SQO accepted, then qualified
— (no routing today) → Speed-to-lead routing rides along as the Lead Routing workstream
Opportunity → Customer → Opportunity → Closed Won → Customer
How to run it: present the tab that matters to each group — objects for the admins,
lifecycle for the VP of Marketing, routing for the VP of Sales. The red rows are the honest conversation:
"just so you know, these don't come over cleanly — are you OK with that?" Get the nod on each, and you have alignment.
2
Phase 2

## Build.

Build to the standard, but the discipline here is
verification . The last vendor on MediaFly broke a customer's RevRec because nobody checked the field
types — so we check everything, in the right order, with the right tool for each job.
2.1 · The Field-by-Field Audit

### The field map is a data deliverable — a hard gate.

1
Audit every field — the field itself and its type
The last vendor would "migrate a field" but not migrate the type — or not migrate the field at all. Assume nothing carried correctly until you've checked it.
2
Map to the true equivalent in the target system
For each field: the right type , plus the equivalent field relationships and object relationships it should have in the other platform. A currency field is not a formula field is not a roll-up.
3
Make the mapping a signed data deliverable
Nothing moves forward until the field map is QC'd. This one discipline is what separates a clean migration from an 11th-hour scramble.
What "we didn't check" cost
MediaFly's RevRec broke entirely — the vendor pushed formula fields in as plain currency fields ,
and roll-up fields came in as currency fields too. None of the logic worked. In the background the client kept saying
"this worked before, it doesn't now" — because the numbers looked right but nothing was computing.
2.2 · Using AI to Build

### Sic Claude on the audit — but know its limits.

Claude is the right tool for the field-by-field audit and the bulk build. But there's one trap that makes a build
look perfect while it's silently broken.
✓ What Claude does well
The audit itself — every field, its type, and the target equivalent
Formula fields and bulk field creation
The diff between source schema and target
✕ Where it silently fails
Roll-up fields can't be created via the API — Claude will make a formula field, but not a roll-up. Those go in by hand.
Vendors used AI to create fields, then backfilled the data — so everything looked good. But any net-new record coming in wasn't computing.
The rule: verify a net-new record actually calculates — never trust that backfilled data looking right means the logic works.
2.3 · Sequence the Objects

### Migrate in pieces — not everything at once.

Doing everything at once is why MediaFly slipped: things broke slowly, then it was one person after another saying
"we don't have this, we don't have that." Split the migration by object and move in order.
The migration sequence
Automations layered in along the way
First Accounts →
Contacts & Leads →
Opportunities →
Custom objects
Keep everything off page layouts — admin-only — until you're ready to deploy. The business
keeps working in the old world; the new one is built quietly underneath.
2.4 · How You Move It

### Don't burn the API when a change set will do.

On cutover, an engineer ran out of API credits mid-push, called Salesforce for emergency capacity, and got capped
at a million. Most of that API load was unnecessary.
Config, flows, and sandbox assets
Change sets + data loader
Push flows and config with a change set ; move data with the data loader (export → load). Old-fashioned, fast, and it doesn't touch your API budget. This is domain expertise, not luck.
If you genuinely need the API
Raise limits early + chunk it
Get the emergency API increase before cutover day, not during — and chunk the load into phases so you never hit the wall live.
2.5 · Where You Build It

### Greenfield goes straight to prod. A merger needs a sandbox.

The build environment is decided by the mode. Don't over-engineer a greenfield build with a sandbox it doesn't
need — and don't ever touch a live merged org without one.
Greenfield · a fresh Salesforce, native build
Build straight in prod
HubSpot → a brand-new Salesforce is almost all native config. There's nothing live to break, so a sandbox just adds friction. Keep it admin-only until deploy (see 2.3) and build in prod. Only layer in a sandbox if you're adding net-new custom automations worth staging first.
Merger · into an existing Salesforce instance
Sandbox is non-negotiable
You're mutating a live org other people depend on — stage and test in a sandbox first. And the reverse case is worse: HubSpot's sandbox is nearly useless — you can only promote a limited slice to prod (it used to be none), so a HubSpot company absorbing a Salesforce org is genuinely scary. Scope that early.
One more audit before you build
The target org already has its own life. Existing flows, process builders, workflow rules, and Apex classes
will butt heads with the automations you're migrating in. Audit the target top-down — don't go off what
the client says it has — then build accordingly.
3
Phase 3

## Enable.

For a migration, enablement is a phased rollout:
who gets into the new instance, in what order, and a cutover day run like a blackout. Get the order wrong and reps
are QA-testing a system that isn't ready.
3.1 · Phased Deployment

### Stakeholders first. Reps last. Always.

1
Stakeholders & vertical owners go in first
The people who own each vertical come in, check the business logic, and confirm it works as intended. This is where you catch what's missing.
2
End-to-end test
Once each area is confirmed, test the whole flow end to end — the first time the new instance is exercised as a system.
3
Pilot group of reps
A small group of reps runs their real workflows and hits the errors — before the whole team pulls over. It's a sub-phase of Build, just like any other rollout.
4
The whole team — last
Reps come in last , and they are never your QA testers. They test their regular workflows on a system that already works.
The anti-pattern
On DealHub we kept sending reps in to build quotes before the products or the mappings existed. Of
course it looked broken — the system wasn't ready for them yet. Reps in an incomplete instance generate noise, not signal.
3.2 · QA Checklists by Component

### Opportunity / deal basics

The always-true checks: stages advance, roll-ups compute, required fields gate, amounts and dates carry.
3.3 · Share the responsibility with the client
We triple-check — then we hand the client a specific double-check list of everything to verify in
their day-to-day, not a "casual, loose" one. A precise list means real coverage and shared ownership if
something slips.
Third-party apps repoint last
The moment you move everyone off, repoint the tools — it's naturally the last step . The exception is a
live-data or enrichment tool a pilot needs on day one. Default: push tools at the end and backfill, rather than
flip everything at once and leave the team in an incomplete system.
3.4 · The Parallel Run

### Overlap the two systems. Don't detonate the old one.

The safest cutover isn't a switch-flip — it's an overlap. The new instance is fully built; the team keeps
working in the old one; you run both in tandem and compare outputs before anyone depends on the new world. Aim for
a month. You can do it in less, but a month gives the weird timing room to surface — things that
only fire once a week or once a month need a full cycle to prove out.
1
Ops goes in first — and takes the most time
The people who own the data and the metrics come over first and stay the longest. They validate records, reconcile that the numbers match the old world, and run every process end-to-end. This is where mismatches surface — give it real runway.
2
A pilot of one or two elite reps — kept short
Bring in a couple of your best reps (or the CSMs running renewals) to run one or two real motions — build a quote, work an opp — and confirm there's no disruption and no extra clicks. This should be quick: they run their workflow, they sign off, done. Reps are never the long pole.
3
Full cutover — only once ops has signed off
When ops confirms the data and the reps confirm the workflows, everyone moves. If scope wasn't 100% nailed, this is where "oh, we also need this " appears — sometimes things they never even had in HubSpot. Hold the line to the Blueprint; net-new is a follow-up, not a cutover blocker.
Keep the data consistent both ways
During the overlap, sync bidirectionally — changes made in Salesforce flow back to HubSpot,
so nobody's validating against stale data. The moved-over pod operates in the new world while everyone else stays
put, and the two never drift apart.
Integrations run on both — mostly
Most third-party tools (Gong, enrichment) can dual-connect and run in tandem through the
parallel window. The one hard caveat: HubSpot can sync to only one Salesforce instance — which bites on
mergers. Some tools flip cleanly at cutover; others must wait and migrate slowly. Sequence them, don't assume.
Leave HubSpot as a ghost town — for now
After full cutover, don't kill HubSpot. Keep it alive on the full plan for a while — the
once-a-month automations still need somewhere to land while you confirm nothing was missed. Only once QA and the
checks are done do you downgrade to the free tier ; only later do you shut it off entirely. And a renewal
coming up in 30 days is not a reason to rush the cutover — that's how you skip the parallel run and pay for it.
3.5 · The Cutover Cadence

### Cutover Friday. Run it like a blackout.

Wed · before
Pre-brief
Walk the broader team through what's changing before it lands.
Fri · 2pm
Cutover blackout
One engineer per one or two tools, each on monitoring & troubleshooting. Let it bake over the weekend.
Mon · after
Office hours
First live day — catch what surfaced when the team logged in.
Fri · +1 week
Office hours
Close out hyper-care. Every enablement also gets docs and an audio brief like this one.
3.6 · World-Class Enablement

### Enablement is what kills the maintenance tail.

The more completely you enable, the less ad-hoc cleanup you're doing for months afterward — the boring maintenance
that quietly eats a project. Over-invest here on purpose. Do it in layers.
Looms for everything · front-end users
Day-zero how-tos for someone with zero experience — how to create a contact, an account,
a deal — and how to use Salesforce to interact with every other system in their stack. Record once, hand
off forever. This is the single biggest lever on the maintenance tail.
Looms for everything · back-end users
A separate track for the admins: how to grant permissions , build automations ,
create fields , and update page layouts . Enable them to run the system so the hand-off is clean —
you're not the permanent help desk for their own instance.
Before cutover

### Tailored group demos

You can't cover an end-to-end instance in an hour. Run per-team sessions —
sales director + team, CS director + team — and go deep on what they touch: the POC process, the opportunity
lifecycle, the customer handoff. Specific beats comprehensive.
When you can

### In-person sessions

If you can get on-site, do it — we've never had a bad one. Customers leave with
real confidence and real goodwill toward LeanScale. It's the highest-trust enablement we run.
After cutover

### Office hours, 1–2× a week

Great optics, and genuinely useful early. By week two or three nobody shows up —
which is exactly the signal you want. It means the enablement landed and the system is sticking.
4
Phase 4

## Maintain.

The tail of a migration is stabilization, not surprise.
You will find broken things after cutover — so plan for it, size it honestly, and don't let the estimate
pretend otherwise.
4.1 · The Honest Timeline

### Quote it post-Blueprint — and bake in fix time.

The Blueprint is the big variable and the part you can't control, so frame every estimate post-Blueprint .
With a green check on the Blueprint, a clean migration runs roughly:
~30d
Build & move
Build the new instance and migrate the data, in object sequence.
1–2w
Pilot & QA
Stakeholders, then the pilot group, then end-to-end QA against the checklists.
+2w
Fix what broke
You'll find broken things — so bake the time in . It doesn't mean you did it wrong; it means it's a migration. Call the whole thing ~2 months , and don't promise shorter.
4.2 · Sizing the Extras

### Base migration, then add the specialized work.

Price the base migration on its own, then stack the specialized workstreams on top. Fortune-500-scale runs longer.
Base migration
The floor
Objects, fields, automations, cutover
None of the extras below
+ CPQ
Specialist
Rebuild quote object, rules, Apex
+ RevRec
Specialist
Formula & roll-up logic, billing sync
+ Attribution
Workstream
≈ 60% of a full attribution build
+ Each tool
Per integration
≈ 10 hrs to reconnect & verify, each
The lesson underneath all of it
A migration's smoothness is decided at setup . If you're rushing at the 11th hour, the Blueprint was thin.
Get a proper setup from the start — highlight everything from the beginning — and the rest of the project goes smoothly.
Know Your Direction

## Two platforms, three directions.

The method above is the same every time. What changes is what you gain and lose based on where you're coming from
and where you're going. Read this before you scope.
The question underneath the whole choice
Does the system serve your process, or your process serve the system? On Salesforce you bend the
system to fit how you work. On HubSpot you bend how you work to fit the system — there are workarounds and hacks,
but that's the trade. Know which one you're signing up for before you move. And the honest LeanScale take: the most
flexible, modern, AI-enabled CRM — the one you barely have to log into — is Salesforce. "We want
something more AI-native" is usually an argument for it, not a reason to leave.
Salesforce → HubSpot
Expect to lose ground
CPQ — HubSpot is notoriously weak; big chunk of the work
Object model — you almost never use Leads in HubSpot; decide on contacts-only up front
Automations — the code node (custom logic in workflows) is license-gated; only ~1 in 5 clients have it, so complex SF automations are hard to reproduce
Custom objects — license-based and less flexible
Formula fields — restricted; don't behave the same
Reporting — a different beast; you can't get as granular
You'll rebuild the go-to-market motions either way
HubSpot → Salesforce
More headroom, new mess
You gain flexibility — custom objects, formula & roll-up fields, granular reporting
But you inherit HubSpot's sync, inclusion-list, and duplicate nuance on connect
Reconcile inclusion lists and sync settings , and confirm the fields actually exist to map into
Decide the Lead vs Contact model deliberately — Salesforce gives you the choice HubSpot didn't
Salesforce → Salesforce
The merger (MediaFly)
You're reconciling two of everything — stages, scoring, definitions, licensing
Accounts churned in one org, active in the other — business decisions, not data settings
Product / licensing may live in both instances — find it before cutover
Merge lifecycle, scoring, and MQL definitions — a GTM Lifecycle project rides along
HS deep dive -->
The Hard Direction · Salesforce → HubSpot

### What you'll lose — and what it quietly costs.

The other two directions rarely surprise you. This one does — it's the direction with real casualties, and several
of them show up as line items on a bill. Scope every one and tell the customer plainly what won't come over.
Marketing contacts
A per-record cost
Which contacts you flag as "marketing" carry a cost over your limit
Decide the marketable set deliberately — it's a bill, not a checkbox
Custom & formula fields
License-capped
Field and formula-field counts are limited by tier
Formula fields don't behave the same — don't assume parity
Product data
A nightmare
The custom-object limitation changes how you store and associate it
The Snowflake sync now charges credits per sync — people are freaking out
SF says "dump it all, clean up in-system"; HubSpot wants only what you need
Permissions
Less granular
Salesforce lets you get far more granular — expect to lose that control
Reporting & Apex
A different beast
No formulas / depth like Salesforce reports
Apex classes have no equivalent — flows are one thing, code is very wonky
Other clouds
Open questions
Service Cloud, Marketing Cloud — not just Sales Cloud
We don't have every answer yet; refine the playbook as we hit them
Be explicit about the plan & tier
Half of what "can HubSpot do this?" comes down to is which license they're on. If they're
evaluating either system, tell them plainly which tier they need to land the functionality — we've been bitten by
leaving that vague.
One point in HubSpot's favor
HubSpot's API is more forgiving on request limits than Salesforce's, which are strict and
a pain to raise. It's a rare place the move gains you headroom — worth noting when you're weighing the trade.
The AI gotcha for this direction — build your own docs
You can point Claude at the Salesforce instance and have it pull every Apex class, flow, and report , then
flag what HubSpot can't replicate. But there's a trap: HubSpot's public documentation is so thin that Claude
will confidently say it can do things it can't — and occasionally the reverse. So set the rule:
err on "HubSpot can't do it unless it's explicitly in public documentation," then manually review the list.
Over time this is why we build our own documentation — our domain expertise, not HubSpot's docs,
is the source of truth. Then hand the customer the not-coming-over list up front, so nothing is a surprise.
SF discovery focus -->
The Easy Direction · HubSpot → Salesforce

### Architecture replicates. Discovery goes to the edges.

Almost everything in HubSpot has a cleaner Salesforce equivalent — contacts, companies, deals, reporting all map
straight across. So don't burn discovery on the core object model. Spend it on the edges.
Discovery goes here

### Forms & email marketing

HubSpot forms are usually hosted on their web pages — where do those go? And the
email marketing itself — what's the alternative, or does HubSpot stay as the MAP? This is the real discovery, not the objects.
Keep it simple

### Lead scoring — keep & sync

If HubSpot stays as the marketing platform, keep lead scoring there , sync the score
into Salesforce, and let Salesforce run the MQL automations. Only rewire scoring (email clicks, form fills, events) if HubSpot is going away.
Turn hacks into rules

### Workflows → validation rules

Pull their HubSpot workflows and code-block hacks; propose a clean set of validation rules
per object in Salesforce — starting from our standards (can't close an opp without a close reason) and adding their weird ones.
The one real decision

### Lead vs Contact model

Salesforce gives you the choice HubSpot didn't. Default to contacts-only unless
there's a massive PLG motion — almost nobody should run an open Lead object. Decide it deliberately in the Blueprint.
One QC checklist to rule them
Take the transcript of every migration scoping session and turn it into a QC checklist for whoever runs the
next one. This playbook is that checklist, made permanent — the gotchas we already paid for, so you don't
have to pay for them twice.
✓
Closeout

## Debrief the project.

When a CRM Migration engagement wraps, spend sixteen
minutes with the debrief agent. Teamwork already knows what got built and when. This is for the
part none of our systems can see — the call that could have gone either way, the thing the customer
wanted that you refused, the near-miss that never became an incident, and above all the places
this playbook turned out to be wrong. What comes out of it gets written back into this page.

### Before you start

Two minutes of thinking beats sixteen minutes of recall. Have these in your head —
you don't need notes, and you definitely don't need a script.
Direction and mode — which way the migration ran, and whether this was lift & shift, process optimisation, or a merger.
Which flavours of duplicate you hit — same prospects in both systems, merger reconciliation, sync-created, or all three.
Which cutover rules you bent — overlap vs. detonate, stakeholders before reps, sandbox or straight to prod, and whether Friday held.
Sixteen minutes, one sitting. It's a voice conversation, so your browser will
ask for microphone access — use headphones or the agent will hear itself. Chrome is the safer bet
over Safari.

#### What this is, and isn't

It's a craft debrief , feeding straight back into this playbook.
It is not an assessment. Nothing here goes near performance review.
It's attributed — Anthony reads it with your name on it.
"This took two weeks longer than it should have because of X" is the most useful thing
you can say . Say it.

#### If it doesn't load

No mic prompt? Check the padlock in the address bar — the browser may have blocked it.
Agent talking over you? Headphones. It's hearing itself through your speakers.
Still stuck? Message Anthony rather than burning fifteen minutes on it.
The transcript takes a moment to generate after you hang up. You'll get a recap
emailed to you.

### Hand over the artifacts too

The debrief asks what you built that's worth reusing. This is where you actually hand it
over — dashboards, field maps, flows, templates, scripts, spec docs. Files land in the
project's Drive folder; links go into the artifact register so the next person can find them.
Thirty seconds, and do it while the project is still in your head.
“I'll upload it later” is exactly how assets end up trapped on an account.
Add an artifact →
LeanScale · Delivery OS
The CRM Migration playbook — the internal standard for moving a customer from one CRM to another across
Salesforce and HubSpot, and merging orgs after an acquisition, without stopping the business.
Blueprint, Build, Enable, Maintain.

#### The four phases

Modes — lift-shift / optimize / merger
Blueprint — scope everything
Build — verify everything
Enable — phase everyone in
Maintain — bake in the fixes
Direction — SF ↔ HS + merger
www.leanscale.team

## Canonical

https://knowledge.leanscale.team/playbooks/crm-migration-playbook/