A carve-out GTM separation moves the divested business off the parent’s CRM, marketing automation, billing and data stack before the transition services agreement (TSA) expires. Run it in three windows: Day-0 (clone, freeze, secure access), the TSA period (build the standalone stack and migrate), and exit (cut over, decommission, prove reporting). Most GTM separations need 90–180 days.
Illustrative board, not a client
Finance and HR separate along legal-entity lines. GTM data doesn’t: the same accounts, contacts, campaigns and automations serve both the parent and the business being sold.
In a carve-out, the buyer acquires a division that has never run on its own systems. On closing day it still logs into the parent’s Salesforce or HubSpot, sends email from the parent’s domain, invoices through the parent’s ERP and reports through the parent’s BI. The transition services agreement (TSA) rents that access back for a fixed period, typically 3–12 months, at a monthly fee. Every month you run past the TSA end date costs an extension fee, and the parent loses patience fast.
The CRM migration itself is usually the easy part. What sets the real exit date is everything tangled around it: shared customer records, licences and data contracts that belong to the parent, integrations that point at parent systems, and a sending domain the carve-out doesn’t own yet.
Plan backwards from the TSA end date. Aim to cut over with at least three weeks of TSA left, so hypercare happens while the parent’s systems are still there as a fallback.
| Window | Typical timing | GTM workstream | Owner | Exit criteria |
|---|---|---|---|---|
| Window 1 · Signing to Day 0 | ||||
| TSA scoping | Pre-signing | List every GTM service you need from the parent (CRM, MAP, billing, BI, data, domain/email, phone), the duration, the fee and the right to extend. | Deal team + carve-out GM | GTM services named in the TSA schedule with an end date and an extension price |
| Data snapshot | Day 0 | Full export of CRM, MAP, billing and support data scoped to the carve-out; store it outside the parent’s tenant. | RevOps lead | Snapshot verified against record counts in the parent systems |
| Systems inventory | Days 0–14 | Inventory every tool, integration, automation, report and licence the carve-out touches (checklist below). | RevOps lead + IT | Inventory signed off by parent and buyer |
| Ownership rules | Days 0–14 | Decide which accounts, contacts, opportunities and campaigns belong to the carve-out, and how shared customers are handled. | Carve-out GM + parent CRO | Written rules plus a reviewed list of shared accounts |
| Change freeze | Day 0 onward | No new parent-side automation that touches carve-out records without sign-off. | Parent RevOps | Freeze agreed in writing |
| Window 2 · TSA period | ||||
| Target architecture | Weeks 1–3 | Choose the pattern (clone-and-prune, fresh build, or absorb into the buyer’s stack). Pick tools and buy licences. | Carve-out GM + RevOps | Architecture diagram and signed contracts |
| Domain & email | Weeks 2–8 | Register the domain, set up SPF/DKIM/DMARC, warm the sending reputation, plan redirects for the website. | Marketing ops | New domain sending at full volume with inbox placement checked |
| Build | Weeks 3–10 | Objects, fields, pipelines, permissions, routing, scoring, sequences, dashboards. Rebuild integrations against the new endpoints. | GTM engineering pod | Configuration complete; integration test log is green |
| Test loads & UAT | Weeks 8–12 | Two or more full test migrations, reconciliation reports, rep and manager UAT scripts. | RevOps + sales leaders | Record counts and pipeline totals reconcile within 0.5% |
| Billing separation | Parallel | Stand up standalone billing or migrate subscriptions; map invoices to CRM accounts. | Finance + RevOps | ARR in billing ties to ARR in CRM |
| Window 3 · Exit | ||||
| Cutover | TSA end minus 3–4 wks | Final delta load over a weekend, swap integrations and forms, redirect inbound, hand reps new logins. | Pod + RevOps | Reps working in the new system Monday morning |
| Hypercare | 2–3 weeks | Daily triage, fix routing and sync issues, compare reports to the parent baseline. | Pod | No P1 issues for 5 consecutive business days |
| Decommission | By TSA end | Revoke parent access, archive the snapshot, confirm the parent has deleted or partitioned carve-out data per the agreement. | IT + legal | Access-removal log and data-handling confirmation |
Inventory before you design. Tick items as you confirm them; your progress stays in this browser.
Clone-and-prune is fastest. A fresh build is cleanest. Absorbing into the buyer’s stack only makes sense when the buyer already runs a healthy one.
| Pattern | How it works | Typical duration | Choose it if | Watch out for |
|---|---|---|---|---|
| Clone-and-prune | Copy the parent org’s configuration (or a sandbox), then delete everything outside the carve-out scope and load carve-out data. | 8–12 weeks | The TSA is short (under 6 months) and the parent’s setup works reasonably well for this business. | You inherit the parent’s technical debt and licences you don’t need. Plan a cleanup sprint after exit. |
| Fresh build | Stand up a new CRM/MAP designed for the standalone business; migrate only clean, in-scope data. | 12–20 weeks | The TSA gives you 6+ months, the GTM motion is changing, or the parent’s org is heavily customized for other divisions. | More design decisions under time pressure. Lock scope early and keep the first release small. |
| Absorb into buyer stack | Migrate the carve-out straight into the acquirer’s existing CRM and MAP. | 10–16 weeks | The buyer is a strategic acquirer or platform company with a clean, documented system and matching sales motion. | Two data models collide. Treat it as a CRM consolidation, with dedupe and ownership rules. |
| Platform switch | Use the separation to move platforms, e.g. Salesforce to HubSpot or the reverse. | 12–20 weeks | The standalone company is smaller than the parent and the parent’s platform is oversized, or the opposite. | Two big changes at once. Only do it if the TSA leaves room for a full test cycle. See Salesforce to HubSpot. |
Almost every TSA extension we see traces back to one of these eight risks. Most are visible in the first two weeks if you look.
| Risk | What goes wrong | Impact | Mitigation | Owner |
|---|---|---|---|---|
| TSA omits GTM services | Data providers, phone, or the email domain aren’t in the TSA schedule, so access ends at close or can’t be extended. | High | Run the systems inventory before signing. Name every GTM service with an end date and extension price. | Deal team |
| Billing stays entangled | Standalone ARR can’t be produced and renewals can’t be invoiced, so the CRM cutover is useless until billing moves. | High | Start billing separation in week one, in parallel. Tie CRM accounts to billing IDs before migration. | CFO + RevOps |
| Shared-customer disputes | Both sides claim the same accounts; reps lose history or double-contact customers. | High | Written ownership rules and a reviewed shared-account list signed by both CROs before any export. | Carve-out GM |
| Consent and opt-outs lost | Unsubscribes don’t travel with contacts, so the new entity emails people who opted out. | High | Migrate subscription status and suppression lists first; test with a seed list before any send. | Marketing ops |
| Cold sending domain | New domain launches at full volume and lands in spam right when customers need the brand-change email. | Medium | Warm the domain for 4–6 weeks before cutover. See the digital identity migration process. | Marketing ops |
| Hidden integrations | A middleware recipe or API user nobody documented breaks at cutover; leads or orders stop flowing. | Medium | Pull API usage logs and connected-app lists, not just interviews. Rebuild and test every endpoint. | GTM engineering |
| History lost | Only open records migrate; leadership loses the multi-year baseline the deal model was built on. | Medium | Export 24+ months of closed history to the warehouse even if it doesn’t all go into the new CRM. | RevOps |
| Cutover at the TSA deadline | No fallback when something breaks; the parent won’t extend, or charges a premium to. | Avoidable | Cut over 3–4 weeks before TSA end so hypercare runs while the parent systems are still there. | Program lead |
Estimates use JayOh guidance: base weeks by pattern, plus record volume, integrations beyond the first five (0.5 wk each), billing separation (3 wks) and domain warm-up (1 wk on the critical path). Illustrative, not a quote.
We staff carve-outs as an embedded pod: a lead consultant plus Salesforce and HubSpot developers, on a term that covers the TSA window plus one run month after exit.
A current example: a PE-backed software carve-out on a 90-day TSA. The standalone stack is Salesforce, HubSpot Marketing Hub and a sales engagement tool, with Clay replacing the parent’s data-provider contract. The engagement was sized at four months so it covers the full TSA and one run month after. Behind it: 75+ CRM migrations and a domain cutover process built for brand changes.
We engineer growth systems. JayOh builds the RevOps architecture, GTM execution and data infrastructure that turn messy revenue operations into predictable pipeline for B2B SaaS and PE-backed teams.
