Migrating to GCC High

Some customers arrive at GCC High through migration rather than greenfield: a DIB company moving off Microsoft 365 Commercial to meet CMMC contract obligations, a sibling GCC High tenant being consolidated after an acquisition, or an OpCo being split out of a shared-services tenant under Option B or C of the Shared Services chapter. The destination architecture (identity, devices, data, monitoring) is covered pillar-by-pillar in the rest of this book. This chapter covers only the migration-specific gotchas.

Throughout, source tenant refers to the tenant being vacated (Commercial or a sibling GCC High), and target tenant refers to the hardened GCC High tenant users are moving into.

Glossary

• CTAS: Cross-Tenant Access Settings. Per-partner Entra configuration that controls inbound and outbound B2B, trust of MFA/compliant-device claims, and Teams shared-channel eligibility. Must be rebuilt in the target tenant, and partners must update their CTAS to point at the new tenant.
• Cross-Cloud Meeting Join: Teams capability that lets a user in one cloud (Commercial, GCC High) authenticate into a meeting hosted in another cloud. Enables Conditional Access, lobby bypass, and compliance claims. Does not enable file sharing, group chat, or persistent meeting-chat access.
• B2B Guest: a user object in the target tenant representing an external identity. Highest-fidelity external collaboration; requires coordinated CTAS on both sides plus explicit Team/group membership.
• Fly: AvePoint Fly SaaS. A FedRAMP-authorized migration tool for mail, SharePoint, OneDrive, and Teams chat across tenant and cloud boundaries. Referenced as the example because it is the tool most commonly used for DIB GCC High migrations; other FedRAMP-authorized tools can substitute.
• MX flip: the DNS change that moves inbound mail routing from one mail handler to another. The migration sequence is designed so the MX flip is the last step for mail, not the first.

Scope decisions up front

Before any configuration work, name the following:

• What is moving. User accounts, mailboxes, SharePoint and OneDrive content, Teams channels and chat history, sensitivity labels, retention policies, distribution groups, dynamic groups, registered apps, service principals, service accounts, SSO-federated SaaS, VPN configuration, device enrollment, Autopilot profiles. Name the workloads explicitly; assume nothing moves by default.
• What stays. Archived content that can live in a read-only vault, apps that only authenticate to Commercial identity and will be retired, service accounts that have no equivalent role in the destination, Duo or any third-party MFA service that is not supported in GCC High.
• Who owns each workload. Source-side owner, target-side owner, migration-tool operator. Every workload needs all three.
• Domain strategy. Whether the primary SMTP domain moves with the users (and when), or whether users receive a temporary .onmicrosoft.us UPN and get their business domain back after cutover. This decision drives the sequencing more than any other.

Identity gotchas

• MFA re-registration. Users do not carry their MFA registrations across the cloud boundary. Everyone re-registers in the target tenant. If the source tenant used Duo, MFA Authenticator, or other third-party MFA, the target registration path is Microsoft Authenticator plus phishing-resistant methods (FIDO2, passkey, WHfB) per the hardened baseline. Communicate the app download ahead of time.
• Cross-cloud B2B is off by default in GCC High. The Commercial cloud allows B2B invitations between any two tenants with no per-partner configuration. GCC High blocks cross-cloud B2B unless the target tenant has Cross-Cloud Settings enabled and each partner tenant is individually allowed. Until those are configured, invitations fail silently from the user's perspective.
• Cross-Tenant Access Settings must be migrated and mirrored. Every partner relationship in the source tenant has a CTAS record defining what that partner can and cannot do. These records do not migrate automatically. Rebuild them in the target tenant and coordinate with each partner to rebuild their side pointing at the new tenant. Existing B2B guest users in the source tenant need to be re-invited into the target tenant; the source-tenant guest object does not move.
• Conditional Access reaches a meeting attendee only if the attendee authenticates. Anonymous join is never evaluated; turn it off for CUI meetings. Teams external access and cross-cloud meeting connections admit attendees as authenticated participants, so your Conditional Access applies to them. A policy that requires MFA blocks them with AADSTS90072 until you trust the partner tenant's MFA in cross-tenant access settings, Microsoft's recommended fix. Authentication is not authorization: team membership and file collaboration still need a B2B guest. See cross-cloud meetings and inbound trust settings.
• Entra Connect sync switchover is a short, coordinated window. Stop sync to the source tenant. Start sync to the target tenant with password hash sync, password writeback, and Entra Hybrid Join configured for the target. During the window, on-premises changes stop flowing to the source but have not yet flowed to the target. Plan the window for a quiet period (Friday morning is common) and minimize its duration. A pre-staged credential-clearing script run via Intune on the target-joined clients smooths the client-side transition.
• Licensing. Use group-based licensing in the target tenant. Two Office variants behave differently: Volume License (VL) Office is per-device and persists through the migration; Microsoft 365 Apps is per-user and requires sign-out and sign-in after the user is in the target tenant. Inventory both before cutover.

