The M&A Playbook Is Decided Before the Deal

Eight times now, some version of the same call has come: a business is being bought, sold, or spun out, and IT owns the technical side of making two companies one — or one company two. Five of those I ran end to end, from the first diligence question to the last decommissioned server. Together they moved roughly a billion dollars in deal value. And the single most important thing I have learned across all of them is this: by the time the call comes, the part that decides whether it goes well is already over.

Not the execution. The execution is hard, but it is solvable, and I have written about that elsewhere — the 60-day cutover of a cross-border carve-out is the operational story of what the cutover itself demands, dependency map and all. This is the other half. The half nobody schedules. The decisions that determine whether your 60 days run quiet or run on fire are made months earlier, often before there is even a deal to point at — and usually by people who do not think they are making IT decisions at all.

The deal does not start when the deal starts

Here is the trap, and almost every IT organization walks into it the first time.

The deal gets announced, and by day ten someone remembers that the two companies share an identity tenant, a SaaS estate, a network, and a fleet of managed devices — and that none of it separates by signing a contract. IT gets handed a date and told to make it work. From that moment, every decision IT makes is a reaction to a structure that was frozen before anyone asked IT a question.

That is the real failure mode, and it sits upstream of anything you will see at execution time. The hard fork-in-the-road questions get answered late, under deadline, by whoever happens to be in the room — instead of early, deliberately, by the people who will have to live with them. You cannot schedule your way out of a structure that was built to never come apart. The answer had to be decided long before the date existed, and either it was or it wasn’t.

Architect for separation before you have something to separate

The most useful thing I ever did for the deals I had not heard of yet, I did between deals.

After the first major separation, I stopped treating each transaction as a project and started treating modularity as a property of the environment. The goal was simple to state and hard to live by: build the IT estate so that any piece of it could be lifted out — or dropped in — without unstitching the whole thing. My manager at the time described it as modularizing the footprint for easy tuck-ins and spin-outs, and that phrase stuck because it named a decision that lives nowhere on a project plan. It is an architectural bias you carry into a thousand small choices when there is no deal in sight.

This is what I have come to call M&A readiness debt — the gap between the deal arriving and the answers being pre-decided. An estate built to never come apart carries that debt quietly, and it all comes due at once on the day someone hands you a date.

So you pay it down before it is owed. It changes how you design identity, so an acquired company’s directory can be absorbed or a divested unit’s can be severed without tenant-wide surgery — not the shared tenant where cutting one business unit means touching everyone. It changes how you license SaaS, so entitlements map to entities you can actually pull apart instead of the single enterprise agreement nobody can split at signing. It changes how you segment the network, so a clean cut is a configuration, not a reconstruction. None of these are deal decisions. They are everyday architecture decisions made with the next deal already assumed — because in an acquisitive company there is always a next deal, and the only question is whether you designed for it or got surprised by it again.

This is the position a generalist cannot take: M&A readiness is not an M&A activity. It is an architecture standard you hold continuously, so that when the deal arrives the separation is mostly a matter of reading answers you already wrote down — not inventing them against a clock. The work that makes the next deal boring is done in the quiet when there is no deal at all.

Pre-decide the questions that always cost two weeks

Every separation surfaces the same fork-in-the-road questions. The first time, each one ambushes you and costs days while someone tracks down an owner and a ruling. So after that first separation I wrote them down — and the record that came out of it is the Infrastructure Autonomy Playbook I detail in the cutover piece. What matters here is its shape, because the shape is the part a reader can copy on Monday.

It is not a runbook of steps. It is a record of pre-made decisions, and every entry is three columns: the question, the default answer, and the single owner allowed to override it. What is our default for splitting a shared SaaS contract before the vendor’s process becomes the bottleneck? Which jurisdictions will not let employee data cross a border without a legal sign-off, and what is the lead time on getting it? Who owns the call when the receiving organization — which often does not yet have its own IT team stood up — wants a platform we would not have chosen? What is the standard for a post-separation support window so we are not negotiating an SLA with ourselves at midnight on day 58?

Each of those is a decision that costs roughly two weeks if you make it under deadline and roughly ten minutes if you made it in advance. Multiply that across a thirty-country carve-out and the pattern becomes the whole game. The LastPass carve-out is the proof: a full separation across thirty-plus countries that went smoothly because most of the hard answers were not invented during those weeks — they were waiting in the record from the carve-outs before it. The Bold360 divestiture to Genesys ran on the same pre-decided spine — a full infrastructure, identity, and telecom separation that kept service uninterrupted for more than a thousand customers and landed in under sixty days — because the team was not inventing the hard answers during those sixty days. They were reading them out of the record.

