Nobody tells you how fast an M&A separation actually has to happen.
You find out when someone calls you and says: "We're divesting this business unit. Day 1 is in 60 days. IT owns the separation."
60 days. 30+ countries. Two businesses that had shared infrastructure, shared identity, shared SaaS licenses — now needed to be completely independent of each other. And both had to keep running on Day 1 of separation as if nothing happened.
What a separation actually involves
The scope of an IT carve-out is harder to communicate to non-IT stakeholders than almost any project in enterprise technology. The analogy I use: imagine two companies that have lived in the same house for years, sharing a kitchen, a fridge, the Wi-Fi password, and a mail slot. Now legally separate them — same address, overnight.
In IT terms, this means:
Identity infrastructure — Azure Active Directory tenant splits, service account separation, MFA policy divergence, conditional access reconfiguration. Network segmentation — VLANs, firewall rules, SD-WAN traffic routing — cleanly divided so traffic between the two companies post-separation can't traverse shared infrastructure. SaaS licensing splits — Salesforce, ServiceNow, Microsoft 365, every cloud tool the company used needed to be cleanly assigned to one entity or the other, with contracts renegotiated or split accordingly. Endpoint management — every managed device needed to be inventoried, assigned, and either retained or transferred. Data classification and migration — shared file systems, email archives, SharePoint environments. Vendor contract carve-outs — reseller agreements, support SLAs, partner tier assignments. Compliance handoffs — data residency rules differ by jurisdiction. In some countries, you can't move certain data across the border without explicit legal sign-off. You don't get to discover this on Day 55.
Most of that list can't run sequentially. It runs in parallel — which means teams that don't usually work together have to be on the same timeline, dependent on each other's outputs, across multiple time zones.
The dependency map before the workplan
The number one failure mode in M&A IT is not technical. It's sequencing. Someone starts the endpoint migration before the identity layer is ready. Network segmentation kicks off before SaaS access is fully mapped. One dependency wrong and you're firefighting instead of executing.
Before we wrote a single workplan, we spent two days drawing the dependency map. Every workstream. Every handoff point. Every external dependency — vendors, legal, the business unit IT team on the receiving end.
That session was uncomfortable. It forced conversations about sequencing that people wanted to defer. Who owned the identity split? What happened if the SaaS vendor couldn't execute the license split in time? What was the fallback if a jurisdiction's legal review took longer than three weeks?
After that session, we had a timeline. Before it, we had ambition. The difference between those two things is what determines whether a separation lands clean or becomes a crisis management exercise.
The technical work in an M&A separation is complex but solvable. The thing that slows every separation down is decision latency. Someone on the business side needs to approve the vendor split. Legal needs to sign off on the data migration. The receiving organization has opinions about what platform they want to land on. Every decision that should take two hours takes two weeks because no one owns it.
The 60% that isn't infrastructure
The first few times you execute an IT separation, you think of it as an infrastructure project. It's 40% infrastructure. The other 60% is stakeholder management.
Who owns decisions on the receiving organization's side? In most separations, the business unit being carved out doesn't have a full IT team of its own yet — they're being built simultaneously with the separation. That means someone in the parent company's IT organization is making decisions on behalf of a business that doesn't fully exist yet.
The vendor negotiations are the other place this shows up. Enterprise software vendors are not incentivized to move fast on contract splits. License portioning, mid-term amendments, new tenant provisioning — every vendor has a process, and their process wasn't designed for a 60-day deadline. You need someone who can escalate to the right level at each vendor fast enough to keep the timeline alive.
And then there's the compliance layer. Data residency, cross-border data transfer agreements, GDPR implications for employee data in the move — these aren't IT questions. They're legal questions that IT needs to be ready to brief on. The IT leaders who've done multiple separations understand this. The ones doing their first often discover it too late.
What the Infrastructure Autonomy Playbook actually is
After our first major separation, I built what we called an Infrastructure Autonomy Playbook. Not a post-mortem. A living operational document.
It contains: pre-decided answers to the questions that slow down every separation. Pre-negotiated SLA agreements for post-separation support windows. Pre-mapped dependency documentation — the dependency map we built before every separation, formalized so the next one didn't start at zero. Vendor escalation paths for the most common enterprise software splits. Jurisdiction-by-jurisdiction data residency requirements for the countries we operated in.
We used it on every subsequent carve-out. Each one got faster. Not because the work got easier — it never does — but because the startup cost dropped. The first separation took us weeks just to understand what we were dealing with. Subsequent ones: we knew the shape of the problem before anyone handed us a timeline.
That compounding value — a framework that gets better with every use — is exactly the kind of organizational capability most IT functions don't deliberately build. They solve the immediate problem. They don't document the solution in a way that transfers.
Why M&A IT experience is increasingly rare
M&A activity is accelerating in 2026. Private equity timelines don't accommodate phased migrations or long vendor negotiations. Most IT leaders in the market have operational experience — they've run IT organizations, managed teams, executed technology roadmaps. Far fewer have done multiple separations and integrations at the execution level.
The difference shows immediately in how an IT leader talks about M&A: those who've done it at speed talk about dependencies and decision owners. Those who haven't tend to talk about tools and timelines. One is the blueprint. The other is the list of things you need to schedule.
If your organization is heading into a deal — start the IT workstream earlier than legal tells you to. By the time legal says go, you've already lost two weeks. The IT leaders who get called in early aren't the ones who asked to be. They're the ones who already showed up prepared.