How to Migrate to GCC High Without Expanding Scope by Accident
A Migration Is a Compliance Event, Not an IT Project
Every GCC High migration creates a temporary period where two tenants coexist, data lives in transit, and configurations are half-built. Without deliberate scope control at every phase, the migration itself becomes the reason your assessment boundary grows — and the reason your assessment gets harder.
Why Migrations Create Temporary Scope Chaos
A GCC High migration sounds like a straightforward infrastructure move: stand up a new tenant, copy the data, decommission the old one. In practice, it is a multi-month project during which both environments are live, both contain CUI, and neither is in its final documented state.
That interim period is where scope expands unintentionally. Systems that were never supposed to be part of the assessment boundary get pulled in because they touched CUI during the transition. Legacy connectors keep syncing data to the old tenant after cutover. Coexistence tools create bridges between Commercial and GCC High that become permanent fixtures nobody remembers to remove.
This is not hypothetical. Organizations regularly schedule C3PAO assessments three to six months after migration, assuming the new environment will be stable by then. What they discover is that the old tenant still has active mailboxes, SharePoint sites with residual CUI, OneDrive accounts with synced copies, and Intune policies that were never ported. Each of these is a system that stores, processes, or transmits CUI — and each one is now inside the assessment boundary whether the SSP accounts for it or not.
The solution is not to delay the assessment indefinitely. It is to plan the migration as a compliance event from day one — with scope control, evidence preservation, and decommission verification built into every phase.
Pre-Migration Scoping and Dependency Inventory
Before a single mailbox moves, you need a complete map of everything that touches CUI in the current environment — and everything that will touch CUI in the target environment. The goal is to define the migration boundary as precisely as the assessment boundary.
This means inventorying far more than mailboxes and SharePoint sites. It means identifying every system, integration, and data flow that interacts with CUI.
The Migration Sequence: Identity, Mail, Files, Collaboration, Devices, Logging
Order matters. A GCC High migration is not a parallel lift-and-shift — it is a sequential dependency chain where each layer depends on the one before it. Getting the sequence wrong creates orphaned configurations, broken integrations, and CUI in limbo.
Identity First
Provision the GCC High Azure AD tenant. Create user accounts, groups, and service principals. Configure conditional access policies, MFA, and PIM roles before any data moves. Every subsequent migration step depends on identity being in its final state. If you migrate mailboxes before conditional access is configured, users will access CUI from the new tenant without the controls your SSP describes.
Mail Migration
Migrate Exchange mailboxes using a cutover or staged approach. There is no native coexistence between Commercial and GCC High Exchange — you cannot split a domain across both tenants simultaneously with free/busy or calendar sharing. Plan for a hard cutover weekend where MX records switch to GCC High. Migrate transport rules, DLP policies, and mail flow connectors to the new tenant in advance. Test them before the cutover.
Files and SharePoint
Migrate SharePoint sites and OneDrive accounts using a third-party migration tool — Microsoft does not provide a native tenant-to-tenant migration path between Commercial and GCC High. Map source sites to destination sites. Preserve permissions, metadata, and version history where possible. Validate that sensitivity labels transfer correctly — some labels may need to be recreated in the GCC High tenant's Purview configuration.
Teams and Collaboration
Teams data — channels, chats, files, tabs, and apps — does not migrate natively between tenants. Recreate Teams structures in GCC High manually or with migration tooling. Chat history is the hardest to preserve. Channel files live in SharePoint and can be migrated with site content, but private chats are stored in individual user mailboxes and require separate handling. Third-party Teams apps may not be available in GCC High — verify app availability before migration.
Devices and Endpoint Management
Unenroll devices from Commercial Intune and re-enroll them in GCC High Intune. This is not a sync — it is a full re-enrollment. Compliance baselines, configuration profiles, and app deployment policies must be rebuilt in the GCC High tenant. Autopilot hardware hashes must be re-registered. Plan for a window where devices are between tenants and ensure CUI access is blocked during that gap via conditional access.
Logging and Monitoring Last
Enable Unified Audit Logging in GCC High on day one of tenant provisioning — not after migration. Connect Microsoft Sentinel or your external SIEM to the new tenant's log sources. Verify that audit log retention meets your SSP requirements (typically one year minimum, with longer retention for specific event types). Do not disconnect logging from the old tenant until decommission is complete — you need continuous coverage with no gaps.
Common Missteps: Coexistence, Duplicate Repositories, Legacy Connectors
The most damaging migration mistakes are not technical failures. They are decisions — or non-decisions — that leave artifacts from the old environment alive and in scope long after the migration is supposed to be complete.
Extended Coexistence
Running both tenants "just in case" for months after cutover. Every day the old tenant remains active with CUI content, it is in scope. Coexistence is not a safety net — it is scope expansion with a monthly licensing bill.
Duplicate SharePoint Sites
Migrating SharePoint content to GCC High but leaving the source sites intact in Commercial with all permissions still active. Users bookmark old URLs. Search results point to old sites. CUI remains accessible in the non-compliant tenant indefinitely.
Legacy API Connectors
Third-party applications with OAuth tokens authorized against the Commercial tenant continue to pull or push data after migration. CRM integrations, ERP connectors, Power Automate flows, and backup solutions are common offenders. If the connector reads CUI, it puts the old tenant — and the third-party system — in scope.
Orphaned OneDrive Accounts
When user accounts are deleted in the Commercial tenant, their OneDrive content enters a 30-day retention period by default — sometimes longer if a retention policy applies. CUI files sit in orphaned OneDrive storage, fully accessible to administrators, unmonitored, and undocumented in the SSP.
Forgotten Mail Forwarding Rules
Users or administrators set up mail forwarding rules during migration to ensure nothing is missed. Those rules keep running after cutover, copying every new message — including CUI — from GCC High back to the Commercial mailbox. A single forwarding rule can undo the entire migration.
Stale Intune Enrollments
Devices that were enrolled in Commercial Intune but never re-enrolled in GCC High continue to report compliance status to the wrong tenant. Conditional access in GCC High does not see them as compliant — but the devices still have locally cached CUI from the sync client. They are unmanaged endpoints with CUI at rest.
Every one of these missteps has the same consequence: a system, data store, or data flow that your SSP does not describe but that an assessor will discover. The fix is not to hope the assessor doesn't look. The fix is to build a decommission checklist that is as detailed as the migration plan — and execute it completely before the assessment.
How to Preserve Evidence and Configurations During Cutover
A migration destroys the evidence that proves your old environment was compliant. Conditional access policies, DLP rules, transport rules, audit logs, Intune baselines — all of these exist in the Commercial tenant. When that tenant is decommissioned, the evidence goes with it.
If your CMMC assessment covers the period before, during, or after migration, you need to preserve a record of your control posture at every stage.
- Export all conditional access policies from the Commercial tenant as JSON before decommission. Store the exports in your evidence vault with timestamps.
- Screenshot or export DLP policy configurations — including trigger conditions, actions, and exception lists — from the Commercial tenant before they are deleted.
- Export Exchange transport rules from both tenants. Document which rules were active during the coexistence window and which were activated post-cutover.
- Download the Unified Audit Log from the Commercial tenant for the full migration period. Retain it for at least the same duration as your standard audit log retention policy. Store it in the GCC High environment or a FedRAMP-authorized archive.
- Export Intune device compliance and configuration profiles from Commercial before re-enrollment. Document which devices were enrolled, their compliance state at cutover, and when they were re-enrolled in GCC High.
- Capture sensitivity label configurations from Microsoft Purview in the Commercial tenant. Labels are tenant-specific and must be recreated in GCC High — verify that the recreated labels have identical settings.
- Hash critical evidence files using SHA-256 at the time of export. Store the hashes alongside the evidence. This proves the evidence was captured at a specific point in time and has not been altered.
Interim-State Risks and How to Document Them
There is no migration that happens instantaneously. For some period — days to weeks — your organization will be operating in a state that does not match either the pre-migration SSP or the post-migration SSP. This interim state is a compliance risk that must be acknowledged and managed, not ignored.
Pre-Migration
Current SSP describes Commercial or GCC environment. Controls documented. Evidence collected.
Migration Window
Both tenants active. Data in transit. Controls partially ported. Neither SSP fully accurate.
Post-Migration
GCC High SSP describes target environment. Old tenant decommissioned. Evidence validated.
The recommended approach is to create a Migration Security Addendum to your SSP — a temporary document that describes the interim-state architecture, the controls in effect during the transition, the timeline for reaching the target state, and the specific risks accepted during the window. This addendum should include:
- Start and end dates for the migration window, by workload (identity, mail, files, devices, logging)
- Which controls are temporarily degraded — for example, if endpoint DLP is not yet configured in GCC High, document that gap and the compensating control (e.g., conditional access restricting access to managed devices only)
- Which systems are temporarily in scope that will not be in the final assessment boundary — for example, the Commercial tenant during coexistence
- How CUI is protected during the transition — which tenant is authoritative for CUI at each phase, and what prevents CUI from existing in both simultaneously
- Rollback criteria — under what conditions the migration is paused or reversed, and what the compliance posture looks like if that happens
If a C3PAO assessment occurs during or shortly after migration, this addendum is the document that explains why your environment doesn't perfectly match the SSP — and why that deviation was planned, controlled, and temporary. Without it, every discrepancy is an unexplained finding.
Post-Migration Validation Checklist
Migration is not complete when the data arrives in GCC High. Migration is complete when the old environment is fully decommissioned, the new environment matches the SSP, and every control can be demonstrated to an assessor. This checklist covers what must be verified before declaring the migration done.
| Validation Item | Method | Status Required |
|---|---|---|
| All CUI mailboxes migrated | Exchange admin center — verify no active mailboxes remain in Commercial tenant | Zero active CUI mailboxes in old tenant |
| SharePoint CUI sites decommissioned | Content Search in Commercial tenant for CUI-labeled content. SharePoint admin — verify sites deleted or locked. | No CUI content discoverable |
| OneDrive accounts cleaned | Verify orphaned OneDrive accounts have passed retention window and content is permanently deleted | No residual CUI in orphaned accounts |
| Conditional access policies active | Azure AD admin — export and review all policies in GCC High. Verify they match target-state SSP. | All policies match SSP description |
| DLP policies active and tested | Run controlled tests with CUI-labeled content. Verify policies trigger correctly. Export incident reports. | Policies firing with documented evidence |
| Sensitivity labels applied | Content Search for unlabeled content in GCC High. Verify auto-labeling rules are active. | Ongoing — monitor for unlabeled CUI |
| Devices re-enrolled | Intune admin — verify all CUI-accessing devices enrolled in GCC High. Verify compliance baselines applied. | 100% re-enrollment for CUI users |
| Audit logging active | Verify Unified Audit Log is enabled. Confirm retention settings. Verify SIEM integration receiving events. | No logging gaps since tenant creation |
| Third-party connectors revoked | Azure AD app registrations — verify all OAuth tokens for the Commercial tenant are revoked. Verify no active API connections remain. | Zero active connectors to old tenant |
| Mail forwarding rules removed | PowerShell sweep of all mailboxes in both tenants for active forwarding rules. Verify none point cross-tenant. | No cross-tenant forwarding |
| SSP updated to reflect target state | Review SSP boundary description, data flow diagrams, asset inventory, and control implementation statements against GCC High environment | SSP matches live environment |
| Commercial tenant decommissioned | Tenant subscription cancelled or converted to non-CUI use. All CUI content confirmed deleted. Admin access revoked or limited. | Tenant out of scope |
The Bottom Line
A GCC High migration is the right decision for most defense contractors handling CUI. But the migration itself is a compliance event that, if executed carelessly, creates more scope than it eliminates. The contractors who migrate cleanly are the ones who treat decommission as seriously as deployment — who build a migration manifest, preserve evidence at every phase, document the interim state, and verify that the old environment is completely cold before an assessor arrives.
The goal is not just to arrive in GCC High. The goal is to arrive in GCC High with a clean assessment boundary, a current SSP that matches the live environment, and zero residual CUI in the environment you left behind. That is what a defensible migration looks like.