External collaboration tiers

Decide per-partner which tier fits. GCC High's three external-collaboration tiers trade fidelity against configuration effort:

Tier	Authentication	Conditional Access	File sharing	Persistent chat	Configuration
Anonymous meeting join	None	No: the anonymous identity is never evaluated	Not a file-collaboration mechanism	Meeting-policy dependent	Explicit anonymous-join policy
Teams External Access	Authenticated federation	Yes, with inbound MFA trust for the partner tenant	No team/site membership	Supported chat depends on the cloud relationship	External-access and partner policies
Cross-Cloud Meeting Join	Authenticated cross-cloud participant	Yes, with inbound MFA trust for the partner tenant	No team/site membership	Meeting functionality is cloud-dependent	Coordinated cross-cloud connection
B2B Guest	Full user object	Yes	Yes	Yes	Coordinated CTAS on both sides, Team membership

For CUI meetings the floor is an authenticated tier (Teams External Access or a Cross-Cloud Meeting Join) with anonymous join turned off in the meeting policy and inbound MFA trust set for the partner tenant. Sharing a CUI file with the partner needs the B2B Guest tier; a meeting connection authenticates a person, it does not authorize access to a site.

Data gotchas

• Teams chat pre-staging is imperfect. Tools like AvePoint Fly can migrate chat history, but reactions do not transfer, and chats with external (non-tenant) users are not migrated. Set the expectation with users that historical reactions and some external chats will be lost. Pre-stage before cutover so users see their migrated history on first sign-in rather than an empty client.
• Provision the target mailbox first and stamp the source LegacyExchangeDN on it. Create the target user, license it so the mailbox exists, then copy source content into it. Add the source mailbox's LegacyExchangeDN (and every existing x500: proxy) to the target object as an x500: proxy address; replies to migrated mail and Outlook's autocomplete cache resolve the sender by that value, and without it the reply fails with a 5.1.1 NDR. Microsoft's cross-tenant mailbox migration and its migration orchestrator stamp this for you; a third-party tool may or may not, so pilot a reply to a migrated message before cutover.
• Preserve the primary SMTP address. Users keep their existing address as the primary SMTP in the target tenant; the target-tenant default domain becomes an alias. If the source-tenant domain is being retired, this requires transferring the domain's verification to the target tenant as part of the migration.
• Outlook client sometimes needs account removal and re-addition. Test this on a pilot before cutover. The modern Outlook profile can usually re-authenticate silently against the new tenant, but older profiles or specific version combinations require a manual profile rebuild. Document the user-facing steps either way.
• Free/busy is an Exchange organization relationship, not a Teams setting. A Cross-Cloud Meeting Join carries no calendar data. GCC High to Commercial and GCC High to GCC relationships are supported in both directions; DoD to any other cloud is not. Create one on each side with New-OrganizationRelationship: on the GCC High side -TargetApplicationUri outlook.com and -TargetAutodiscoverEpr https://autodiscover-s.outlook.com/autodiscover/autodiscover.svc/WSSecurity; on the Commercial side -TargetApplicationUri office365.us and the matching autodiscover-s.office365.us endpoint. Microsoft is moving free/busy sharing to the Microsoft 365 cross-tenant access policy as EWS retires; build new relationships that way once the rollout reaches both tenants.
• Sensitivity labels and encryption require an explicit migration plan. Label policies and IDs belong to the source tenant, but file label metadata and rights-management protection can persist with a copied file. Do not assume migration strips or decrypts them. Map the target taxonomy, test protected-file access and the tool's relabeling support, and preserve source keys and access until authorized reprotection and validation are complete (label persistence, encryption behavior).
• Assess the migration service and execution environment. For a cloud service that handles CUI, verify the exact offering's FedRAMP authorization or DoD equivalency and DFARS support. A self-hosted migration utility is evaluated within the organization's assessed environment; the software itself does not need a SaaS authorization. Document operator access, temporary copies, logs, and cleanup.

