Cloud migration checklist: 15 steps to a smooth transition
A cloud migration checklist turns a complex move to AWS, Azure or Google Cloud into a sequence you can actually execute, from workload assessment to post-migration optimization. This guide organizes the process into 15 practical steps across 5 phases, covering the dependencies, rollback controls and governance enterprise migrations need.
What should you assess before starting a cloud migration?
A cloud migration should start with business outcomes, a complete view of the current environment and a migration strategy for each workload, before production infrastructure begins to move.
The temptation is to begin with technology: choose a provider, create accounts and start copying workloads.
Current migration guidance from AWS, Microsoft and Google points in the opposite direction. Portfolio discovery, business alignment, workload assessment and dependency identification come before migration-wave planning and production execution.
Step 1: Define your migration goals and business case
A cloud migration is easier to control when the reason for moving is explicit.
Start by defining which outcomes justify the project. Typical drivers include:
- reducing infrastructure or operational cost;
- improving scalability or availability;
- leaving an expiring data center or hardware platform;
- addressing end-of-support software;
- accelerating product delivery;
- creating access to managed cloud services;
- consolidating infrastructure after an acquisition or organizational change.
Your migration strategy should connect directly to business and technical drivers rather than selecting a migration path in isolation.
Define measurable success criteria before moving workloads. Depending on the project, these might include availability, latency, recovery objectives, operating cost, deployment frequency, infrastructure-management effort or a fixed data-center exit date.
This is also the point to decide who will operate the cloud after migration. The difference between running cloud infrastructure yourself and outsourcing it affects staffing, operating responsibilities and the economics of the target model.
A migration without a clear business case can still move workloads successfully.
It just becomes much harder to know whether the migration itself was successful.
Step 2: Audit your application portfolio and infrastructure
You cannot create a reliable migration plan from an incomplete inventory.
Build a current catalog of:
- applications and services;
- servers and virtual machines;
- databases and data stores;
- storage volumes;
- networks and connectivity;
- external integrations;
- identities and service accounts;
- scheduled jobs and background processes;
- licensing dependencies;
- current performance and capacity.
At this stage, keep dependency discovery at portfolio level. Identify the major relationships among applications, platforms, databases, shared services and business processes well enough to group the estate, surface obvious blockers and identify which workloads need deeper assessment.
Capture baseline performance too.
If you do not know current response times, utilization, throughput, error rates and availability, you will have nothing objective to compare against after migration.
An infrastructure audit should also identify workloads that should not move.
Some systems may be obsolete. Others may be constrained by latency, hardware dependencies, regulation or unsupported software.
The goal is not to migrate everything.
It is to understand everything before deciding what should move.
Step 3: Choose your migration strategy – the 7 R’s
AWS documentation currently uses both six- and seven-strategy variants, depending on the migration framework and context. In this guide, we follow the seven-strategy model used in the AWS Large Migration Guide, which treats Relocate as a separate migration path:
- Rehost – move the workload largely as-is, often called lift-and-shift.
- Relocate – move infrastructure to a cloud environment with minimal application-level change, such as certain VMware relocation scenarios.
- Replatform – make limited changes to use managed cloud capabilities without fundamentally redesigning the application.
- Repurchase – replace the existing system with another product, often SaaS.
- Refactor or re-architect – substantially redesign the application to use cloud-native capabilities.
- Retain – keep the workload in its current environment for now.
- Retire – decommission an application that no longer creates enough value to justify keeping it.
Why does some current AWS guidance still use 6 R’s?
AWS documentation uses both variants. Some current AWS portfolio-assessment guidance uses a 6-R decision tree covering rehost, replatform, refactor or re-architect, repurchase, retain and retire. The AWS Large Migration Guide uses 7 R’s, adding Relocate as a distinct strategy.
Neither variant needs to be treated as universally outdated. They are used in different AWS guidance contexts. For this article, we use the 7-R version from the AWS Large Migration Guide because it makes Relocate explicit.
Do not choose one R for the entire organization.
A large migration portfolio normally contains several.
You may rehost a stable legacy application, replatform its database, replace an old collaboration system with SaaS, retain a latency-sensitive workload and retire unused software in the same program.
If AWS is part of the target estate, our enterprise cloud migration strategy framework provides additional context around workload decisions, sequencing, architecture and post-migration governance.
How do you choose the right cloud provider and architecture?
Provider selection should follow workload requirements, operating constraints and target architecture, because AWS, Azure, GCP, hybrid and multi-cloud choices affect much more than where virtual machines run.
Architecture, identity, governance and connectivity should be resolved before production cutover rather than after workloads have already moved.
Step 4: Select a single-cloud, multi-cloud or hybrid approach
Do not start with “Which cloud is best?”
Start with “What does this workload require?”
Assess:
- existing technology and licensing;
- staff expertise;
- regulatory or data-location constraints;
- managed services the workload needs;
- resilience requirements;
- integration with existing systems;
- expected data-transfer volumes;
- commercial commitments;
- portability requirements;
- the operational cost of supporting more than one platform.
A single-cloud strategy simplifies governance and operations, but increases dependence on one provider’s services and commercial model.
A multi-cloud strategy can provide access to different provider strengths or support organizational constraints, but introduces more complexity in identity, networking, tooling, skills and cost management.
A hybrid-cloud model keeps some infrastructure private or on-premises while using public cloud services for selected workloads.
Those terms should not be confused. How public, private, and hybrid cloud compare on cost and control is a separate workload-placement decision from choosing multiple public cloud providers.
The important point is not that one hyperscaler has the “correct” migration framework. It is that your internal process should remain consistent even when workloads land on different platforms.
Cloud migration also sits inside a broader engineering foundation that connects architecture, security, data, compliance and production operations. Webellian’s digital engineering services provide the wider context for those capabilities without tying the migration decision to one individual cloud platform.
If the target estate spans more than one provider, a deliberate multi-cloud strategy can help evaluate workload placement, governance, resilience and the complexity cost of operating across AWS, Azure and Google Cloud.
Step 5: Design your target cloud architecture
A cloud migration should not reproduce the current environment accidentally.
Define the target architecture before large-scale workload movement begins.
At minimum, design:
- network topology and connectivity;
- compute and runtime platforms;
- storage architecture;
- database services;
- identity architecture;
- DNS and name resolution;
- observability;
- backup;
- high availability;
- disaster recovery;
- secrets and key management;
- infrastructure provisioning.
Treat Infrastructure as Code as part of the architecture, not a cleanup task after migration.
A repeatable environment makes testing easier, reduces configuration drift and gives teams a more reliable rebuild path.
Architecture decisions should also be evaluated across reliability, security, performance, operations and cost rather than optimized for one dimension in isolation.
That is the purpose of a broader framework for designing secure, reliable cloud architecture.
Do not assume that a workload which runs correctly in the source environment will behave identically in the target cloud.
Network latency changes. Storage characteristics change. Autoscaling may change concurrency. Managed database behavior may differ. Authentication paths may change.
Design for the destination rather than simply reproducing the source.
Step 6: Build your security, compliance and governance framework
Security should be designed into the target environment before workloads arrive.
Identity, least privilege, segmentation, data protection and governance should operate throughout the cloud lifecycle rather than being treated as a final pre-production check.
Your cloud migration checklist should cover:
- IAM roles and least-privilege access;
- privileged-access controls;
- service and workload identities;
- encryption at rest and in transit;
- key ownership and rotation;
- logging and audit trails;
- network segmentation;
- security monitoring;
- data classification;
- retention requirements;
- incident-response ownership;
- backup responsibilities;
- policy enforcement;
- regulatory and contractual obligations.
Compliance cannot be reduced to the fact that a cloud provider holds a certification.
Your organization remains responsible for how data, access and workloads are configured.
Map requirements such as GDPR, PCI DSS, HIPAA or sector-specific obligations to actual controls and responsible owners before cutover.
For a deeper treatment of the responsibility model, IAM, migration-window exposure and configuration risk, see the security risks and best practices unique to cloud migration.
How do you plan data and application migration?
Application and data migration becomes manageable when initial portfolio discovery is followed by workload-level dependency validation, data transfer is treated as its own workstream and workloads are grouped into migration waves with named owners and acceptance criteria.
Current cloud migration frameworks place dependency analysis and workload sequencing before large-scale execution for a reason: applications rarely move independently.
Step 7: Validate workload dependencies and migration readiness
Step 7 moves from the portfolio-level discovery in Step 2 to workload-level validation. Before assigning an application to a migration wave, verify its technical and business dependencies in enough detail to determine whether it is genuinely ready to move.
An application is rarely one deployable object.
It may depend on:
- databases;
- internal APIs;
- external SaaS;
- authentication systems;
- message queues;
- file shares;
- DNS;
- scheduled jobs;
- partner systems;
- firewall rules;
- legacy middleware.
Map both technical and business dependencies.
A system may be technically independent but still need to migrate in the same wave as another application because the same users or business process depend on both.
Classify readiness for every workload:
- ready to migrate;
- requires remediation;
- requires modernization;
- blocked by another dependency;
- retained for now;
- candidate for retirement.
Where legacy systems rely on tightly coupled integrations, clearer API ownership and governed API boundaries can help isolate consumers from underlying implementation changes and reduce coupling during migration.
Step 8: Build a data migration plan
Data migration requires its own plan because application cutover and data movement often operate on different timelines.
Define:
- which datasets move;
- which datasets remain;
- how much data must transfer;
- how data will be cleaned or standardized;
- how initial bulk transfer will work;
- whether continuous replication is required;
- how long synchronization can run;
- acceptable replication lag;
- how integrity will be validated;
- how data will be backed up before migration;
- how long the source remains available.
The transfer method should reflect data volume and downtime tolerance.
A small internal database can be treated very differently from a multi-terabyte transactional system that must remain available during migration.
For near-zero-downtime scenarios, continuous replication may be necessary. Data integrity should also be validated with checksums or equivalent methods rather than relying only on row counts.
Do not declare data migration complete merely because the transfer job returned “success.”
Validate that the target data is complete, current and usable by the migrated application.
Step 9: Create a migration roadmap with owners and milestones
Turn the inventory into migration waves.
A wave should group workloads that make sense to move together based on:
- dependencies;
- business criticality;
- technical complexity;
- migration strategy;
- risk;
- team availability;
- acceptable downtime.
For each wave, identify:
- migration owner;
- application owner;
- security owner;
- business approver;
- start and target dates;
- testing window;
- cutover window;
- go/no-go criteria;
- rollback owner;
- hypercare period.
Do not schedule the hardest system first.
An early migration wave should create learning without creating unacceptable business risk.
The objective is not simply to move small workloads quickly. It is to validate the process before it carries more critical systems.
This is where the agile practices that keep migration teams aligned become useful. Communication, collaboration, commitment and continuous improvement need to operate across the migration program, not only inside engineering.
How do you execute and test the migration safely?
Safe execution depends on proving recovery before cutover, defining objective rollback criteria and testing the migrated workload against functional, data, performance, integration and security expectations.
Migration night is the wrong time to discover that the backup exists but cannot be restored.
Step 10: Set up a backup and disaster recovery plan
Backups and disaster recovery solve related but different problems.
A backup protects recoverable data.
A disaster-recovery plan defines how the workload resumes service when a serious failure occurs.
Set explicit:
- RPO – Recovery Point Objective: how much data loss is acceptable;
- RTO – Recovery Time Objective: how long the service can remain unavailable.
Then test whether the technical design can actually meet those objectives.
Do not stop at checking that backup jobs are green.
Before cutover:
- create or verify a recoverable backup;
- test restoration;
- confirm permissions to perform recovery;
- document the recovery sequence;
- verify replication health where applicable;
- assign recovery ownership;
- confirm monitoring and alerting work.
A backup that has never been restored is evidence of a backup process, not evidence of recoverability.
Step 11: Execute the cutover with a rollback plan
A cutover should have a defined decision point where the team either proceeds or returns to the known-good environment.
Before the migration window opens, document:
- go/no-go criteria;
- acceptable replication lag;
- DNS and traffic-routing changes;
- data freeze requirements;
- expected downtime;
- key contacts;
- validation sequence;
- rollback triggers;
- rollback procedure;
- maximum time allowed before rollback becomes the safer decision.
Rollback criteria and procedures should exist before migration starts.
Do not treat rollback as failure.
Rollback is a control.
If the migration violates pre-agreed thresholds for data integrity, availability, performance or critical business functionality, returning traffic to the stable environment may be the correct outcome.
Keeping the source environment available is only one part of a rollback strategy. For stateful workloads, once the target starts accepting new writes, the source can quickly become stale. A safe rollback may require reverse replication, data reconciliation, dual writes or another tested method of bringing post-cutover data back to the source. Define in advance when rollback remains safe and when fixing forward becomes the lower-risk option.
Step 12: Test and validate every migrated workload
Testing should prove that the application still works as a system, not simply that the server is running.
A cloud migration testing checklist should include:
- functional testing – critical business journeys still work;
- integration testing – APIs, queues, external services and background jobs connect correctly;
- data validation – migrated data is complete and accurate;
- performance testing – latency, throughput and resource behavior meet expectations;
- security testing – identity, authorization, network policy and logging function correctly;
- resilience testing – failover, backup and recovery behave as designed;
- observability testing – metrics, logs, traces and alerts are arriving correctly.
Compare results against the baseline captured before migration.
“Feels faster” is not a migration KPI.
A migrated workload should meet defined service expectations and have clear evidence that its critical paths operate correctly.
How do you optimize and govern the cloud environment after migration?
Migration is not finished at cutover: monitoring, cost optimization, operational ownership and continuous improvement determine whether the new environment actually delivers the business case that justified moving.
A workload that runs successfully after cutover may still be oversized, poorly monitored or more expensive than expected.
Step 13: Set up monitoring and track cloud KPIs
Monitoring should answer two questions:
Is the workload healthy?
And is the migration producing the outcomes you expected?
Track technical indicators such as:
- response time and latency;
- error rate;
- throughput;
- saturation and resource utilization;
- availability;
- backup success;
- replication lag where relevant;
- security events.
Also track migration and business indicators:
- cost per workload or service;
- migration-wave progress;
- incident rate;
- recovery performance;
- cloud consumption against forecast;
- whether baseline SLAs or SLOs are being met.
After migration, validate that logs and metrics are complete, alerts trigger correctly and dashboards reflect the new architecture.
Avoid creating dozens of dashboards nobody uses.
Each KPI should support an operational or business decision.
If a metric changes and nobody knows what action to take, it is probably not yet a useful KPI.
Step 14: Optimize cost and performance post-migration
Do not assume the initial migration configuration is the final configuration.
A workload moved conservatively may be intentionally oversized during cutover. Autoscaling behavior may need tuning. Managed-service settings may need adjustment after real traffic arrives.
Post-migration optimization should look for:
- over-provisioned compute;
- underused resources;
- idle storage and environments;
- unnecessary data transfer;
- inefficient autoscaling;
- poor storage tiers;
- licensing waste;
- opportunities to replatform or modernize;
- opportunities for commitment-based discounts once usage stabilizes.
Current FinOps practices distinguish between usage optimization and rate optimization.
Usage optimization means matching resources to actual workload requirements through measures such as right-sizing, eliminating idle capacity or changing service configuration.
Rate optimization means reducing the price paid for appropriate usage through mechanisms such as AWS Savings Plans and Reserved Instances, Azure Reservations or Google Cloud committed-use discounts.
Usage and rate optimization are closely related and can happen in parallel. Before locking in long-term commitments, establish a reliable usage baseline and understand whether planned right-sizing, replatforming or modernization could materially change the resource profile. Where demand is sufficiently predictable, organizations can optimize rates at the same time while continuously checking that commitments still match realized usage.
Long-term discounts should therefore be based on evidence about expected demand, not treated as a substitute for workload efficiency.
Cost optimization should also remain connected to performance and reliability.
The cheapest architecture is not successful if it breaks the service-level objective that justified the migration.
Step 15: Train your team and build a continuous improvement loop
The operating model changes after migration.
Infrastructure teams may need to learn Infrastructure as Code, cloud IAM, provider-specific networking, cost management and managed-service operations.
Application teams may inherit more responsibility for observability or service configuration.
Security teams may need new telemetry and policy automation.
Finance and procurement may need to understand consumption-based cost models and commitment discounts.
Create a structured post-migration review after each major wave:
- What assumptions proved wrong?
- Which dependencies were missed?
- Which tests caught real problems?
- Which alerts were useful?
- Where did the cutover take longer than planned?
- Which cost assumptions changed?
- What should be different in the next wave?
Migration plans should evolve as teams discover workload-specific information and learn from previous waves.
Continuous improvement is not a phase you “complete.”
It is how a migration program gets safer and more predictable as it scales.
FAQ
What are the 7 steps of a typical cloud migration model?
There is no universal industry-standard seven-step model.
A practical seven-stage summary is:
- define business objectives;
- discover and assess workloads;
- choose migration strategies and target architecture;
- prepare security, governance and the cloud foundation;
- plan migration waves and data movement;
- execute, cut over and validate;
- optimize, govern and decommission the source environment.
Different cloud providers package these activities differently. The important point is that assessment and planning come before execution, while optimization continues after cutover.
What are the 6 R’s or 7 R’s of cloud migration?
AWS currently uses both 6-R and 7-R variants in different migration guidance.
The AWS Large Migration Guide uses 7 R’s:
- rehost;
- relocate;
- replatform;
- repurchase;
- refactor or re-architect;
- retain;
- retire.
Other current AWS Prescriptive Guidance, including its application portfolio assessment guidance, still uses a 6-R decision tree without Relocate as a separate category.
This article follows the 7-R model from the AWS Large Migration Guide, where Relocate is explicitly treated as its own migration strategy.
What should a cloud migration testing checklist include?
At minimum, test:
- core business functionality;
- integrations and background processes;
- data completeness and integrity;
- performance against the pre-migration baseline;
- identity and security controls;
- backup and restore;
- failover and disaster recovery;
- monitoring, logs and alerts;
- rollback procedures.
Testing should happen before production cutover where possible and continue immediately after traffic is redirected.
What are the best cloud migration tools?
There is no single best tool because discovery, server migration, database migration, orchestration and validation are different jobs.
For AWS, AWS Transform provides an agentic migration workflow, while AWS Transform MGN is the current name of the rehosting service formerly known as AWS Application Migration Service. AWS Database Migration Service (AWS DMS) supports database migration and replication.
For Azure, Azure Migrate supports discovery and assessment, while additional Microsoft services support workload-specific migration tasks.
For Google Cloud, Migration Center supports discovery, assessment and planning, with services such as Migrate to Virtual Machines and Database Migration Service handling specific workload types.
Choose tools based on the workload and migration stage rather than trying to standardize every task on one product.
What are the five phases of cloud migration?
There is no single provider-neutral five-phase standard.
A practical five-phase structure is:
- Assess
- Design
- Plan
- Execute and validate
- Optimize and govern
Different cloud providers organize their frameworks differently.
The five sections in this checklist are an editorial structure for the 15 practical steps, not a claim that every cloud provider uses the same lifecycle model.
Sources
https://aws.amazon.com/about-aws/whats-new/2026/06/aws-transform-mgn-rebrand
https://learn.microsoft.com/en-us/azure/migration/migrate-to-azure
https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/migrate/plan-migration
https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/migrate/migration-wave-planning
https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/secure/security-top-10
https://docs.cloud.google.com/docs/migration
https://docs.cloud.google.com/migration-center/docs/migration-planning-overview
https://docs.cloud.google.com/migration-center/docs/plan-migration-waves
https://docs.cloud.google.com/migration-center/docs/migration-risks
https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/security.html
https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/data-protection.html