The IT Leader's Guide to M&A Carve-Outs in Microsoft 365

A carve-out is not a migration. It is a separation — and the distinction matters more than it sounds. In a standard migration, both organisations typically cooperate, timelines are flexible, and the people doing the work have access to what they need. In a carve-out, the IT infrastructure you are separating from is controlled by an organisation with different interests, the timeline is set by deal lawyers not IT capacity, and your access to data, systems, and documentation is negotiated, not assumed.

For the IT team responsible for the carve-out, this means operating under constraints that do not apply to any other kind of migration. This guide is for that team.

What Makes Carve-Outs Different

Three constraints define carve-outs and shape every decision in the programme:

Political constraints on access. The parent organisation controls the infrastructure — the Microsoft 365 tenant, the Active Directory, the network, the device management platform. Depending on the deal structure and the relationship, they may provide varying degrees of cooperation. In hostile separations, they may provide the minimum required by the separation agreement and nothing more. Every access request is a negotiation, and delays in access translate directly to delays in the programme.

Fixed timelines. The "Day 1" date — the date on which the carved-out entity must operate independently — is typically set by the deal, not by IT readiness. If the legal and financial close happens on a particular date, IT must be ready by that date regardless of technical complexity. Late IT separation is not generally accepted as a reason to delay a commercial transaction.

Incomplete documentation. The parent organisation's IT team maintains documentation for the whole environment, not for the subset you are separating. What exists in the carve-out entity's portion of the tenant — which mailboxes, which SharePoint sites, which devices, which SaaS integrations — is frequently undocumented, inconsistent, or actively contested. You will discover dependencies you did not know existed during the separation process.

Phase 1: IT Due Diligence

Due diligence for a carve-out begins before the deal closes, ideally before it signs. The questions you need answered:

Identity. How are the entity's users managed — in the parent's Entra ID tenant, a sub-organisation, or a separate tenant already? Are devices enrolled in the parent's Intune? Are there shared service accounts that span the entity and the parent? What is the directory synchronisation model?

Data. Where does the entity's data live? If it is in SharePoint sites that also contain parent organisation data, how will the data be separated? Who owns the decision about what belongs to the entity versus the parent?

Integrations. What SaaS applications does the entity use, and are those applications licensed at the parent level or the entity level? ERP systems, HR platforms, finance tools, and business-critical applications often have contracts at the parent company level that need to be novated or re-contracted.

Licences. What Microsoft 365 licences does the entity use, and are they part of an Enterprise Agreement at the parent level? If so, you will need either a new agreement for the separated entity or a licence transfer mechanism, and the timing of this is critical.

Contracts and dependencies. Are there IT services provided by the parent that the entity depends on — managed services, network connectivity, security monitoring, helpdesk? These need to be replicated or replaced before Day 1.

The output of due diligence is a separation scope document: what is being separated, what is being replicated, what is being left behind, and what is being newly established. This document is the foundation of the programme plan.

Phase 2: Parallel Infrastructure

Once due diligence is complete, the new tenant and infrastructure must be built in parallel to the existing environment. The entity cannot go dark while new systems are being established.

The core tasks in this phase:

Tenant establishment. A new Microsoft 365 tenant is provisioned with the required domain names, the entity's licences, and baseline security configuration. This is done in advance of any user migration — the target environment is ready and tested before users move.

Identity architecture. If the entity is starting from scratch, a cloud-only Entra ID tenant is typically the right choice — no legacy on-premises identity debt. If there is existing on-premises infrastructure that is being separated, the synchronisation architecture needs to be designed and tested.

Security baseline. Conditional Access policies, Defender for Endpoint configuration, Purview sensitivity labels, and DLP policies are all applied to the new tenant before users migrate. Migrating users into an unsecured tenant and then attempting to apply security controls retrospectively creates a window of exposure and a significant rework burden.

Communication and collaboration infrastructure. Exchange Online domain routing, Teams meeting infrastructure, and SharePoint sites need to be established and tested. Coexistence with the parent tenant — so that users can still communicate during the migration period — requires explicit configuration.

