Quick answer. As of September 2026, Microsoft’s native path for moving identities onto Entra ID exists in a government tenant: its Microsoft Entra feature availability reference lists both Microsoft Entra Connect sync engines, cloud and federated authentication, Conditional Access, Privileged Identity Management and Microsoft Entra ID Governance as available in Azure for US Government, and what changes is the directory the identities land in, since Microsoft’s identity planning guide for Azure Government says Office 365 GCC was designed to use Microsoft Entra Public, describes Microsoft Entra Government as commonly used for GCC High and DoD, and says managing an Azure Government subscription requires identities from Microsoft Entra Government. Design around the exclusions before the first wave: according to Microsoft’s comparison of Azure Government and global Azure, Trusted IPs is not supported in Azure Government and Conditional Access named locations take its place; according to Microsoft’s B2B guide for government and national clouds, B2B collaboration is not enabled by default across national cloud boundaries until both tenants set it up in Microsoft cloud settings; and according to Microsoft’s cross-tenant synchronization overview, cross-cloud synchronization does not carry the manager attribute or groups. A financial-services tenant in the commercial cloud meets none of those exclusions, but both kinds of tenant share the same evidence rule: according to Microsoft’s diagnostic settings guide and its Entra data retention reference, logs might take up to three days to start appearing in their destination and retention changes are not retroactive, so route sign-in and audit logs before cutover.
Someone has just asked which migration tool the government tenant needs. It is a fair question with the wrong subject. The tenant you are moving into decides more than the tool does: it decides which Microsoft directory the identities land in, which Entra features behave differently on day one, and whether the record of the move exists when the assessor or examiner asks for it. Microsoft’s own documents, cited below with each page’s visible update date, answer most of that before any tool is chosen. This guide sets out the directory decision, the Microsoft capability that moves each identity source, what the government clouds leave out, what changes for a financial-services tenant, and the evidence to switch on before the first wave.
The first decision is the directory, not the tool
The failure that costs the most is discovering mid-migration that the identities went into the wrong directory. Government clouds are not settings inside the commercial cloud. According to Microsoft’s national clouds reference (last updated January 15, 2025), “National clouds are physically isolated instances of Azure.” The same page states: “All the national clouds authenticate users separately in each environment and have separate authentication endpoints.” An identity lives in one of them, and the choice follows it into every application and subscription it touches.
Which directory depends on which government service you run. Microsoft’s identity planning guide for Azure Government (last updated October 12, 2023) states that “The Office 365 GCC environment was designed to use Microsoft Entra Public” and describes Microsoft Entra Government as “Commonly used if your organization already has a Microsoft Entra Government tenant to support Office 365 (GCC High or DoD) or are creating a new tenant in Microsoft Entra Government.” Note the condition: Microsoft says commonly used, and this guide keeps that word. The hard requirement on that page is for Azure Government subscriptions. Asked whether an Azure Government subscription can be managed from a commercial directory, the same guide answers: “No, the ability to manage Azure Government subscriptions requires identities sourced from a directory in Microsoft Entra Government.” It adds that “If you have both Azure Public and Azure Government subscriptions, separate identities for both are required.”
That is how two tenants appear without anyone deciding to create them. According to the same Microsoft identity planning guide, “Now, many Office 365 GCC customers have two Microsoft Entra tenants: one from the Microsoft Entra subscription that supports Office 365 GCC and the other from their Azure Government subscription, with identities in both.” Applications follow the same split: Microsoft’s national clouds reference states that “To integrate applications with the Microsoft identity platform in a national cloud, you’re required to register your application separately in each Azure portal that’s specific to the environment.”
Three neighboring decisions sit outside this page. If the organization has not yet settled which Microsoft 365 government cloud it needs, start with Microsoft 365 GCC vs GCC High: Which Government Cloud Does Your Organization Need?. If the plan is a GCC High tenant, its phases are set out in Microsoft 365 GCC High Migration Checklist: Best Practices for Defense Contractors. If Azure subscriptions and workloads are moving too, that move is covered in Azure Government Migration: What Moving from Azure Commercial Actually Takes.
Before any wave, write down which directory each population lands in, and which applications must be registered in which cloud.
Which Microsoft capability moves each identity source
When someone asks which tool to buy, the real question is usually which source is hard to move. Microsoft’s Microsoft Entra feature availability reference (last updated January 15, 2026) lists, for Azure for US Government, directory synchronization with Microsoft Entra Connect (sync and cloud sync), cloud authentication by password hash synchronization or pass-through authentication, federated authentication, multifactor authentication, Conditional Access, Privileged Identity Management, access reviews, entitlement management, lifecycle workflows and API-driven inbound provisioning as available, and states that “Microsoft Entra ID Governance is available in the US Government community cloud (GCC), GCC-High, and Department of Defense cloud environments.” Microsoft’s resources for migrating applications to Microsoft Entra ID (last updated May 31, 2024) and its cross-tenant synchronization overview (last updated May 29, 2026) cover the rest. Read together, they give one Microsoft capability per source:
- On-premises Active Directory: Microsoft Entra Connect, with both the sync engine and cloud sync listed available in Azure for US Government. Which engine to run is its own decision, with its own government-cloud requirements, and is not made on this page.
- AD FS: cloud authentication and federated authentication are both listed available. Retiring federation, and the staged rollout that usually goes with it, is its own project and is not planned here.
- Another identity provider: the applications move through Microsoft’s “four clearly-outlined phases: discovery, classification, migration, and ongoing management”, and where that provider is the one covered in How Do I Hire Consultants to Migrate Us Off Okta Onto Microsoft Entra ID Without Breaking Access?, the policy translation and waves are set out there.
- Microsoft Identity Manager scenarios: Microsoft publishes guidance for moving them to Entra cloud services, and the Microsoft Identity Manager user client access license is listed available; that guidance is not restated here.
- Applications: Microsoft describes its migration resources as “Resources to help you migrate application access and authentication to Microsoft Entra ID.”
- Another Entra tenant, in the same cloud or the other one: cross-tenant synchronization is supported within the commercial cloud and within Azure Government. Across the two clouds, Microsoft’s answer is “Yes, cross-cloud synchronization (such as public cloud to Azure Government) is supported.” Its licensing condition is kept in full: “Each user who’s synchronized with cross-cloud synchronization must have a Microsoft Entra ID Governance or Microsoft Entra Suite license in their home/source tenant.”
No third-party migration tool is named, compared or recommended here, and no claim is made that any tool is needed or not needed for a compliance decision. This guide says what Microsoft’s own capabilities cover in each cloud, according to Microsoft’s feature availability reference. If someone proposes a non-Microsoft tool for a source, ask for the Microsoft capability it replaces and the reason, in writing.
For each source, name the Microsoft capability that moves it and the person who signs off the wave.
What the government clouds exclude or change during the move
A wave fails when it assumes a commercial behavior that the government cloud does not have. A Conditional Access design that leans on trusted IP ranges is the common case. According to Microsoft’s comparison of Azure Government and global Azure (last updated August 21, 2025), “Trusted IPs isn’t supported in Azure Government.” The same page gives the replacement in the next sentence: “Instead, use Conditional Access policies with named locations to establish when multifactor authentication should and shouldn’t be required based off the user’s current IP address.” For consumer-facing sign-in, the same comparison states that “Azure Active Directory B2C is not available in Azure Government.” Moving that kind of sign-in is its own project.
Guests from the other cloud are the second case. Microsoft’s B2B guide for government and national clouds (last updated July 7, 2025) states that “B2B collaboration isn’t enabled by default across national cloud boundaries, but you can use Microsoft cloud settings to establish mutual B2B collaboration”, so both tenants have to configure it before a cross-cloud guest can sign in. For invitations inside Azure US Government, the same guide warns: “If you invite a user outside of these groups (for example, if the user is in a tenant that isn’t part of the Azure US Government cloud or doesn’t yet support B2B collaboration), the invitation fails or the user can’t redeem the invitation.” Collaboration in GCC High is narrower again: Microsoft’s Office 365 GCC High and DoD service description (last updated August 3, 2026) states that “Users in GCC-High will be able to share only with other organizations in GCC-High.” How to share controlled unclassified information with primes and subcontractors in each partner’s cloud is a separate subject from the migration and is not planned here.
Synchronized identities are the third case. According to Microsoft’s cross-tenant synchronization overview, cross-cloud synchronization is supported, but the same page names two things it does not carry: “Synchronization of the manager attribute isn’t currently supported in cross-cloud synchronization.” and “Synchronizing groups across cloud environments such as Azure commercial, Azure Government, and Azure in China isn’t supported.” Any access rule, approval flow or group-based assignment that depends on a synchronized manager or group has to be rebuilt on the target side, and every synchronized user carries the source-tenant license condition quoted in the previous section.
Microsoft’s feature availability reference lists further features that are unavailable or partial in Azure for US Government; they are set out, with the verification questions to ask about them, in The Buyer’s Guide to Evaluating IAM Implementation Firms for Regulated Industries. If the move is from one tenant to another after a deal, rather than onto Entra ID from another source, that case is covered in Managing Dual-Tenant Microsoft Complexity After a Merger or Acquisition.
Before the pilot wave, check every Conditional Access policy, guest population and synchronized attribute against this list.
A financial-services tenant: same Microsoft capabilities, and the evidence is the difference
A bank, insurer or capital-markets firm moving identities onto Entra ID in the commercial cloud faces a different risk from the government contractor. The exclusions in the previous section are stated by Microsoft for Azure Government and the national clouds, which Microsoft’s national clouds reference describes as “physically isolated instances of Azure.” A tenant in the commercial cloud is not in one of them, so the directory split, the Trusted IPs gap and the cross-cloud guest defaults do not arise. The per-source map above still applies, source by source.
What does not get easier is the record. The examiner’s question is rarely which tool moved the identities; it is what happened to access during the move and who approved it. No financial regulator’s authentication, retention or examination expectation is described here; those belong to your compliance team and your examiner. What this guide does say is that the design effort saved on government-cloud exceptions is best spent on the evidence in the next section, switched on before the first wave rather than reconstructed after it.
Treat the commercial design as settled by the map above, and put the time into the evidence plan.
The evidence to keep, and why it has to be switched on first
The evidence gap no one plans for is the first wave’s. Entra sign-in and audit logs are routed by diagnostic settings, and the routing has to exist before the events you want to keep. According to Microsoft’s diagnostic settings guide (last updated June 16, 2025), “Using diagnostic settings in Microsoft Entra ID, you can integrate logs with Azure Monitor, stream logs to an event hub, or archive logs to a storage account.” The same guide sets the order: “You must have a destination set up prior to configuring diagnostic settings.” And it sets the lag: “It might take up to three days for the logs to start appearing in the destination.”
Changing retention later does not recover what was lost. Microsoft’s Entra data retention reference (last updated March 25, 2026) states that “Log retention changes aren’t retroactive.” It also states that “Microsoft Entra ID audit and sign-in logs are separate from the Microsoft 365 Unified Audit Log (UAL).” An evidence plan that reads only the Unified Audit Log therefore misses the identity record of the move. How long each log is kept, and how to export it, is its own decision and is not set here. Where the move retires federation, Microsoft’s staged rollout guide (last updated September 15, 2026) notes that “We’ve enabled audit events for the various actions we perform for Staged Rollout:” and those events belong in the same destination.
The evidence set below is this guide’s planning recommendation for the tenant owner, not a Microsoft or regulator requirement:
- The directory decision record: which population lands in which directory, and why.
- The per-source map: the Microsoft capability that moved each source, and who signed off each wave.
- The exclusion decisions: each Conditional Access policy, guest population and synchronized attribute checked against the government-cloud list, and what was rebuilt.
- The sign-in and audit logs for each wave, from the routed destination.
Because Microsoft’s diagnostic settings guide says logs might take up to three days to start appearing, create the destination and the diagnostic setting at least three days before the pilot wave, and name who keeps the record.
When this guide is the wrong starting point
If your question is not about the move itself, this guide is the wrong starting point, and the cases below say where to go instead. If the real question is which third-party migration tool to buy, this guide does not compare tools; it says only what Microsoft’s own capabilities cover. If the move is a tenant consolidation after a merger or acquisition, the dual-tenant page linked above is the place to start. If the question is whether on-premises Active Directory or cloud-only Entra ID should be the identity authority for a CMMC assessment boundary, that is a scoping decision this guide does not make. If Azure workloads are moving to Azure Government as well as identities, the workload move has its own page, linked above. If someone wants a statement that a tool or a tenant is compliant, no Microsoft page read for this guide says that, and the determination belongs to the tenant owner and its assessor or examiner. And a DoD component with identity requirements of its own should read them from its own sources; they are outside this page.
What to ask of whoever helps you move it
Whoever does this work with you, inside the organization or outside it, hold it to these criteria, stated as what they should be able to show you:
- Which directory each population lands in, and why, before any tool is chosen.
- The Microsoft capability that moves each source, and a written justification for any non-Microsoft tool against it.
- Every Conditional Access policy, guest population and synchronized attribute checked against the government-cloud exclusions.
- The log routing live before the pilot wave.
- Who provisions the government tenant and under what authorization, with evidence of that status rather than a claim of it.
- The runbooks and the evidence handed to your own team to keep.
No firm, supplier or tool is named or compared in that work.
How i3solutions answers
i3solutions has done hundreds of Okta to Entra ID conversions. i3solutions governs identity and access for regulated Microsoft estates with senior, U.S.-based engineers and leaves an audit-defensible record. i3solutions has deep experience implementing identity governance for enterprises in aerospace and defense manufacturing, financial services, and healthcare, including environments with CMMC and ITAR obligations.
For a move onto Entra ID in a government or financial-services tenant, that means a project, with embedded specialists where your team needs them, that decides the landing directory, maps each source to the Microsoft capability that moves it, designs around the government-cloud exclusions and switches on the evidence before the first wave.
We manage GCC High migrations end-to-end: from eligibility validation and licensing coordination with your AOS-G supplier through identity architecture, data migration, security baseline configuration, and post-migration governance. i3Solutions plans and runs these migrations for regulated defense organizations, structuring each phase around the compliance evidence assessors expect. The GCC High tenant itself is provisioned by your AOS-G supplier, and i3solutions works alongside that supplier.
i3solutions has been a Microsoft partner since 1997 and has delivered 600+ implementations across aerospace and defense, financial services, and health sciences. An i3solutions engagement does not produce managed-service ownership, a replacement for the internal team, open-ended scope expansion, or vendor lock-in.
For how this fits the wider identity program, see Establish Identity as a Governed Enterprise Capability.
Key Takeaways
Every Microsoft fact below is drawn from Microsoft’s identity planning guide for Azure Government, its feature availability reference, its comparison of Azure Government and global Azure, its B2B guide for government and national clouds, its cross-tenant synchronization overview, its diagnostic settings guide and its Entra data retention reference, each re-read on drafting day:
- Decide the directory before the tool: Office 365 GCC was designed on Microsoft Entra Public, Microsoft Entra Government is commonly used for GCC High and DoD, and managing an Azure Government subscription requires Microsoft Entra Government identities.
- Microsoft lists its sync engines, cloud and federated authentication, Conditional Access, Privileged Identity Management and Entra ID Governance as available in Azure for US Government.
- Trusted IPs is not supported in Azure Government; use Conditional Access named locations instead.
- Cross-cloud B2B collaboration is off by default until both tenants configure Microsoft cloud settings, and cross-cloud synchronization does not carry the manager attribute or groups.
- Route sign-in and audit logs before cutover: logs might take up to three days to appear, and retention changes are not retroactive.
Frequently Asked Questions
Does GCC use Microsoft Entra Government?
No. According to Microsoft’s identity planning guide for Azure Government, the Office 365 GCC environment was designed to use Microsoft Entra Public. Microsoft describes Microsoft Entra Government as commonly used when an organization has a Microsoft Entra Government tenant to support Office 365 GCC High or DoD.
Can an Azure Government subscription use our commercial Entra ID tenant?
No. According to Microsoft, the ability to manage Azure Government subscriptions requires identities sourced from a directory in Microsoft Entra Government, and an organization with both Azure Public and Azure Government subscriptions needs separate identities for both.
Is cross-cloud synchronization supported between commercial Entra ID and Azure Government?
Yes, with conditions. According to Microsoft, cross-cloud synchronization such as public cloud to Azure Government is supported, but synchronization of the manager attribute isn’t currently supported, groups are not synchronized across cloud environments, and each synchronized user must have a Microsoft Entra ID Governance or Microsoft Entra Suite license in the home or source tenant.
Does Trusted IPs work in Azure Government?
No. According to Microsoft, Trusted IPs isn’t supported in Azure Government; Microsoft says to use Conditional Access policies with named locations instead.
When should we turn on Entra log routing during a migration?
Before the first wave. According to Microsoft, a destination must be set up before diagnostic settings are configured, logs might take up to three days to start appearing in the destination, and log retention changes aren’t retroactive.
Planning the Decision
If identities are about to move onto Entra ID in a government or financial-services tenant, start by writing down which directory each population lands in, check every Conditional Access policy, guest population and synchronized attribute against the government-cloud exclusions, and switch on log routing before the pilot wave.
