A carve-out is the sale of part of a company. The business being sold rarely has technology of its own. It runs on the parent's network, directory, email platform, finance system and contracts, alongside people who are staying behind. Separating it means drawing a line through all of that, and keeping both sides running while you do.
Transition services bridge the gap. The seller keeps providing some services after closing, for a fee and for a limited time, while the buyer builds or moves to its own. Getting the scope wrong is expensive on both sides: a term that is too short ends in an extension on the seller's terms, vague service descriptions end in disputes, data goes where it should not, and access that was meant to be temporary survives for years.
When it happens
Separation work starts before signing, because the perimeter and the outline of the transition services are part of what is being negotiated. Detailed planning runs between signing and closing. Transition services start at closing and run until each one is exited, which typically takes months.
This playbook applies whichever side you are on. As the seller, you protect the business you keep and avoid costs left stranded when the services end. As the buyer, you make sure you receive a business that can run, and a realistic path off the seller's systems.
Who is involved
- The seller's separation lead and IT team, who know the shared estate.
- The buyer's integration lead, who owns the receiving side.
- Service managers on both sides, one per transition service.
- Legal counsel, for the transition services agreement, data transfer, privacy, licences and intellectual property.
- Finance, for service pricing, stranded costs and the separation budget.
- Privacy officers on both sides, for personal data that moves or is shared.
- HR, for staff who transfer and the systems that follow them.
- Business owners, who decide what the separated business needs.
The steps
1. Define the perimeter
List what goes with the business and what stays, across five categories. Anything shared needs a decision, and the shared items are where most of the work is.
- People: who transfers, and the accounts, devices and access that go with them
- Applications: dedicated, shared, or used by both sides on one instance
- Data: what belongs to the business, what is mixed, and what must stay with the seller
- Infrastructure: sites, network segments, servers, cloud subscriptions, end-user devices
- Contracts: dedicated, shared, assignable, or needing a new contract
2. Choose a separation approach for each system
There are three broad approaches, and most carve-outs use all three for different systems.
- Clone and go: copy the system and its data for the buyer, then remove what does not belong. Fast, but the licence may not allow a copy, and removing the other business's data is hard to do well.
- Extract: move the business's data into a system the buyer already runs. Clean for the buyer, but needs data mapping and a receiving platform ready in time.
- Build new: stand up a fresh environment and migrate into it. The slowest and most expensive, but it carries no inherited configuration or data.
Weigh speed, cost, data risk, licence terms and the buyer's intended end state.
3. Scope the transition services
Each service needs its own schedule. "IT services as currently provided" is not a scope; it invites disputes. Agree the commercial and legal terms with counsel and finance.
- A description of the service, the systems and the users covered
- Service levels, usually anchored to how the service ran before closing
- Duration, extension terms and termination notice
- Cost basis and charging
- Exit criteria that define when the service is finished
- Dependencies between services
- Security and data handling obligations on both parties
- Reverse services, where the buyer provides something back to the seller
4. Separate the data, legally and technically
Data separation is a legal question before it is a technical one. Privacy law, such as GDPR or PIPEDA, may govern what personal data can be transferred, on what basis, and what people must be told. Agree the approach with counsel and the privacy officers on both sides.
- Customer, employee, supplier and financial data mapped to its owner after closing
- Mixed databases identified, with a method for splitting them
- The legal basis and any notices for personal data that moves
- Copies the seller must keep for its own obligations, such as tax records
- Confirmation that data was deleted where it should not remain
5. Untangle the entanglements
Some shared items are easy to miss because nobody thinks of them as systems. Build an entanglement register early and give each item an owner.
- Licences under enterprise agreements that cannot be split or assigned
- Brand domains registered in the parent's account, and email on a shared domain
- Certificates, including wildcard certificates used by both sides
- Accounts in the parent's directory, and single sign-on to shared applications
- Shared address space, firewalls and remote access
- Phone numbers, supplier portals, code-signing keys and shared mailboxes
6. Secure the transition period
During the transition period two organisations share infrastructure, and often administrators. Set access boundaries so each side sees only what it should, and write the obligations into the agreement.
- Access for the separated business limited to its own systems and data
- Seller administrators' access to the buyer's data logged and reviewed
- Incident notification between the parties, with contacts and time limits
- Joint change control for shared systems
- Leavers on either side removed from both
7. Plan the exit from day one
The exit plan starts at closing, not when the term is ending. Long-lead items such as circuits, licences, hardware and new contracts often take most of the term.
- An exit plan for each service: target date, approach, dependencies, test and cut-over
- Long-lead items ordered early
- Monthly review of exit progress against each service's term
- Extension decisions taken early enough to negotiate
- At exit: data returned or deleted, access removed, certificates revoked, the service formally closed
Common traps
- A perimeter drawn on the organisation chart, without mapping systems and data
- Service schedules that say "as currently provided"
- No exit criteria, so nobody can agree when a service has ended
- A term set by the deal team without asking IT how long the exit will take
- Licences assumed to transfer with the business
- A brand domain in the parent's registrar account
- A shared wildcard certificate that cannot be revoked without breaking both sides
- Seller administrators who keep access to the buyer's data after exit
- Cloned systems that still hold the other business's data
- Stranded costs at the seller, found after the services end
- Exit work started late
What you hand over
- The perimeter register: people, applications, data, infrastructure and contracts
- The separation approach for each system
- Transition and reverse transition service schedules
- A data separation plan, agreed with counsel
- The entanglement register, with owners
- Security arrangements for the transition period
- The exit plan, with dates and status
- A close-out record for each service: exited, data handled, access removed
Where MNA Tools helps
- DeepReview maps the domains, brands and hosts linked to the business from public information, including ones nobody listed, which helps when you build the entanglement register.
- SubnetSleuth inventories the separated business's network read-only, inside ranges agreed with both parties and with the parent's ranges excluded, so the receiving team starts with documentation.
- HouseGRC can hold each separated business as its own organisation, with its risks, supplier contracts and reporting kept apart from the parent's.
A general guide to the technology side of a deal, not legal, tax or financial advice. Adapt it to the deal in front of you, and take advice where the stakes call for it.