Azure Government migration is the project a defense contractor reaches when its Azure workloads, the custom applications, data, and infrastructure that run the business, have to meet requirements that Azure Commercial was not built to satisfy. i3solutions has delivered Microsoft platform and Azure work for regulated organizations across aerospace and defense, financial services, and healthcare, and the same delivery discipline that protects those engagements governs how we scope a cloud migration. As a Microsoft Solutions Partner since 1997, with 600+ Microsoft platform implementations across nearly 30 years, i3solutions treats an Azure Government move as an Enterprise Delivery Assurance problem: scope the workloads correctly, and the migration lands on-time, in-scope, and in-production. This is the borrowed expertise a VP of IT brings in when a cloud migration is really a re-architecture with a compliance deadline attached.
Quick Answer
Azure Government migration is the re-deployment of Azure workloads from the commercial cloud into Microsoft’s isolated government cloud. It is not a lift-and-shift, because the two clouds have separate identity, endpoints, and service catalogs. It is required when workloads need US-person-only access or DoD Impact Level 4 or 5, and optional otherwise.
Key Takeaways
- Azure Government migration is a re-deployment, not a lift-and-shift: Azure Commercial and Azure Government are isolated clouds with separate identity, endpoints, and service catalogs, so workloads are rebuilt rather than relocated.
- The government cloud is required only when a workload needs US-person-only access, handles ITAR or EAR export-controlled data, or must meet DoD Impact Level 4 or 5. FedRAMP High alone does not force the move, because Azure Commercial already holds it.
- Both Azure Commercial and Azure Government carry a FedRAMP High authorization, so the decision is made workload by workload against the specific obligation, not as a blanket move of the whole estate.
- The three expensive failure modes are treating the project as a lift-and-shift, over-scoping the migration, and missing a service-availability gap, and all three trace back to scoping the workloads too late.
- Scope the obligation first, migrate only the workloads that require the government cloud into an enclave, and leave everything else in the commercial cloud where it runs for less.
Azure Government Migration: Why It Is a Re-Deployment, Not a Move
Defense contractors planning an Azure Government migration usually discover the same surprise: there is no lift-and-shift, because Azure Commercial and Azure Government are separate, isolated clouds, and the workloads that handle CUI have to be rebuilt in a new tenant, not relocated. The decision that comes first, and the one most teams skip, is which workloads actually require the government cloud at all, because moving the wrong ones wastes budget and moving the right ones late risks a compliance finding under deadline.
Azure Government is a physically and logically isolated instance of Azure, built exclusively for United States government entities and their solution providers, including the defense industrial base. Its data centers are in the continental United States only, and the personnel who operate it are screened United States citizens. The practical consequence for a migration is that Azure Government is not a region you switch on inside your existing subscription. It is a separate cloud with its own portal at portal.azure.us, its own API endpoints, and its own identity service: Microsoft Entra ID Government is a separate directory from the commercial Microsoft Entra ID, with its own credentials and a tenancy that ends in onmicrosoft.us, and the two interoperate only through controlled cross-cloud collaboration rather than a shared tenant.
Because the two environments are isolated, there is no in-place migration path between them. Workloads are re-deployed: applications are rebuilt against the government endpoints, identities are re-provisioned in the new directory, and data is moved across the boundary rather than connected through it. Treating that work as a relocation is the single most expensive misunderstanding in the project, and it is why an Azure Government migration is better understood as a re-architecture with a compliance deadline than as a move.
The government cloud is also operated differently once you are in it. Azure Government runs from dedicated United States regions, with the highest DoD Impact Level 5 workloads served from separate Department of Defense regions, and it is the same isolated platform that underlies Microsoft 365 GCC High, which is why the Azure and Microsoft 365 sides of a defense estate usually move together. Every subscription used for federal work must obtain an Authority to Operate before it can run production workloads, and once it does, changes flow through tighter change management than most commercial teams are used to, often a formal change-control process intended to protect the authorization. None of that is a reason to avoid the move; it is a reason to plan it as the governed, sequenced program it is, rather than as a weekend cutover.
Do You Actually Need to Migrate to Azure Government? FedRAMP High, US Persons, and Impact Levels
The most common reason organizations over-spend on this migration is a misunderstanding about FedRAMP. Both Azure Commercial and Azure Government hold a FedRAMP High Provisional Authorization to Operate. FedRAMP High alone, in other words, is not the trigger for the government cloud, because the commercial cloud already meets it. Microsoft documents the exact services and authorizations in scope across both environments in its Azure Government FedRAMP and DoD audit-scope guidance, and the FedRAMP control set itself is defined in NIST SP 800-53. The real differentiators are narrower, and they are what should drive the decision.
What actually forces Azure Government
Three requirements move a workload from optional to required. The first is United-States-person access: only Azure Government screens its operations personnel as United States citizens and restricts data to the continental United States, which is what satisfies ITAR and EAR export-control obligations and any contract that demands United States sovereignty. The second is the higher DoD Impact Levels: Azure Government carries DoD SRG Impact Level 4 and Impact Level 5 authorizations that the commercial cloud does not, with Impact Level 5 served from dedicated regions. The third is specific handling rules such as CJIS, where Azure Government can store unencrypted criminal-justice data because its staff are background-checked, while the commercial cloud cannot. If none of those apply, FedRAMP High in the commercial cloud, configured and documented correctly, may already be sufficient, and our Microsoft 365 Compliance Consulting practice starts every cloud decision by confirming which of these triggers is actually present.
One caution applies in both directions. A FedRAMP authorization, in either cloud, is an authorization of the platform, not a certification of your application. Microsoft is responsible for the controls that the platform inherits, but the configuration of your workloads, your identity model, and your data handling remains yours, and an assessor evaluates the whole system, not just the cloud underneath it. Choosing Azure Government does not make a workload compliant, and choosing Azure Commercial does not make it non-compliant; the environment sets the ceiling, and your configuration decides whether you reach it. That is why the decision is best made workload by workload against the specific obligation, rather than as a blanket move of the entire estate.
When You Must Migrate to Azure Government, and When Commercial Is Enough
Reading the trigger correctly is how a contractor avoids paying to move workloads that never needed to move. The decision splits cleanly once the data and the contract are understood, and the honest version of the answer includes the cases where the migration is unnecessary.
When the migration is required
Migrate to Azure Government when workloads store, process, or transmit ITAR or EAR export-controlled technical data, when a contract requires United-States-person-only access or United States data sovereignty, or when the workload must meet DoD Impact Level 4 or 5. These are the same drivers that send the Microsoft 365 side of the estate to GCC High, which runs on Azure Government, so the two decisions are usually related; our GCC High and Sensitive Data Protection consulting covers the productivity-suite half, and the DoD’s CMMC program defines the certification context the workloads are assessed against. For DoD contractors that context is usually CMMC Level 2, which maps to the 110 controls of NIST 800-171, and the Azure workloads in scope are the ones that store, process, or transmit the CUI those controls protect. Azure Government inherits the platform side of the picture, with Microsoft responsible for the bulk of the NIST 800-53 controls the cloud carries, while the 800-171 obligation stays with the contractor and its applications.
The practical test is to look at the data and the contract together, not the technology. A workload that processes export-controlled drawings, a database that holds technical data subject to ITAR, or an application a contract says only United States persons may administer, all point to the government cloud regardless of how modern or well-built they are in the commercial one. The technology rarely decides this; the obligation does, and the obligation is what the scope should be drawn around.
When Azure Commercial is genuinely enough
Stay in Azure Commercial when the requirement is FedRAMP High without a United-States-person restriction, when the data is federal but not CUI, or when the workloads are standard commercial systems that carry no export-control or Impact Level obligation. The cost-control lever most teams miss is scope: rather than migrating the entire Azure estate, segregate the workloads that actually require the government cloud into an enclave and migrate only those, leaving everything else in the commercial cloud where it runs for less. The honest version of this answer is the one most vendors skip: if no workload carries a United-States-person or Impact Level obligation, you may not need Azure Government at all.
Not sure which of your Azure workloads actually require the government cloud? Schedule an Azure Government migration advisory discussion with an i3solutions principal.
What Has to Be Rebuilt in an Azure Government Migration
Once the workloads are scoped, the work itself is a rebuild, not a copy. Four areas account for most of the effort, and underestimating any of them is how a timeline slips.
Identity and tooling
Microsoft Entra ID Government is a separate directory, so identities, groups, conditional-access policies, and application registrations are re-provisioned rather than synchronized from the commercial tenant. Every piece of automation that targets the commercial cloud has to be retargeted: infrastructure-as-code templates such as ARM, Bicep, and Terraform, deployment pipelines, and management scripts all point at the commercial endpoints by default and must be reconfigured for the government portal and APIs. Strong identity design is the backbone of the new environment, which is why we treat Microsoft Identity and Access Management Solutions as the first build surface.
Services, networking, and authorization
Not every Azure service is available in the government regions, and some arrive on a later timeline, so each workload’s service dependencies have to be verified against the government region catalog before migration, and some services need extra configuration to meet Impact Level 5 isolation requirements. Networking is rebuilt with ExpressRoute Government and a hub-and-spoke topology rather than reused. And because every subscription used for federal work needs an Authority to Operate before production, with tighter change management afterward, the migration is sequenced alongside the authorization rather than ahead of it. Azure Government provides meaningful control inheritance, with Microsoft responsible for the bulk of the NIST 800-53 controls and the customer responsible for the application-level remainder, which is exactly the kind of Microsoft Integration Architecture work that has to be designed deliberately rather than assumed.
Data is the other piece that surprises teams. Because the clouds are isolated, data does not flow between them on a private link; it is exported from the commercial environment and re-ingested into the government one, which has to be planned for volume, downtime, and chain-of-custody on sensitive content. Monitoring and security operations are rebuilt as well, with the government equivalents of the tooling your commercial environment relied on. The throughline across identity, services, networking, data, and monitoring is the same: each is a rebuild in a new cloud, and the migration plan has to budget for the rebuild rather than a copy.
Need senior, US-based engineers to scope and execute the re-deployment? See how to engage i3solutions Microsoft integration specialists.
The Three Ways an Azure Government Migration Goes Wrong
Most troubled Azure Government migrations fail for one of three reasons, and all three trace back to a planning assumption made before the workloads were scoped.
Treating it as a lift-and-shift: the gap between a move and a rebuild
The first failure mode is planning the project as a relocation. Teams budget and schedule for a migration of virtual machines and discover, after the contract is signed, that there is no in-place path, that identities and tooling have to be rebuilt against new endpoints, and that the timeline assumed a move that does not exist. The gap between a move and a rebuild is where the budget overrun lives.
Over-scoping: when the wrong workloads get migrated and budget is wasted
The second failure mode is migrating the entire estate when only a subset carries a United-States-person or Impact Level obligation. Moving the wrong workloads into the more expensive, more constrained government cloud wastes licensing and engineering effort and slows everyone down, all to protect data that Azure Commercial could have held. The remedy is the enclave: scope the obligation, migrate only what requires it.
The missing-service gap that strands an application after cutover
The third failure mode surfaces at the worst time. An application depends on an Azure service that is not available in the government regions, or is available only with different configuration, and no one checked the region catalog during planning. The application is stranded after cutover, and the team is re-architecting under production pressure. A service-dependency check before migration is what prevents it.
What the three failure modes share is timing. Each one is set in motion by a decision made before the workloads were scoped: the budget assumed a move, the scope assumed the whole estate, the plan assumed full service parity. Scoping the workloads first, against the actual obligation and the actual service catalog, is what turns all three from a mid-project crisis into a line item that was planned for. That is why the assessment comes before the migration, not alongside it.
How to Evaluate a Partner for an Azure Government Migration
Once you know the migration is a re-architecture rather than a move, the risk shifts to the firm you choose to execute it. Evaluating a partner for an Azure Government migration is about evidence the firm has done this inside the compliance boundary, not just in commercial Azure. Six questions separate a credible partner from a risky one.
The six questions a regulated buyer should ask
First, will the firm scope which workloads actually require the government cloud before it proposes a migration, or move the whole estate by default? Second, can it show how it rebuilds identity, retargets infrastructure-as-code, and verifies service availability in the government regions, rather than assuming a lift-and-shift? Third, does it design the migration alongside the Authority to Operate and the NIST 800-53 control inheritance, and produce audit-ready evidence? Fourth, who performs the work, senior United-States-based engineers who can operate inside the personnel requirements of the government cloud, or a rotating offshore bench that cannot? Fifth, will it tell you when Azure Commercial is enough and the migration would be wasted spend? Sixth, does it transfer ownership of the environment to your team, or engineer a permanent dependency? A partner that answers all six with specifics has earned the right to your workloads.
How i3solutions Delivers Azure Government Migrations
An Azure Government migration is finally a decision about who you trust to rebuild your workloads inside a compliance boundary. i3solutions approaches it the way it approaches every regulated engagement: assessment-led, delivered by senior United-States-based engineers, and governed by Enterprise Delivery Assurance from the first workload assessment to production handover. We do not staff these programs with rotating offshore benches; the people who scope the workloads are the people accountable for the migration landing on-time, in-scope, and in-production, with the compliance evidence intact. We run these programs through four phases, Discovery, Architecture, Build, and Optimize: Discovery scopes the workloads and the enclave boundary, Architecture designs the identity, networking, and service mapping and the authorization approach, Build re-deploys and migrates only what belongs inside the boundary, and Optimize hardens the environment, assembles the audit evidence, and transfers ownership.
A defense contractor planning to move its entire Azure estate engaged i3 and left with an enclave design that migrated only the CUI-handling applications into Azure Government, keeping the rest in the commercial cloud and saving the cost of moving workloads that never required it. The scoping work mapped each application to the specific obligation it carried, separated the handful that touched export-controlled data from the majority that did not, and gave the contractor a documented basis for the boundary that an assessor could follow. An ITAR supplier that had budgeted a lift-and-shift engaged i3 after the project stalled, and we reset it into a re-deployment plan, rebuilt the identity and pipeline tooling against the government endpoints, verified the service dependencies against the region catalog, and brought the workloads online ahead of the assessment date. In both cases the work was the scoping and the re-architecture, not a copy.
It is the same discipline behind 600+ Microsoft platform implementations delivered over nearly 30 years as a Microsoft Solutions Partner since 1997. Defense and aerospace organizations have relied on i3 for senior, United States based delivery on engagements where the cost of failure is measured in audits and operations. For a contractor facing an Azure Government migration, that record is the point: the firm has scoped and rebuilt Azure workloads inside compliance boundaries long enough to know where these projects break, and how to keep yours from being one of them.
Ready to scope your workloads and plan the move with confidence? Schedule an Azure Government migration advisory discussion with an i3solutions principal.
About i3solutions
i3solutions is a Microsoft Solutions Partner since 1997 that has delivered 600+ Microsoft platform implementations across nearly 30 years for regulated enterprises in aerospace and defense, financial services, and healthcare. Our Enterprise Delivery Assurance model exists to make one promise dependable: complex Microsoft work lands on-time, in-scope, and in-production, with the compliance evidence intact. Defense and aerospace organizations have relied on i3 for senior, United States based delivery on engagements where the cost of failure is measured in audits and operations, not license fees. For buyers facing an Azure Government migration, that is the borrowed expertise we bring: the judgment to scope the workloads correctly and get the irreversible choices right the first time.