Device and app gotchas

• New Outlook is not generally available in GCC High; plan on classic Outlook or OWA at cutover. New Outlook for Windows in GCC High and DoD is in Public Preview (roadmap item 564913): off by default, enabled per device via a registry value, with the classic-to-new toggle rolling out to classic Outlook from roughly August 2026. Users arriving from a Commercial tenant may already live in new Outlook and must move to classic Outlook or OWA until the GCC High rollout completes; fold that into the cutover communication, since to the user it reads as losing an app. (Control installing and using new Outlook)
• Outlook, Teams, and mobile apps: sign out, sign back in. This is usually sufficient; reinstall is rarely required. Test on a pilot device before rolling communication. Mobile apps (iOS Outlook, Android Teams) may prompt for re-registration with a work profile; have the Intune MAM or MDM policy ready in the target tenant before users sign in.
• App inventory is the overlooked workstream. Inventory every app that authenticates against the source tenant. The usual suspects are obvious: Office, Teams, OneDrive sync client. The commonly missed one is the VPN client, which often carries SSO endpoints pinned to the source tenant's *.microsoftonline.com identity URLs. When source tenant federation dies, the VPN breaks. Inventory VPN, any other SAML-federated SaaS, and all certificate-trusted SSO integrations ahead of cutover.
• Registered apps and service principals in the source tenant. Every app registration in the source tenant has client secrets, certificates, and permissions that die with the source tenant. Inventory them, register equivalents in the target tenant, and update the consuming systems. If apps have been granted broad Graph permissions, audit what they have been reading before decommissioning.
• Service accounts. Inventory, determine whether the equivalent role exists in the target tenant, and create or retire accordingly. Service accounts are a common source of "the cutover was a week ago and something broke" incidents a month later.
• Entra Hybrid Join, Intune enrollment, and WHfB do not complete on Day 1. These require round-trips, reboots, and in the case of WHfB a user-driven provisioning event. Full device compliance is a two-to-four-week process for a typical fleet. Plan Conditional Access enforcement accordingly (see below).

Conditional Access strengthening timeline

Do not enforce device compliance at cutover. A device cannot be compliant until it is Entra joined (hybrid or direct) and Intune enrolled and the compliance policies have evaluated it; for a typical fleet that takes two to four weeks (see Device and app gotchas above). Windows Hello for Business is not a compliance input; it is the prerequisite for the phishing-resistant authentication strength, so that policy is gated on registration, not on compliance. Register users for phishing-resistant methods before cutover and test the bootstrap and recovery paths (Chapter 9) before enforcing the strength. Gate each policy on a measured state, not a calendar date:

