Identity is the longest tail in any TSA.

Why Azure AD is the critical path.

In most carve-outs the Newco inherits a population of user accounts, groups, devices, conditional access policies, and application registrations that live in the seller's Microsoft Entra ID tenant, also known by its previous name Azure Active Directory. Every Microsoft 365 mailbox, every Teams workspace, every SharePoint site, every domain joined device, and every modern application that uses single sign on relies on that tenant for authentication. Until the Newco has its own tenant, the Newco is operating on the seller's identity stack.

The risk profile is high. The seller's security team retains administrative access to the tenant and therefore to the Newco's data inside it. Conditional access policies, multi factor settings, and audit logs are all controlled by the seller. The Newco's identity team cannot make independent decisions about its own access posture. From a compliance and audit perspective the Newco does not yet stand on its own.

For these reasons the Newco's own tenant is a Day One priority even when the cutover takes months. A new tenant is provisioned, named, licensed, and made ready to receive users well before the actual migration starts. The pattern overlaps with the broader carve-out Active Directory migration playbook.

The three migration patterns.

Three migration patterns dominate Azure AD separation. The first is a full cutover. The Newco provisions a new tenant, moves all user accounts, devices, and applications on a single weekend, and decommissions the bridge to the seller. Full cutover works for smaller Newcos with a unified application portfolio and a tolerance for a brief outage. It is rare above five hundred users.

The second pattern is a phased migration with B2B collaboration. The Newco tenant is built and populated with the Newco's primary identities. Access to the seller's applications continues through Entra ID B2B guest access for the duration of the TSA. As each application migrates to the Newco tenant the corresponding guest access is decommissioned. This is the most common pattern and handles populations from one thousand to twenty thousand users gracefully.

The third pattern is a tenant to tenant migration using Microsoft's cross tenant synchronization or a third-party migration tool. Users keep their original sign in experience while the underlying tenant changes. This is used in larger and more sensitive populations. The pattern carries the most cost but the least operational disruption. The choice is governed by population size, application portfolio, and the negotiated exit window in the TSA.

Application dependencies and SSO.

An Azure AD tenant is not merely a list of users. It is the identity provider for every application that uses SAML or OpenID Connect single sign on. A typical mid-market Newco has between forty and one hundred fifty applications registered against the seller's tenant. Each registration has to be re-created in the Newco tenant or the application has to be reconfigured to trust the new tenant.

The discovery work is non trivial. The seller's tenant administrators have a complete view but the Newco team rarely does. A pre-signing inventory of every application that authenticates against the tenant is the right first step. Each entry captures the application name, the protocol, the owner, the vendor contact, the licensing implications of switching tenants, and the planned cutover date. Without this inventory the cutover encounters surprise dependencies in week two and slips by months.

Migration of an SSO integration is rarely a thirty minute task. Most third-party SaaS vendors require a coordinated change with their support team to repoint the identity provider. Some larger vendors charge a fee for the change. A small number block the change until the existing contract is amended. The cutover schedule has to accommodate this. The pattern overlaps with the broader Okta identity separation playbook for federated environments.

Devices, Intune, and the endpoint problem.

Devices joined to the seller's Entra ID tenant are managed by the seller's Intune service. Moving a device to the Newco tenant typically requires the device to be unenrolled from the seller and re-enrolled into the Newco. For Windows endpoints this can be scripted with Autopilot reset patterns. For macOS endpoints it requires Apple Business Manager coordination. For mobile devices it requires user action and Mobile Application Management configuration on the Newco side.

The endpoint cutover is the most visible part of the migration for end users. A poorly run cutover loses encryption keys, breaks app installations, or leaves users without printer access. A well run cutover preserves user data through OneDrive sync, replays the application catalog on the new tenant, and provides a clear support path during the transition window.

The endpoint stream typically lags the identity cutover by six to twelve weeks. Users authenticate against the new tenant for cloud applications first, and devices follow once the change is operationally stable. The pattern overlaps with the broader carve-out endpoint management playbook.

Licensing, cost, and the TSA invoice.

During the TSA the seller invoices the Newco for the Newco's share of Entra ID, Microsoft 365, and Intune consumption. The methodology is usually a pass-through of Microsoft's per user licensing cost with a small administrative mark-up. The invoice should be itemized by SKU and headcount. Buyers that do not validate the invoice tend to pay for licenses that no longer correspond to active users.

Procurement of the Newco's own Microsoft licensing happens early. Direct purchase, a Cloud Solution Provider partner, or an Enterprise Agreement transfer each carry different lead times and price points. The decision has to be made in the first sixty days post-close. By the time the migration is ready to start, the new tenant must already be licensed at full headcount.

When the cutover completes the seller's invoice should drop to a residual amount for any users still on bridge access, and then zero. A buyer that continues to see a flat invoice after cutover is paying for licenses that are no longer in use. The pattern overlaps with the broader TSA invoice validation process playbook.

Closing the migration and the exit.

A clean Azure AD exit closes three records. The seller's tenant retains no Newco user objects, no Newco service principals, and no Newco devices. The Newco tenant holds the complete identity record, the audit history is exported, and any guest collaboration with the seller is reviewed and approved on its own merits. The seller's administrators no longer have administrative rights into Newco resources.

The exit is documented in a final cutover report. The report lists every application that was migrated, every device that was re-enrolled, every legacy account that was disabled, and any open items that survived to the post-close services agreement. The seller and the buyer both sign the report. The report supports the broader TSA exit certificate and feeds into the audit trail the Newco will rely on at its first independent SOC examination.

Specialist support across the identity workstream is part of the TSA Exit Acceleration service when the milestone is at risk. The work coordinates with the buyer's IT lead, the seller's identity team, and the Microsoft partner ecosystem.

More on vendor and platform separation.