Luis García, GTM engineer and founder of Drivant. About four years building GTM systems for B2B SaaS, fintech, HR-tech and staffing companies, from early-stage startups to established teams. How I work
Same words, different meanings.
Illustrative, but typical. Each row is a number that will not reconcile until someone signs one meaning.
What has to be decided between two systems and one
- Company A CRMSQL = meeting booked
- then → Definitions signed
- then → Shared customers reconciled
- Company B CRMSQL = budget confirmed
- then → Ownership + comp rules
- then → History + source IDs kept
- Definitions signed
- then → One CRM
- Shared customers reconciled
- then → One CRM
- Ownership + comp rules
- then → One CRM
- History + source IDs kept
- then → One CRM
- One CRMone revenue picture
Takeaway. The migration is the last arrow. Everything to its left is a decision, not a data task.
Where it goes wrong, in order.
Definitions
Both sides sign one meaning per term, or a mapping for a quarter.
Overlap
Shared customers reconciled on domain plus hierarchy, with a reviewed sample.
Ownership
Rules for every account with two owners, agreed with comp.
Move
Records move with source IDs and original dates stored.
Freeze
The retired system goes read-only on a set date.
5 ways it breaks.
Two meanings, one field
Each side's lifecycle or stage values were mapped by label, not by definition. 'SQL' meant a booked meeting on one side and a budget confirmation on the other.
Shared customers counted twice
Overlap was matched only on exact domain. Subsidiaries, regional domains and accounts created by different integrations were never reconciled.
History reset on arrival
Imported records take new create dates and lose stage history unless original dates are stored and reports point at them.
Ownership fights
Ownership was migrated as data, when it's a commercial decision with comp consequences that needed rules before cutover.
Old IDs everywhere else
Every migrated record gets a new ID. Without a stored source ID and a crosswalk, downstream systems quietly break.
When the same account is owned by a rep on each side, who keeps it, and has comp agreed? The Pipeline Leak Teardown answers questions like this one for your company, in one page, without a call.
Get the teardownTradeoffs we decide together, in writing.
| Which system survives | Usually the acquirer's, but not always: the system with the stronger data model and fewer customizations is often cheaper to keep. We decide on cost of rework, not seniority. |
|---|---|
| Unify definitions now or map them for a quarter | Unifying immediately gives one funnel and resets trends; a temporary mapping keeps trends readable while teams adjust. The board calendar usually decides. |
| What not to migrate | Stale leads, dead integrations and unused properties stay behind in an archive. Smaller is safer, but someone has to sign off on what's left out. |
What I check in the first 48 hours.
If both companies count their customers today, will the combined number equal the sum, and do you know why not? That question usually opens the audit. Then, in order:
- Side-by-side definitions of every lifecycle stage, deal stage and 'customer' in both systems, with who signed each
- Overlap between the two customer and pipeline bases: exact domain, hierarchy and name, with a reviewed sample
- Which fields each system treats as source of truth, and which integrations write to them
- Accounts with an owner on both sides, and the revenue at stake on each
- Reports leadership uses today in each company, and the history each depends on
- Downstream systems that store CRM IDs: billing, finance, warehouse, support
Questions.
Can HubSpot or Salesforce merge two accounts natively?
Neither merges two portals or orgs natively. One system absorbs the other through a migration, so every decision about definitions, matching and history has to be made explicitly.
How long does it take?
It depends on the number of objects, integrations and how far the definitions diverge. I scope it after seeing both systems; if it's larger than the standard build, I'll quote it separately up front.
Should we keep both CRMs running for a while?
Sometimes, with a clear cutover date and a freeze on new customizations in the system being retired. Running both indefinitely is how two truths become permanent.
What about marketing history and email consent?
Opt-outs and consent move first and are verified before anything else. Some engagement history doesn't transfer, so we archive what's needed for reference.