You closed the deal. The platform is yours. But the CRM still runs on the seller’s Salesforce instance. Finance pulls reports from their ERP. Customer data sits in their data warehouse, and your website routes through their CDN. Every month, the transition services agreement charges hit your account, often at rates 15 to 30 percent above market, while your team scrambles to figure out what to build, what to buy, and what to migrate.
This is the reality for most operators who inherit a TSA at close. The clock started the moment ink hit paper, and every week of delay compounds cost, extends dependency, and erodes the value creation thesis that justified the acquisition. According to Deloitte’s M&A trends research, TSA extensions are one of the leading causes of integration cost overruns, with poorly managed agreements adding 10 to 20 percent to total separation costs. Before the transition begins, buyers should already understand the target’s digital environment through a structured digital diligence process.
I have worked with portfolio companies mid-TSA who discovered, months into the agreement, that they had no clear exit sequencing, no ownership assigned to critical workstreams, and no visibility into what standalone capability actually required. This article is the disciplined plan those teams needed on Day 1. It covers how to read your TSA schedule for commercial and IT services, how to sequence exits by cost, risk, and dependency, how to build standalone CRM, data, and web capability, and how to track milestones to avoid penalties. At the end, you will find a usable TSA exit tracker you can adapt immediately.
The live problem is a TSA meter running on systems you do not control
A transition services agreement exists because carve-outs and acquisitions rarely come with clean boundaries. The seller agrees to continue providing services, from IT infrastructure to HR administration to customer-facing systems, for a defined period after close. In theory, this gives the buyer time to stand up independent operations. In practice, it creates a burning platform with compounding costs and misaligned incentives.
The seller has no motivation to accelerate your exit. Their operations team is juggling their own priorities. Their IT staff may actively resist the knowledge transfer that lets you leave. Meanwhile, you pay monthly fees that often include margin, sometimes significant margin, baked into the service rates.
Why TSA Overruns Happen
BCG’s research on carve-out execution identifies three common failure modes in TSA management. First, buyers underestimate the complexity of services they are receiving, treating the TSA schedule as a contract document rather than an operational dependency map. Second, they fail to assign clear ownership for each service exit, leaving workstreams orphaned between IT, finance, and business unit leaders. Third, they sequence exits based on contract deadlines rather than operational dependencies, creating situations where a critical system is turned off before its replacement is ready.
The commercial consequence is real. Extensions typically cost 1.5 to 2 times the original monthly rate. Penalties for early termination without proper notice can trigger six-figure charges. And every month of dependency is a month where your data, your customer relationships, and your operational flexibility remain tied to an entity with different priorities.
For operators approaching the first 100 days or managing a carve-out separation, the TSA exit plan is not a back-office administrative task. It is a value creation workstream that deserves board-level visibility and dedicated resources.
Reading the TSA schedule for commercial and IT services
The TSA schedule is the operational map of your dependency. Most buyers review it during diligence, sign it at close, and then file it away. This is a mistake. Within the first week post-close, your integration lead should walk through every line of that schedule with three questions in mind.
What Service Is Actually Being Provided
TSA schedules often describe services in legal language that obscures operational reality. “IT Infrastructure Support” might mean a dedicated server administrator, or it might mean a shared help desk ticket queue. “CRM Access” might include data hosting, user provisioning, and integration maintenance, or it might be read-only access to historical records. For each service, document what you are actually receiving, who on the seller side delivers it, and what would break if it stopped tomorrow.
What Is the True Monthly Cost
TSA pricing typically includes direct costs plus an administrative markup. Some agreements also include usage-based components that can vary significantly. Pull the actual invoices from the first month and compare them to the schedule. Identify any services where actual costs exceed schedule estimates, as these are your priority exits from a pure cost perspective.
What Are the Exit Conditions
Every service should have defined termination provisions: notice period, exit criteria, data handover requirements, and any penalties for early or late termination. Build a calendar of these dates. Note that some services may have interdependencies, where Service A cannot be terminated until Service B is stood up, even if the contract does not explicitly state this.
This analysis feeds directly into your carve-out separation plan, connecting contract terms to operational execution requirements.
How to sequence exits by cost, risk, and dependency
Not all TSA services are equal. Some cost $5,000 per month and carry minimal operational risk. Others cost $50,000 per month and, if mishandled, could take down your customer-facing systems. The exit sequence must account for three factors simultaneously.
Cost Priority
Rank services by monthly cost. The top five to ten cost items typically represent 70 to 80 percent of your TSA spend. These deserve the most aggressive exit timelines and the most dedicated resources. However, cost alone does not determine sequence.
Risk Assessment
For each service, assess the operational risk of a failed exit. What happens if you terminate CRM access before your new system is fully configured and tested? What happens if payroll processing fails during the first standalone pay cycle? High-risk services require longer parallel-run periods and more rigorous testing gates before exit.
Dependency Mapping
Some services cannot be exited independently. Your marketing automation platform may depend on CRM data feeds. Your analytics may depend on data warehouse access. Your customer portal may depend on authentication services. Map these dependencies explicitly. A service with three downstream dependencies must be exited last among that cluster, regardless of its individual cost or risk profile.
McKinsey’s integration research suggests that dependency mapping failures account for roughly 40 percent of TSA extension requests. The culprit is usually a service that seemed standalone on paper but had undocumented integrations with other systems.
Building standalone CRM, data, and web capability
For most acquisitions, the commercial systems, CRM, customer data, marketing technology, and web properties, are where TSA exits create the most friction. These systems touch revenue directly. They contain customer relationships that represent the value you just acquired. And they often have years of accumulated configuration, integration, and data that cannot be replicated quickly.
CRM Separation
If you inherited access to the seller’s CRM instance, your exit path depends on your target architecture. Are you migrating to your existing platform portfolio company’s CRM? Standing up a new instance? The decision affects timeline significantly. A Salesforce-to-Salesforce migration might complete in 8 to 12 weeks. A Salesforce-to-HubSpot migration with data transformation and integration rebuild might take 16 to 24 weeks.
Key decisions: What historical data do you need to migrate versus archive? What integrations must be rebuilt? What custom objects and workflows are business-critical versus legacy artifacts? Your M&A integration playbook for CRM and data should govern these choices.
Data Infrastructure
Customer data, transaction history, and analytics often live in the seller’s data warehouse or cloud environment. Standing up independent data infrastructure requires decisions about platform (Snowflake, BigQuery, Redshift), data pipeline architecture, and access controls. Do not underestimate the time required for data validation. A corrupted migration can damage reporting integrity for months.
Web Properties
Websites and digital properties often share hosting, CDN, SSL certificates, or DNS management with the seller’s infrastructure. These are typically lower-cost services but high-risk if mishandled. A botched DNS migration can take your customer-facing site offline. Build these exits with cushion and parallel-run periods.
If multiple businesses are being consolidated, this workstream should follow a dedicated integration framework.
Setting milestones, gates, and penalty avoidance protocols
Every TSA exit workstream needs defined milestones and quality gates. Without them, teams drift toward deadline-driven panic rather than controlled execution. The gate structure should mirror the risk profile of each service.
Standard Gate Sequence
For moderate-complexity services, a four-gate model works well. Gate 1: Standalone capability spec complete and approved. Gate 2: Build or implementation complete in test environment. Gate 3: Parallel run complete with validation criteria met. Gate 4: Cutover complete, TSA service terminated, and 30-day monitoring period initiated.
High-risk services, those touching revenue, customers, or critical operations, should add a Gate 2.5: User acceptance testing complete with sign-off from business owners.
Penalty Triggers
Review your TSA for penalty provisions. Common triggers include failure to provide adequate termination notice (typically 30 to 90 days), early termination of services with minimum commitment periods, and failure to meet exit criteria such as returning seller-owned hardware or revoking access credentials. Build these dates into your milestone calendar with adequate buffer.
Extension requests should be treated as escalations, not routine administrative tasks. Every extension represents a failure to execute the original plan and triggers above-market rates. Document root causes and remediation actions for each extension.
This milestone discipline integrates with your broader post-merger integration checklist, ensuring TSA exit workstreams connect to overall integration governance.
Cost tracking and the exit business case
TSA exit is a value creation workstream, and it deserves the same rigor you would apply to any investment decision. Build a business case that quantifies the return on accelerated exit.
Cost Components
Your TSA cost model should capture monthly service fees (from the schedule), actual invoiced amounts (which may differ), extension rate premiums, penalty exposure by service, and internal resource costs allocated to exit workstreams. Track these in a rolling 12-month view that shows actual versus plan.
Exit Investment Requirements
Standing up standalone capability requires investment, whether in new software licenses, implementation partners, internal headcount, or infrastructure. These costs should be weighed against TSA continuation costs. In many cases, spending $200,000 to accelerate an exit by three months saves $300,000 in TSA fees and extension premiums.
Board Reporting
TSA status should be a standard board reporting item for the first 12 to 18 months post-close. Report format should include total TSA spend to date, current monthly run rate, services exited versus plan, services at risk of extension, and updated exit forecast with cost implications. This visibility ensures TSA management gets appropriate attention and resources.
According to Bain’s integration benchmarks, companies that treat TSA exit as a board-level priority complete separation 30 percent faster than those that delegate it to operational teams without executive sponsorship.
The working TSA exit tracker document
Below is a TSA exit tracker template structured for immediate use. Adapt the services to your specific agreement, but maintain the column structure to enable consistent tracking and reporting.
| Service | Monthly Cost | Dependencies | Target Exit Date | Build vs Replace | Owner | Status |
|---|---|---|---|---|---|---|
| CRM Access (Salesforce) | $18,500 | Marketing automation, customer portal | 2024-09-30 | Replace (migrate to HubSpot) | VP Sales Ops | G2: Build in progress |
| Data Warehouse (Snowflake) | $12,000 | Analytics, BI reporting, CRM sync | 2024-10-31 | Build (new instance) | Head of Data | G1: Spec approved |
| Marketing Automation (Marketo) | $8,200 | CRM, web forms | 2024-11-15 | Replace (HubSpot Marketing Hub) | CMO | G1: Vendor selected |
| Web Hosting / CDN | $2,400 | DNS, SSL certificates | 2024-08-15 | Replace (AWS + Cloudflare) | IT Director | G3: Parallel run active |
| ERP Read Access (NetSuite) | $6,500 | Finance reporting, data warehouse | 2024-12-31 | Build (new NetSuite instance) | CFO | G1: Requirements gathering |
| HRIS (Workday) | $4,800 | Payroll, benefits administration | 2025-01-31 | Replace (BambooHR) | VP People | Not started |
| IT Help Desk | $3,200 | None | 2024-08-31 | Build (internal + managed service) | IT Director | G4: Cutover scheduled |
| Accounts Payable Processing | $2,100 | ERP access | 2025-01-15 | Build (internal team) | Controller | G1: Process documentation |
How to use this tracker: Update status weekly. Escalate any service at risk of missing target exit date or requiring extension. Review dependencies when any service moves to G3 or later, verifying that downstream services are prepared for the transition. Track cumulative TSA spend against original budget monthly.
Governing the exit with cadence and escalation
A tracker without governance is just a spreadsheet. TSA exit requires a meeting cadence and escalation path that keeps workstreams moving.
Weekly Standup
Fifteen to thirty minutes, attended by all service owners and the integration lead. Review status changes, blockers, and upcoming milestones. Document decisions and action items. This meeting should feel operational, not strategic.
Biweekly Steering Committee
Sixty minutes, attended by executive sponsors (typically CFO and COO or equivalent) plus integration lead. Review overall progress against plan, cost tracking, and any services requiring escalation or additional resources. Approve or reject extension requests at this level.
Monthly Board Update
Include TSA status in board materials. Format: summary metrics (spend to date, current run rate, services remaining), key risks, and updated exit forecast. Flag any services that may impact the integration thesis or value creation timeline.
Escalation Protocol
Define what triggers an escalation: service at risk of missing gate, dependency conflict identified, seller non-cooperation, or cost overrun exceeding 10 percent. Escalations go to the steering committee with a proposed remediation plan, not just a problem statement.
The first 30 days of immediate actions
If you are reading this post-close and have not yet built TSA exit discipline, here is your immediate action list.
Week 1: Pull the TSA schedule and first month’s invoices. Walk through every service with your integration lead and identify the responsible party on both buyer and seller side.
Week 2: Build your TSA exit tracker. Assign owners. Set preliminary target exit dates based on contract terms and operational judgment.
Week 3: Map dependencies. Identify services that cannot be exited independently. Adjust sequencing accordingly.
Week 4: Establish governance cadence. Schedule recurring meetings. Communicate roles and expectations to all owners.
By Day 30, you should have a complete TSA exit plan with ownership, milestones, and cost tracking in place. This does not mean every service has a build-out underway, but it means you have visibility and control.
TSA exit as a value creation discipline
A transition services agreement is not a safety net. It is a temporary bridge with a toll that increases the longer you stay on it. The operators who capture full deal value treat TSA exit as a first-order integration workstream, with dedicated ownership, board visibility, and the same rigor they apply to revenue initiatives.
The tracker and framework in this article give you the structure. What matters now is execution: assigning owners, hitting milestones, and building standalone capability before the meter drains your thesis.
To sequence and execute a TSA exit across commercial and digital systems, DevriX can run it to schedule.
A TSA reduces operational risk, but long-term value comes from disciplined integration after close.
