Azure Government cloud migration checklist

1. Confirm eligibility, requirements, and ownership

• Confirm access eligibility with the provider and identify the target tenant, subscriptions, and regions.
• Document data classification, system boundary, applicable security requirements, and authorization dependencies.
• Name the owners of identity, network connectivity, data, application operations, and cutover approval.
• Agree on recovery objectives, allowed outage, and conditions that require rollback.

Government cloud selection is not a compliance determination. Requirements depend on the workload and program, including any applicable DoD impact-level requirements. Validate the proposed services and operating model with the responsible reviewers.

2. Inventory dependencies and service compatibility

List application runtimes, databases, storage, third-party APIs, certificate services, build runners, container registries, package repositories, and telemetry destinations. Check each service's availability and feature support in the actual target region. Confirm endpoints and identity integration against current documentation.

Include dependencies used only during failure or maintenance: restore locations, licensing checks, incident tooling, and administrative access. A workload that starts successfully may still fail when it needs a backup restore or token refresh.

Use the Microsoft Azure Government documentation as the starting point for current environment differences. Record the assumptions you verify, rather than copying a commercial Azure reference architecture unchanged.

3. Validate identity and network paths

• Test user and workload authentication in the target environment, including privileged and emergency access.
• Confirm DNS, private connectivity, firewall rules, egress restrictions, and certificate trust.
• Verify that deployment runners can reach approved cloud APIs and artifact sources.
• Test access from the real consuming networks, including hybrid dependencies.

Document the approved endpoints and identity configuration for each environment. Do not hardcode commercial-cloud assumptions into scripts. Separate credentials from infrastructure code and grant deployment identities only the permissions their operations require.

4. Rehearse infrastructure and platform delivery

Use reviewed Terraform modules with pinned provider versions, an appropriate backend, state access controls, and locking. Validate provider configuration for the target cloud. Deploy a representative environment and verify logs, key management, network segmentation, and required configuration checks.

If Kubernetes is part of the architecture, test image pulls, workload identity, network policy, ingress, telemetry, and upgrades in the selected platform. A healthy cluster alone does not demonstrate that the application works or that its security requirements are implemented.

Run a representative build and deployment through the intended pipeline. Include a controlled failure to verify that gates block unsafe promotion and that evidence is retained.

5. Exercise data migration and recovery

• Measure transfer duration using representative data and approved routes.
• Define how writes are paused, synchronized, or reconciled during transition.
• Check record counts, integrity, application-level consistency, and access permissions.
• Restore a backup into the target environment and exercise the recovery procedure.
• Define how post-cutover writes will be handled if rollback is needed.

A rollback plan that ignores new writes can lose or fork data. Agree on the recovery point and the reconciliation process before the migration window. Handle test data and generated evidence according to their sensitivity.

6. Use explicit cutover acceptance criteria

Before approving cutover, record the expected application behavior, latency and error thresholds, alert delivery, data checks, and operational coverage. Rehearse the runbook with the people who will execute it. Record who can make the go/no-go decision and how that decision is communicated.

During cutover, verify representative user transactions rather than relying only on open ports or healthy infrastructure. Confirm scheduled jobs, integrations, authentication renewal, and incident notifications as well as the main request path.

7. Complete handover and review authorization dependencies

Deliver architecture records, infrastructure definitions, runbooks, evidence, access procedures, and escalation contacts to the operating team. Review cost and capacity after migration. Retire source resources only after retention, recovery, and program requirements permit it.

Update the relevant assessment documentation and obtain required approvals through the program's process. For supporting evidence workflows, see FedRAMP compliance automation workflows. For delivery support, explore government cloud engineering.