The decisions IT does not get to make — but has to shape

There is a harder layer underneath the technical pre-decisions, and it is where M&A IT graduates from project management into something closer to a seat at the table.

Some of the most consequential separation decisions are not IT’s to make. Which entity keeps which SaaS contract has tax and legal weight. What data can move across which border is a compliance ruling, not a migration task. When the receiving organization stands up its own IT, who decides the platform is a governance question. IT does not own those calls — but IT is the only function in the building that can see, early and concretely, which of them will detonate the timeline if they are left unanswered.

So the move is not to make those decisions. It is to force them onto the table before they are urgent. The first time, you discover the cross-border data ruling late and lose a week you did not have — because employee data in certain jurisdictions cannot cross a border without an explicit legal sign-off, and that sign-off has a lead time that does not care about your Day 1. By the third deal, you have learned to walk into the room in the first week and say: here are the decisions that are not mine, here is the one that breaks the timeline on day 50 if we defer it, and here is who needs to own it now. That is the difference between an IT leader who executes a separation and one who is trusted to shape the deal — and it is exactly the kind of executive readiness that shows up before the title does, in the gap between the decision that needs an owner and the org chart that has not caught up.

This is also where the experience compounds, and why it carries weight in the room. Plenty of IT leaders have run organizations and shipped roadmaps. Far fewer have stood inside the carve-out where the legal clock, the vendor’s process, and the receiving company’s half-built IT all collide at once — eight times — and come out the other side with a written record of what to decide before the next one. You can hear it in thirty seconds of conversation: the leader who has done it talks about which decisions to pre-make and who owns them; the one who has not talks about tools and timelines. One is teaching you where the estate has to bend before the deal arrives. The other has not had to find out yet.

What this actually asks of you

If your company is acquisitive — and in 2026, with private-equity timelines that do not tolerate phased migrations, more of them are — the lesson compresses to one uncomfortable instruction: do the deciding before the deal. Hold the modular standard when there is nothing to separate. Keep the fork-in-the-road answers written down and updated after every transaction. Map the decisions that are not yours, and get into the room early enough to force them while there is still slack.

And if you are already mid-deal with no record to lean on, the instruction does not change as much as it looks. Start the record anyway — capture each decision the moment it is forced, the answer you land on, and who owned it. The artifact’s first job was never to save this deal. It is to make the next cut boring.

The first separation I ran, we figured out the shape of the problem while the clock was already running. Every one after, we knew the shape before anyone handed us a date — because the answers were decided before the deal was. That is the whole craft, and it is invisible from the outside. By the time the deal closes, the playbook is either written or it isn’t. The deadline just tells you which.

Common questions

When is the M&A IT playbook actually decided?
Before the deal exists. By the time the call comes — “we’re separating this business, Day 1 is in 60 days” — the part that determines whether it goes well is already over. The hard fork-in-the-road questions either got pre-decided deliberately, by the people who would have to live with them, or they get answered late under deadline by whoever happens to be in the room. You cannot schedule your way out of an estate that was built to never come apart; that answer had to be made long before the date existed.

Why does M&A IT separation fail before the deal even closes?
Because the real failure mode is upstream of anything technical: deciding the separation answers late instead of pre-deciding them. When a deal is announced, IT is handed a date and forced to react to a structure that was frozen before anyone asked IT a question. Christian Merkel calls the underlying gap M&A readiness debt — the distance between the deal arriving and the answers being pre-decided. An estate built to never come apart carries that debt quietly, and it all comes due at once on the day someone hands you a deadline.

How do you prepare IT for an acquisition or divestiture before a deal exists?
Hold a modular architecture standard continuously, so any piece of the estate can be lifted out or dropped in without unstitching the whole thing — design identity so a directory can be absorbed or severed without tenant-wide surgery, license SaaS so entitlements map to entities you can actually pull apart rather than one enterprise agreement nobody can split, and segment the network so a clean cut is a configuration rather than a reconstruction. Keep the fork-in-the-road answers written down and updated after every transaction, and map the decisions that are not IT’s to make — plus their lead times — so you can force them onto the table early. In an acquisitive company there is always a next deal; the only question is whether you designed for it.

Why is hands-on M&A IT experience rare and valuable?
Plenty of IT leaders have run organizations and shipped roadmaps. Far fewer have stood inside a carve-out where the legal clock, the vendor’s process, and the receiving company’s half-built IT collide at once — Christian Merkel has done it across eight deal events, five run end to end, totaling roughly a billion dollars in deal value — and come out with a written record of what to decide before the next one. You can hear the difference in thirty seconds: the leader who has done it talks about which decisions to pre-make and who owns them; the one who has not talks about tools and timelines.