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: the things that are true because you are crossing a cloud boundary or merging tenants, and that the greenfield chapters do not address.

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, OneDrive content, 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.
• External meeting attendees need Cross-Cloud Meeting Join. Conditional Access policies that target external identities — typical for CUI-handling meetings — only apply if the external attendee authenticates. Anonymous Teams External Access bypasses CA. Cross-Cloud Meeting Join brings the external user's authentication and compliance claims into the meeting, but has documented limits: no file sharing, no group chat, no persistent meeting-chat access. For full-fidelity external collaboration, a B2B Guest invite is still required.
• 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
Teams External Access	Anonymous	No	No	No	Minimal — tenant-level toggle
Cross-Cloud Meeting Join	Authenticated (partner-side)	Yes	No	No	Partner-side setup required
B2B Guest	Full user object	Yes	Yes	Yes	Coordinated CTAS on both sides, Team membership

For CUI-adjacent collaboration, Cross-Cloud Meeting Join is the minimum tier that allows CA enforcement. B2B Guest is the only tier that supports full document and chat workflows.

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.
• Mailbox migration order matters for GCC-to-GCC. When both source and target are GCC High and you want to preserve primary SMTP addresses, migrate the target-tenant mailbox first, then migrate the source-tenant mailbox content into it. Header rewrites during migration keep reply-to-migrated-mail functional.
• 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 during the transition. Once hybrid is configured in the target tenant, Teams shows on-premises Exchange calendars correctly. Between tenants, free-busy does not flow unless a Cross-Cloud Meeting Join or organization-relationship is explicitly configured.
• Sensitivity labels do not survive a tenant migration. Labels are tenant-scoped. Migrated content loses its source-tenant label. Before content migration, the target tenant must have an equivalent label taxonomy published, and a re-labeling pass must follow migration — either automatic (auto-labeling policy matching patterns) or manual (workload owners confirm). Treat label re-application as a migration step, not a later nice-to-have.
• Use a FedRAMP-authorized migration tool. For CMMC-scoped tenants, the migration tool itself processes CUI in transit. Tooling like AvePoint Fly SaaS carries FedRAMP authorization; non-FedRAMP tools should not be used for CUI workloads regardless of convenience or price.

Device and app gotchas

• 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 on Day 1. Devices will fail to reach compliance until Hybrid Join, Intune enrollment, and WHfB have all completed, and enforcing compliance during that window locks users out. The standard phased timeline:

• Day 1. Phishing-resistant authentication enforced for all users. Device compliance CA in report-only mode.
• Week 2. 100% Entra Hybrid Join across the fleet. Confirm via Entra device inventory.
• Week 4. 100% Intune Compliance. Enable the Device Compliance CA policy in enforce mode.

Report-only mode continues the source-tenant's level of non-enforcement for the transition window. Communicate the date each enforcement level activates so users understand the timeline.

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 Phase 3.
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