Azure Migration Readiness Checklist

A migration is a change to responsibility, dependencies, and recovery, not merely a new hosting address. Inventory the application, data, users, integrations, and current failure behavior before selecting an Azure service or a cutover date.

Map dependencies

Record inbound traffic, identity providers, databases, file shares, scheduled jobs, outbound connections, and third-party services. A server diagram alone often misses operational handoffs.

Define recovery

Agree on acceptable data loss and downtime for the actual business task. Test backup and restore in the target environment before relying on a theoretical recovery plan.

Prepare the team

Assign deployment, monitoring, incident, access, cost, and vendor responsibilities. The new platform should make those obligations clearer, not leave them to whoever has a console login.

Inventory the parts users do not see

Trace a representative business task from login through application, database, file exchange, scheduled job, external service, and support alert. Record owners and credentials as managed dependencies without copying secrets into the plan. Note network allowlists, identity assumptions, storage growth, and data residency needs. Choose a pilot whose connections can be exercised and rolled back. A server that starts in Azure is only the first check; the migration is ready when the complete task works, fails visibly, and can be recovered by the team that will operate it.

A dependency ledger should connect each business task to its hidden services. For every application, list identity, database, file store, outbound integration, scheduled work, certificate, DNS entry, network rule, owner, and recovery expectation. Mark which dependencies the pilot will exercise and which remain unproved. Attach the test result and date rather than a generic green status. When the cutover meeting arrives, the team can see whether the remaining unknowns are acceptable and who owns them. The same ledger can later become the operating runbook, so it should describe what a responder can actually check.

Write cutover and recovery criteria

Define acceptable outage and data loss with the business owner, then test backup restoration in the destination. Decide when writes stop in the old system, how final data is reconciled, who confirms user-facing behavior, and what condition triggers rollback. Include cost alerts and ownership for monitoring, patching, access, and incident response. A cutover checklist should contain evidence, not only tasks marked complete: restore duration, successful login, transaction count, dependency checks, and operator sign-off. Keep the old environment available for the agreed rollback window and retire it deliberately after reconciliation.

Decision checklist

• Inventory apps, data, identities, and integrations.
• Choose a pilot with a clear rollback route.
• Model cost from expected usage and data movement.
• Test restore and user-facing acceptance before cutover.

A small test before committing

Move a low-risk but representative workload to a test environment and perform one full restore, one credential rotation, and one simulated dependency failure. Compare the user journey and operational alerts with the current system. Write the cutover and rollback decision in advance, including who has authority to invoke it. A successful deployment is only one milestone; the pilot should show that the team can operate and recover the service after the migration.

Worked scenario

A hypothetical reporting app might be easy to host in Azure but still depend on an office file share and a nightly export. The pilot must prove those connections and failure alerts before the team calls the migration complete.

For a scoped application of this decision, see Azure Cloud Platforms.