Cloud Migration Checklist: Seven Gates Before Production Cutover

Cloud & Infrastructure

Updated July 12, 2026

By Jerame Trunnell Owner of Cloud Core MSP

A cloud migration should not reach production because every task in a project board is marked complete. It should proceed because named owners have evidence that the workload, users, data, controls, support process, and rollback path are ready. This checklist turns that evidence into seven go, conditional-go, or stop gates.

This is a cross-industry migration control sheet, not a decision that every workload belongs in the cloud and not a substitute for application-specific engineering. First decide whether to retain, retire, replace, rehost, replatform, or refactor each workload. NIST's Cloud Computing Synopsis and Recommendations remains useful for framing cloud opportunities and risks, while current provider tools supply platform-specific assessment details.

Create one workload record before planning the move

Give each application or service a record with a business owner, technical owner, support owner, critical workflows, user groups, data types, current hosting, target service, expected migration method, and disposition of the old environment. A server inventory is not enough. The application may depend on identity, DNS, certificates, database links, file shares, devices, vendor allowlists, scheduled jobs, email relays, reporting tools, or an integration nobody sees on the server itself.

Use discovery data to challenge assumptions. Azure Migrate, for example, can assess readiness, sizing, and estimated Azure resource cost for supported workload types, as described in Microsoft's assessment overview. That output is specific to Azure and the assessment settings selected; it does not prove business workflow readiness or establish a final bill.

Gate 1: outcome and scope are approved

State the reason for moving in observable terms: retire unsupported infrastructure, enable a required capability, improve recoverability, support a location change, or reduce an identified operating burden. List what is explicitly in and out of scope. Document who can change scope and who accepts residual risk. If the team cannot state the outcome, moving the same complexity to a different platform is not progress.

Gate 2: dependencies and data are mapped

Trace at least one normal transaction and one exception from the user's first action to every downstream service. Inventory data volume, change rate, permissions, retention, backup, encryption, and transfer method. Microsoft advises migration teams to inventory data sources, application dependencies, performance, resilience, security, and recovery needs in its storage migration assessment guidance. Apply the method to the actual platform and dataset rather than assuming every Microsoft control fits another provider.

Gate 3: identity, security, and administration work in the target

Test workforce sign-in, multifactor authentication, service identities, privileged roles, emergency access, joiner/mover/leaver behavior, logging, and vendor access. Record whether source and target identities coexist during transition and how privileges are removed afterward. CISA's federal Cloud Security Technical Reference Architecture is written for agencies, but its attention to identity, asset management, network security, application security, data protection, and visibility is a useful question set for other organizations. It is guidance, not a claim that a private organization has federal obligations.

Gate 4: the target is supportable

Confirm monitoring, alert routing, backup jobs, restoration steps, patching or platform update responsibility, capacity signals, license ownership, escalation paths, and after-hours coverage. The support team needs appropriate access before the cutover, not after the first incident. Record shared-responsibility boundaries between the organization, its provider, software vendors, and the cloud platform.

Gate 5: users and workflows pass acceptance

Test the workflows people actually perform, including printing, scanning, reporting, exports, mobile use, remote access, accessibility needs, and integrations. Use representative test accounts and sanitized or controlled test data. Capture pass criteria before testing. A successful login does not demonstrate that month-end processing, clinical intake, dispatch, or another critical workflow operates correctly.

Gate 6: cutover and rollback are executable

Write the cutover in command order with owners, communication points, verification steps, stop conditions, and the latest safe rollback time. Microsoft's current migration execution guidance calls for stakeholder readiness, support availability, verification procedures, rollback criteria, controlled changes, data validation, and post-cutover monitoring. Google Cloud likewise recommends a tested rollback strategy for each migration step in its migration-plan validation guidance. These are provider-specific guides; use the applicable commands and services for your target.

Gate 7: recovery and source retirement are approved separately

Restore protected data into a controlled location and verify that the application can use it. Confirm the recovery point, recovery sequence, credentials, network dependencies, and owner. Do not decommission the source merely because traffic moved. Define a stabilization period, preservation needs, license changes, data-destruction approval, and the evidence required for retirement. Recovery, rollback, and source retirement are related but different decisions.

Migration gate checklist

Use one row per workload-and-gate, preserving the seven-gate sequence below for every workload. Duplicate the seven rows for each workload and replace every bracketed field. A conditional go needs a named owner, due date, evidence reference, written acceptance, and acceptance date; it should not become a vague substitute for a failed gate.

Workload	Gate	Owner	Condition / status	Due date	Evidence reference	Acceptance / decision	Acceptance date
[Workload name]	1. Outcome and scope	[Executive or service owner]	[Pass / conditional go / stop; stop if there is no business owner or clear reason to move]	[Date or N/A]	[Approved workload record, target outcome, exclusions, and risk record]	[Go / conditional go / stop, with rationale]	[Date]
[Workload name]	2. Dependencies and data	[Application and data owners]	[Pass / conditional go / stop; stop for an unknown critical integration or unapproved data treatment]	[Date or N/A]	[Validated dependency map, data inventory, transfer and retention plan]	[Go / conditional go / stop, with rationale]	[Date]
[Workload name]	3. Identity and security	[Security or identity owner]	[Pass / conditional go / stop; stop for excess privilege, a failed authentication path, or missing audit evidence]	[Date or N/A]	[Test results for users, admins, service accounts, logs, and emergency access]	[Go / conditional go / stop, with rationale]	[Date]
[Workload name]	4. Operability	[Operations owner]	[Pass / conditional go / stop; stop when a production operating responsibility has no owner]	[Date or N/A]	[Monitoring, backup, update, licensing, support, and escalation records]	[Go / conditional go / stop, with rationale]	[Date]
[Workload name]	5. User acceptance	[Business process owner]	[Pass / conditional go / stop; stop if a critical workflow fails or lacks an approved workaround]	[Date or N/A]	[Signed results for critical and exception workflows]	[Go / conditional go / stop, with rationale]	[Date]
[Workload name]	6. Cutover and rollback	[Change authority]	[Pass / conditional go / stop; stop if rollback cannot complete within the approved interruption window]	[Date or N/A]	[Rehearsed runbook, contacts, validation, timing, and stop criteria]	[Go / conditional go / stop, with rationale]	[Date]
[Workload name]	7. Recovery and retirement	[Service, data, and risk owners]	[Pass / conditional go / stop; stop if restoration is unproven or preservation requirements remain unresolved]	[Date or N/A]	[Restore evidence, stabilization plan, and separate source-retirement approval]	[Go / conditional go / stop, with rationale]	[Date]

Run the final go/no-go meeting from evidence

Schedule the meeting before the change window. Each gate owner reports pass, conditional go, or stop and points to evidence. The change authority records the decision, open conditions, communications, and rollback trigger. Optimism, sunk project cost, or a vendor's availability should not override a failed stop condition.

After cutover, compare target behavior with the recorded baseline: critical transactions, authentication, integrations, data integrity, alerts, backup, response time where relevant, and user support volume. Keep the old environment protected until the approved retirement criteria are met. Then remove temporary identities, firewall paths, synchronization jobs, and duplicated licenses through a controlled change.

Choose the more specific planning guide when needed

If placement itself is unresolved, begin with the on-premise versus cloud decision guide. Healthcare practices working with clinical workflows and ePHI need the additional questions in the healthcare hybrid-cloud readiness guide. Before approving recovery evidence, make sure leaders understand the distinction in cloud backup versus disaster recovery.

Primary sources

Suggested next step

Book a discovery call if you need help converting a migration project plan into workload-level evidence and cutover gates.