Secure cloud migration checklist: inventory to cutover

A cloud migration is a change to operations as well as infrastructure. Moving an application before understanding its data, dependencies, and recovery needs can reproduce old risks in a new environment.

Inventory before scheduling

List applications, owners, environments, databases, integrations, secrets, traffic patterns, and data classifications. Identify which workloads must move together and which can remain where they are. Record licensing and contractual constraints.

Establish a secure landing zone

Set up identity and access roles, network boundaries, encryption, logging, backup, and cost visibility before the first production workload. Use infrastructure as code where practical so environments can be reviewed and reproduced. Apply least privilege and avoid storing credentials in source code or deployment artifacts.

Migrate in controlled waves

Choose an initial workload with manageable dependencies. Define data synchronization, cutover criteria, rollback triggers, and the person who approves the switch. Rehearse restore and failover, not just deployment. Test critical customer paths, integrations, performance, and access controls in the target environment.

Operate after cutover

Monitor errors, latency, security events, backup health, and spend. Retire old access and infrastructure only after data and recovery checks pass. Update incident runbooks and ownership records.

Cloud providers describe responsibility as shared between the provider and the customer; the split varies by service. Review your chosen provider's official shared-responsibility documentation when assigning controls. A successful migration is one the team can support, secure, and recover after the launch window closes.

Example: moving a customer portal

A portal may depend on a database, email provider, identity service, payment system, and scheduled jobs. Moving the web server alone can break the journey. Build a dependency map showing data flows, network access, latency assumptions, and who owns each integration. Decide whether to migrate data ahead of cutover and how changes made during the transition will be reconciled.

Pre-cutover decision checklist

• Have backups been restored successfully in a test environment?
• Are least-privilege access roles and secrets rotation in place?
• Can the team observe errors, latency, jobs, and security events?
• Are critical user journeys and integrations tested in the target?
• Is there a defined point at which the team rolls back?
• Who has authority to approve the cutover and communicate incidents?

After migration

Compare actual cost and performance with the plan. Check data completeness, backup schedules, alerting, and access lists. Remove temporary accounts and shut down old infrastructure only after the recovery path is verified. Migration is complete when the new environment can be operated and recovered confidently, not when the first page loads.

Choose the right migration move

Not every workload needs a rebuild. A lift-and-shift move can change the hosting environment quickly but may retain operational inefficiencies. Replatforming can take advantage of managed databases or deployment services while keeping most application behavior. Re-architecting may be justified when the existing system cannot meet reliability or scalability needs, but it carries more change risk. Compare options against business outcomes, team skills, compliance needs, timeline, and total operating cost.

Shared responsibility is specific

A cloud provider secures parts of the underlying service, while the customer remains responsible for data, identities, application behavior, and many configuration choices. The exact split depends on the service. Review the provider's official model; AWS documents this division for its services. Assign a named owner to each control so the phrase “the cloud handles it” cannot become a gap.

Rehearse an adverse cutover

Practice a failed deployment, unavailable dependency, and incomplete data synchronization before production. Verify that the team can restore from backup within the required time and explain which transactions must be replayed. Choose a cutover window based on business activity, not convenience alone. Prepare a communication plan for users and support teams.

Measure the new operating state

After migration, compare error rate, latency, recovery time, deployment frequency, and actual spend with the baseline. Review permissions and temporary exceptions created during the move. A migration should leave a documented, supportable environment with clear runbooks and a tested recovery path. If it only changes the hosting address, the business may have taken risk without gaining much value.