AWS Migration Checklist
AWS partner dedicated to startups
- 2000+ Clients
- 5+ Years of Experience
- $10M+ saved on AWS
An AWS migration can improve scalability, resilience, and access to cloud-native services, but success depends on what happens before the first workload is transferred. A rushed migration can create downtime, unexpected cloud costs, broken dependencies, or security gaps.
This AWS migration checklist covers the full migration process, from pre-migration planning and assessment to migration execution, user acceptance testing, cutover, and post-migration optimization. At Cloudvisor, we use this same structured approach: assess the current environment, plan migration waves, test, synchronize data, cut over during quieter periods, and optimize the AWS setup after launch.
How to use this AWS cloud migration checklist
Treat the checklist as a framework rather than a one-size-fits-all sequence. Larger estates with legacy applications, sensitive data, compliance requirements, or many dependencies need more detailed planning.
AWS structures migration programs around Assess, Mobilize, and Migrate & Modernize. The important part is to establish clear migration goals, understand the current IT environment, prepare the AWS environment, and validate workloads before production cutover.
- Define business and technical migration goals
- Inventory applications, databases, servers, and dependencies
- Select a migration strategy for each workload
- Prepare AWS accounts, networking, identity, security, and logging
- Choose the right AWS migration tools
- Run a pilot migration
- Test data, applications, and rollback procedures
- Execute and validate cutover
- Monitor, optimize, and document the new environment
1. Define migration goals, scope, and success metrics
Start by defining why the business is moving to the AWS Cloud. Migration goals might include leaving data centers, improving business agility, reducing operational overhead, supporting growth, strengthening disaster recovery, or modernizing legacy applications.
Turn those goals into measurable success criteria. The migration team should agree on acceptable downtime, performance targets, cost expectations, recovery objectives, and workloads in scope.
Estimate costs during pre-migration planning. Compare current infrastructure costs with expected AWS usage, migration effort, licensing, connectivity, and temporary parallel environments. AWS’s migration methodology similarly starts with assessment and building the business case before migration at scale.
2. Assess your current infrastructure and dependencies
Inventory the current environment before migrating applications. Document servers, databases, storage, operating systems, network connections, owners, users, and compliance requirements.
Map application dependencies carefully. A service may rely on a database, identity platform, API, file share, DNS, or another system that is not obvious from the application itself.
Also identify which workloads should migrate, remain where they are, or be retired. AWS portfolio-assessment guidance treats discovery, analysis, and planning across applications and their compute, storage, and network infrastructure as a core part of migration assessment.
This risk assessment also helps determine migration waves. Applications with tightly connected dependencies can move together, while less critical workloads can become early pilot candidates.
3. Choose the right AWS migration strategy
AWS currently defines seven migration strategies, known as the 7 Rs: retire, retain, rehost, relocate, repurchase, replatform, and refactor or re-architect. The older “6 Rs” model is therefore no longer the current AWS list.
Rehosting, or lift and shift, is useful when speed and minimal application change are priorities. Replatforming introduces targeted improvements, such as moving a self-managed database to an AWS managed service. Refactoring makes deeper architectural changes to take advantage of cloud-native features.
Choose the strategy workload by workload. The right AWS migration strategy should reflect business goals, risk, technical complexity, cost efficiency, and how much modernization is realistic during the migration window.
4. Prepare a secure AWS environment before migration
Do not wait until cutover to design the AWS setup. Establish the account structure, networking, security groups, backups, monitoring, logging, and access management before production workloads arrive.
For larger cloud environments, consider a multi-account approach using AWS Organizations. AWS recommends multi-account strategies as environments grow because account boundaries can help with governance, security controls, cost management, and workload separation.
Define AWS Identity and Access Management permissions using least privilege and document access control for administrators, engineers, applications, and support teams. Encryption requirements for sensitive data at rest and in transit should also be defined before the actual migration.
AWS Config can evaluate AWS resource configurations against defined rules, while AWS Security Hub CSPM runs security checks and brings security findings together to help teams understand their security posture.
These AWS services support governance, but they do not automatically ensure compliance with GDPR, HIPAA, or other industry regulations. Your compliance requirements still need to be assessed for the specific workload and data.
5. Select migration tools for applications and data
Choose AWS tools based on the source environment, workload, acceptable downtime, data volume, and migration strategy.
Current AWS documentation calls its automated rehosting service AWS Transform MGN, which can be used to migrate physical, virtual, and cloud servers into AWS. Cloudvisor’s migration offering also refers to the familiar AWS Application Migration Service (MGN) name for lift-and-shift Windows and Linux migrations.
For data migration, AWS Database Migration Service, or AWS DMS, can support database migration and ongoing replication. At Cloudvisor, we use change data capture, test loads, data validation, and low-traffic cutover windows to help preserve data integrity and reduce downtime.
Other migration tools include AWS DataSync for file transfers and AWS Transform for migration planning and modernization. Cloudvisor selects the tools based on the customer’s stack and risk tolerance rather than applying one migration method to every environment.
6. Run a pilot migration and test the process
Before full migration execution, choose a representative workload for a pilot migration. Test more than whether the server starts in AWS.
Validate networking, identity, security groups, data replication, monitoring, backups, integrations, performance, deployment processes, and application functionality.
User acceptance testing should involve people who understand normal business use. Document go/no-go criteria before production.
Cloudvisor’s migration process uses pilots, workload testing, migration waves, and synchronized data before production cutovers.
7. Plan the production cutover and rollback
Create a cutover plan covering owners, timing, communications, final synchronization, validation, and rollback criteria. Use a lower-traffic window where possible.
For replicated workloads, confirm that replication is healthy and complete the final synchronization before redirecting end users. AWS Transform MGN supports test launches before workloads are marked ready for cutover, with acceptance testing recommended before the cutover is finalized.
For business-critical migrations, define rollback triggers and keep source systems usable until the move is accepted.
At Cloudvisor, we plan migration waves, keep data synchronized, test restores, rehearse cutover steps, and keep rollback plans available. This structured migration process is designed to reduce downtime and protect data integrity.
8. Validate the AWS environment after migration
After cutover, confirm application functionality, integrations, data integrity, user access, security controls, backups, and performance before decommissioning the original environment.
Amazon CloudWatch monitors AWS resources and applications in real time and can provide visibility into application performance, operational health, and resource utilization.
Review the migrated architecture against the AWS Well-Architected Framework. It currently has six pillars: operational excellence, security, reliability, performance efficiency, cost optimization, and sustainability.
Retire source infrastructure only after the new environment is formally accepted and the rollback period has passed.
9. Optimize costs and operations after migration
Cloud migration does not end at cutover. Actual AWS usage provides better information for rightsizing, performance tuning, auto scaling, storage optimization, and introducing cloud-native features.
Use AWS Cost Explorer and other optimization tools to understand spending and evaluate commitments once usage becomes predictable. AWS Savings Plans can provide savings of up to 72% on eligible compute workloads, while Standard Amazon EC2 Reserved Instances can also offer discounts of up to 72% compared with On-Demand pricing. These are maximum potential discounts, not guaranteed savings for every workload.
Improve continuous integration, infrastructure as code, monitoring, backups, and documentation after migration. The goal is to use cloud technology more effectively, not simply recreate the old environment.
At Cloudvisor, post-migration work can include rightsizing, cost controls, auto scaling, storage tuning, and ongoing AWS managed services where customers want additional operational support.
If you are preparing an AWS cloud migration, our AWS Solutions Architect can assess your current environment, outline the migration strategy, and provide a no-commitment Statement of Work. We also check whether your project qualifies for AWS migration funding.
Talk to our AWS migration experts and get a free migration assessment before you start moving workloads.
Frequently asked questions about the AWS migration checklist
1) What AWS tools should be included in a migration checklist?
The tools depend on the workload. AWS Transform MGN supports rehosting servers, while AWS Database Migration Service supports database migration and replication. AWS DataSync can support file transfers, and Amazon CloudWatch provides monitoring after migration.
AWS Migration Hub may still appear in older AWS cloud migration checklists. However, AWS stopped accepting new Migration Hub customers on November 7, 2025 and now recommends AWS Transform for new migration projects. Existing Migration Hub customers can continue their current projects.
2) What security checks should happen before an AWS migration?
Review AWS identity and access management, network segmentation, security groups, encryption, logging, backups, sensitive data handling, and industry requirements before migrating workloads.
AWS Config can help evaluate resource configurations, while AWS Security Hub CSPM can provide findings from security checks and integrated security services. Security and compliance teams should remain involved throughout the AWS migration process.
3) How can you optimize costs after an AWS migration?
Start with actual resource utilization. Right-size compute and databases, remove unused resources, tune storage, implement auto scaling where appropriate, and review cloud costs regularly.
When workloads become predictable, Savings Plans or Reserved Instances may improve cost efficiency. Continue reviewing costs after migration because cloud usage changes as the business grows. AWS Cost Explorer also provides Savings Plans recommendations based on historical usage.
Cloudvisor handles AWS migration from discovery through cutover and post-move optimization, including pilot migrations, data synchronization, migration tooling, security practices, and cost controls.
Planning a move from on-premises, Google Cloud, another cloud provider, or an existing hosting platform? Talk to our team and build an AWS migration process around your applications, data, business goals, and risk requirements.