• Cutover. Enforce the phishing-resistant strength for the group that completed registration in the target tenant; leave the rest on the interim MFA policy and move them into the group as they register. Device compliance CA in report-only.
• Join gate (typically week 2). Every fleet device shows Join type Microsoft Entra hybrid joined or Microsoft Entra joined and MDM Microsoft Intune in Entra ID > Devices > All devices (filter on both; export with Download devices and diff against the fleet inventory). Devices missing from the filtered list are the work queue.
• Compliance gate (typically week 4). Intune > Devices > Compliance reports Compliant for the wave, the report-only CA policy's sign-in log Insights show no users who would be blocked, then switch the policy to On for that wave.

Report-only evaluates a policy without enforcing it; it does not inherit source-tenant protection. Bound the transition window and test the controls that protect CUI during it.

High-level migration plan

The following phase structure generalizes cleanly across most DIB GCC High migrations. Adjust phase length to the user count and workload mix; the ordering is the invariant.

1. Prepare users. Communications, training, authenticator app installation, expectation-setting on what changes and when.
2. Harden the target tenant. The target must be CMMC-ready before any user or content arrives. Identity, Conditional Access, Intune baseline, OIB import, Purview label taxonomy, DLP, Sentinel: all configured per the rest of this book before step 3 switches the sync.
3. Switch Entra Connect sync. Stop sync to the source tenant, start sync to the target. Configure password hash sync, password writeback, and Hybrid Join.
4. Pre-stage collaboration content. Teams chat history migrated via FedRAMP-authorized tool. Confirm tenant readiness on the target side (Teams, SharePoint, meeting policies).
5. Transfer the primary domain. Remove the domain from the source tenant, verify it in the target tenant, let Entra Connect convert user UPNs to the target-domain. Mail continues to flow through on-premises Exchange or the source cloud mail stack: the MX is not yet flipped.
6. User-facing cutover. Users sign out of Outlook, Teams, and mobile apps, then sign back in authenticating against the target tenant.
7. Device configuration. GPO for Entra Hybrid Join, Intune for WHfB provisioning, Office apps deployment, Intune Compliance reporting. Pilot first, then fleet rollout.
8. Mailbox migration. Incremental, user-by-user or batch-by-batch. MX record stays on the source mail handler until the last mailbox cuts over, then flips to the target tenant's mail flow.
9. Address remaining source-tenant usage. Registered apps, service principals, service accounts, SSO-federated SaaS, VPN clients, any residual workload still authenticating against the source. Nothing functional should remain in the source.
10. Decommission the source. For Commercial: kill federated auth (Duo, ADFS) so no one can sign back in to the old tenant. For on-premises Exchange: change the source-of-authority to cloud or use Exchange attribute tools, then decommission the server. For GCC-to-GCC: archive or delete the source tenant per corporate retention policy.

Risks to call out during planning

• The commercial tenant cannot be left running "just in case." As long as the source tenant is active, there is risk that a user, app, or service account authenticates against it, creating a split-brain identity state. Decommission decisively, on a date, with communication.
• Third-party MFA services are usually not supported in GCC High. Duo is the most common example. Plan the MFA transition well before cutover so users are not caught between two tenants with no working authentication.
• Migration tools see CUI. The tool's FedRAMP posture, its operator credentials, its logging retention, and its incident-response process all become part of the CMMC narrative for the migration window. Document this in the SSP.
• User communication is half the project. Every gotcha in this chapter eventually surfaces at a user's desk. Pre-cutover communications, a help desk runbook, and a clearly-owned escalation path are the difference between a smooth migration and a tenant full of locked-out users.

Related chapters

• Shared Services and Conglomerate Tenants: migration is the mechanism for moving between Option A, B, and C architectures
• Phase 2: Identity Architecture: the target-tenant identity design that migration lands into
• Phase 3: Devices: Hybrid Join, Intune, WHfB sequencing during the Week 2–4 ramp
• Phase 4: Data Protection: label taxonomy that must exist in the target before content migrates