The TSA Clock
/The most expensive month of a lower middle market integration is rarely month one — it is month thirteen, when you are still living on the seller's systems, have stopped treating it as a problem, and the cutover plan has quietly become a running joke.
A Transition Service Agreement (TSA) — the post-close arrangement in which the seller continues to provide access to IT infrastructure, payroll, accounting software, and sometimes physical space for a defined period, typically sixty to one hundred twenty days — is a standard tool in lower middle market M&A. In theory, a TSA is a bridge that gives the buyer time to build out independent infrastructure. In practice, it becomes a residence. The acquirer stays past the agreed term, extends once, then again, then quietly stops tracking it. Eighteen months after close, most buyers are still logging into systems they do not own, running payroll through a vendor relationship they cannot control, and operating on a data architecture that makes independent financial reporting almost impossible.
TSA Creep Happens in Every Lower Middle Market Deal Because Every Extension Is Locally Rational
The mechanism is the same in almost every case. On day one, the team is focused on customer retention, employee stabilization, and operational continuity. The cutover project — standing up independent HR, IT, and finance infrastructure — goes on the roadmap as a month-three priority. By month three, there is always something more urgent: a key customer at risk, a vendor relationship that needs attention. The cutover slips to month six. By month six, the team has adapted to the seller's systems, the pain is tolerable, and an extended TSA looks cheaper than the disruption of cutting over mid-year. The logic is locally rational at every decision point, and the aggregate result is that the buyer never fully owns the business they acquired. They are a tenant in someone else's operating infrastructure, paying rent in TSA fees, operational dependency, and compounding data integration debt.
The Hidden Cost of a TSA Is Not the Fee — It Is the Leverage You Hand the Seller
TSA fees are a real cost, but they are not the largest problem. The largest problem is operational dependency — the buyer's inability to manage, report on, or improve the business without the seller's continued cooperation. A business running on a seller's ERP cannot produce clean financial data independently. A business running payroll through a seller's HR system cannot modify compensation, implement new benefits, or respond to employment issues on its own. A business sharing IT infrastructure with a former owner cannot maintain data hygiene, deploy new software, or grant its own team the permissions they need. Every week inside a TSA is a week where post-merger integration failure points multiply quietly. We have seen TSA overhang last three years; at that point it is not a transition service but a dependency the seller has every incentive to preserve and the buyer has lost the urgency to resolve.
You Run the TSA Clock Correctly by Building the Cutover Plan Before You Sign the TSA
The discipline is not complicated, but it requires intentionality from the first week. Before close, define the cutover plan in parallel with the TSA itself — the TSA sets the deadline, and the cutover plan is the project required to hit it. Assign a single owner to that project with explicit, protected bandwidth. Build the cutover milestones into the first hundred-day plan as a parallel track alongside operational stabilization, not as an afterthought. And treat the first TSA extension request — if it comes — as a signal, not a routine administrative action. Most acquirers treat an extension request as paperwork when it is actually evidence that the cutover plan is already off track. In lower middle market operational due diligence, the question of how the business will stand up independent infrastructure post-close is as important as any other integration workstream — and it is almost never given adequate attention before close.
Key Framework: The TSA Cutover Protocol
A structured approach to managing TSA exits in lower middle market acquisitions, ensuring the buyer achieves operating independence within the agreed window.
Define the cutover plan before you sign the TSA — The TSA sets a deadline; the cutover plan is the project required to meet it. Both should exist simultaneously, not sequentially.
Assign a single owner — Cutover work requires explicit, protected bandwidth. Without a named owner, it competes with every operational priority and loses every time.
Build milestones into the hundred-day plan — IT independence, payroll migration, and ERP standup belong on the integration roadmap with hard dates, as active workstreams rather than future-state aspirations.
Treat the first extension request as a flag — An extension request means the plan is behind. The answer is a root-cause conversation, not an automatic approval and a return to other priorities.
The core principle — A TSA is a bridge with a demolition date. The acquirer's job is to build the other side before the bridge expires, not to move into the bridge and call it home.