Phase 3: Wave-Based Migration

Moving everyone at once is not feasible in a carve-out, for several reasons. Not all users have the same dependencies. Some business units are more complex than others. Risk needs to be distributed across waves, not concentrated in a single cutover event.

Wave sequencing should be based on three criteria:

Complexity. Users with simple setups — standard mailbox, OneDrive, no special integrations — migrate in early waves. Users with complex dependencies — shared mailboxes, Teams channel ownership, SaaS integrations — migrate in later waves with more preparation time.

Business criticality. Business-critical roles should not be in the first wave. Unexpected issues in wave one are normal. Critical users should move in wave two or three, when the migration process has been validated.

Geographic alignment. Where possible, users in the same geographic location should migrate in the same wave, to simplify helpdesk support and user communication.

For devices, the wave sequencing follows the same logic, but device migration has an additional consideration: physical access. In a carve-out, the device fleet is often distributed across multiple locations, some of which may require coordination with the parent organisation to access. A device migration tool that operates remotely — moving device enrolment from the parent Intune tenant to the new tenant without requiring physical access to the device — is materially important for distributed carve-outs.

Phase 4: Day 1 Readiness

The 12 hours before Day 1 cutover are not the time to discover problems. They are the time to execute a pre-validated plan.

Day 1 readiness means:

• All Day 1 users have been migrated to the new tenant
• Mail routing has been confirmed — email to entity domains is delivered to the new tenant
• All business-critical applications have been tested with entity user credentials in the new tenant
• The helpdesk team is briefed and on standby for the first business day
• The rollback procedure is documented and the authority to invoke it is clear
• The Day 1 communication to users has been reviewed, approved, and is ready to send

The Day 1 cutover window should be a DNS change and a licence handover, not a migration event. If migration work is still happening on Day 1, the programme has run behind plan.

Phase 5: Stabilisation and Decommission

The week after Day 1 is typically the most support-intensive period of the programme. Users discover dependencies that were not identified during planning. Applications that were expected to work do not. Mail flow issues appear in edge cases.

Stabilisation planning should include:

• Daily check-in calls with helpdesk leads for the first two weeks
• A known issues log updated in real time and accessible to support staff
• A fast-track escalation path for critical issues — standard support queues are not appropriate for carve-out stabilisation

Once stabilisation is complete, the decommission of the entity's presence in the parent tenant can begin. This includes removing accounts, revoking access, cleaning up shared resources, and — where the separation agreement allows — deleting data from the parent tenant that belongs exclusively to the entity.

A Real-World Example

A recent Opsora carve-out engagement involved a cybersecurity company being separated from its parent, spanning 3 countries, 145 employees, and 15 departments. The complexity was compounded by the parent's restricted cooperation stance — access to documentation and systems was provided on a request-by-request basis with delays measured in days.

The approach: establish the new tenant immediately after deal signing, build the security baseline independently of parent cooperation, and sequence migration waves by department starting with IT and operations. Device migration was handled using a remote migration approach that required no physical access and no wipe — critical for the distributed workforce. Day 1 was achieved on the deal's required date, with zero disruption to the entity's customer-facing operations.

The key enabler was not technical sophistication. It was the programme structure: a clear scope document, a wave plan that was stress-tested before execution, and a senior programme lead who had navigated restricted-access carve-outs before.

The Value of Senior Programme Leadership

The most common failure mode in carve-out programmes is not technical — it is organisational. The IT team is competent. The tools work. The failure is in programme management: scope creep from undiscovered dependencies, timeline slippage due to access negotiations, and miscommunication between the IT team, the legal team, and the business.

A programme lead who has done carve-outs before knows where these failures happen and designs the programme to pre-empt them. They know which access requests to make before the programme starts, which dependencies to verify during due diligence, and how to manage the relationship with a reluctant parent organisation. That experience is the difference between a carve-out that closes on time and one that becomes a multi-month post-deal drama.

Opsora provides senior programme leadership for M&A carve-outs and consolidations. See how we approach carve-out and tenant migration engagements.