How to Create an AWS Migration Plan: A Step-by-Step Guide
Moving workloads to AWS is not simply a case of choosing a few cloud services and deciding on a migration date.
A useful AWS migration plan connects the reason for migrating with the applications you currently run, their technical and business dependencies, the AWS environment they will move into, the order in which workloads will migrate, and how each migration will be tested and validated.
The objective is to remove as much uncertainty as possible before production workloads start moving.
By the end of the planning process, you should know what is moving, why it is moving, where it is going, how it will get there, when it will move, what could go wrong and who is responsible for each stage.
This guide walks through how to build that plan step by step.
What Is an AWS Migration Plan?
An AWS migration plan is the practical blueprint for moving applications, data and infrastructure from an existing environment into Amazon Web Services.
It turns a high-level decision such as "we want to move to AWS" into a sequence of decisions and activities that can actually be delivered.
AWS commonly describes the migration journey through three broad phases:
Assess → Mobilize → Migrate and Modernize
Assessment helps you understand the existing environment and build the case for migration. Mobilisation turns that understanding into a migration programme, including the AWS foundation, migration plan, operating model and readiness work. Migration and modernisation then move workloads through planned migration waves and improve them where appropriate.
An AWS migration strategy, migration roadmap and migration plan are related, but they are not exactly the same thing.
A migration strategy defines the overall approach and the migration treatment for workloads.
A migration roadmap describes the expected sequence and timeline.
A migration plan brings those decisions together with the workload inventory, dependencies, target architecture, migration waves, risks, testing, cutover and operational requirements needed to execute the migration.
What should an AWS migration plan contain?
Although every migration is different, a practical plan will normally establish:
- migration objectives and success criteria
- applications and infrastructure in scope
- application and infrastructure dependencies
- migration readiness and constraints
- migration strategy for each workload
- target AWS architecture
- security, networking and governance requirements
- expected migration and AWS operating costs
- migration waves and sequencing
- migration risks and mitigations
- testing and validation requirements
- cutover and rollback plans
- post-migration responsibilities
The quality of the plan depends heavily on the quality of the information behind it. A detailed spreadsheet is not particularly useful if the workloads, dependencies or assumptions recorded in it are wrong.
Step 1: Define Why You Are Migrating to AWS
Before deciding how to migrate, establish what the migration is supposed to achieve.
Organisations move to AWS for very different reasons. One business might need to leave a data centre before a contract expires. Another might be struggling to scale an existing platform. Others may want better resilience, faster deployment, less physical infrastructure to manage or access to AWS managed services.
Those objectives influence the migration plan.
For example, a business facing a fixed data-centre exit date may prioritise moving workloads quickly and modernising them later. A business migrating primarily to reduce operational overhead might place greater emphasis on replacing self-managed infrastructure with managed AWS services.
Define measurable success criteria where possible.
Ask questions such as:
- Which business or technical problem is the migration expected to solve?
- Which workloads are in scope?
- Is there a fixed deadline?
- How much downtime can each application tolerate?
- Are there regulatory, security or data-location requirements?
- Is application modernisation part of this migration or a later programme?
- What would make the migration unsuccessful even if the applications technically run in AWS?
The last question is important.
An application starting successfully on an EC2 instance does not necessarily mean the migration achieved its business objective.
Step 2: Build an Accurate Workload and Application Inventory
You cannot build a reliable AWS migration plan without understanding what currently exists.
Discovery should identify the applications, infrastructure and services that may be affected by the migration.
Depending on the environment, this can include:
- physical and virtual servers
- operating systems
- CPU and memory utilisation
- databases
- storage
- network configuration
- IP addresses and DNS
- application owners
- business owners
- software versions
- licences
- authentication services
- certificates and secrets
- backup requirements
- scheduled jobs
- monitoring
- third-party integrations
- application criticality
Do not treat this purely as a server inventory.
A list showing 50 virtual machines tells you that 50 virtual machines exist. It does not necessarily tell you which machines form one application, which database they depend on, who uses the application or what happens if one component becomes unavailable.
The application view is what begins turning infrastructure discovery into migration planning.
Identify application and infrastructure dependencies
Dependencies are one of the most important parts of discovery because they directly affect migration sequencing.
Consider a relatively simple customer-facing application.
The web tier might communicate with an internal API. The API might depend on a database. Authentication might rely on Active Directory. The application might send email through another internal service and exchange files with a third-party system overnight.
Migrating the web server without understanding those relationships can create an application that is technically running in AWS but cannot function properly.
Dependencies can include:
- application-to-application communication
- database connections
- authentication and directory services
- shared file systems
- internal APIs
- DNS
- network routes and firewall rules
- message queues
- batch processes
- external SaaS platforms
- third-party APIs
Dependency information will later help determine which systems need to move together and which services must remain reachable across AWS and the existing environment during a phased migration.
Don't rely entirely on the CMDB
Existing documentation and configuration management databases are useful starting points, but they should not automatically be treated as complete.
Environments change.
An application owner may know about a critical integration that isn't properly documented. Network traffic may reveal communication between systems that wasn't recorded. Operations teams may know about overnight processes that are invisible during a short discovery exercise.
Good discovery can therefore combine documentation, automated discovery, monitoring data and conversations with the people who actually operate and support the applications.
Step 3: Assess Migration Readiness and Constraints
Once you know what exists, determine how ready each workload and the wider organisation are to migrate.
Not every workload will present the same level of difficulty.
An internally developed stateless application running on a supported operating system might be relatively straightforward. A legacy application with undocumented integrations, an unsupported database and strict downtime requirements is a very different migration.
Assess areas such as:
Technical compatibility. Can the application run in the intended AWS environment? Are operating systems, databases and application versions supported?
Data. How much data needs to move, how quickly does it change and how long will transferring or synchronising it take?
Connectivity. Which systems will continue communicating with the existing environment during migration?
Availability. What are the workload's recovery and downtime requirements?
Security and compliance. Are there specific requirements around access, encryption, logging, data residency or auditability?
Licensing. Can existing licences move to AWS, or will the target architecture change the licensing model?
People and skills. Does the organisation have the AWS skills needed to build and operate the target environment?
Operational readiness. Who will monitor, patch, back up and support the workload after migration?
Constraints discovered here should influence the plan rather than being recorded and forgotten.
If a database can tolerate only a short outage, for example, that becomes an input into the migration method and cutover design.
Step 4: Choose a Migration Strategy for Each Workload
The next step is deciding what will actually happen to each application.
AWS commonly describes seven migration strategies, often referred to as the 7 Rs:
- Rehost – move the workload with minimal architectural change.
- Replatform – make targeted changes that provide cloud benefits without redesigning the entire application.
- Refactor or re-architect – redesign the application to make greater use of cloud-native architectures or services.
- Relocate – move infrastructure to AWS without redesigning individual applications, where the underlying platform supports this approach.
- Repurchase – replace the existing application with another product, commonly a SaaS solution.
- Retain – keep the workload in its current environment for now.
- Retire – remove applications or infrastructure that are no longer required.
The important point is that an organisation does not need one migration strategy for everything.
One application might be rehosted because a data-centre exit deadline is approaching. Another might move from a self-managed database to an AWS managed database as part of a replatform. An old reporting application might be retired altogether.
Trying to modernise every application during the migration can also increase programme complexity unnecessarily.
For some workloads, getting the application safely onto AWS first and modernising it afterwards may be the lower-risk option.
Each workload should therefore have an agreed migration treatment and a reason for that decision.
Step 5: Design the Target AWS Environment
At this stage you know what is moving and broadly how it will move.
Now define where it is going.
A migration plan should not leave fundamental architecture decisions until workloads are ready for cutover.
The target environment may need decisions around:
- AWS Region selection
- AWS account structure
- production and non-production separation
- VPC design
- subnets and routing
- internet access
- connectivity back to the existing environment
- DNS
- IAM and workforce access
- encryption and key management
- centralised logging
- monitoring
- backup and recovery
- security services and controls
- tagging
- cost allocation
- resilience and availability
- compute, database and storage services
The level of design required will depend on the size and complexity of the migration.
A single application moving into an existing, well-governed AWS environment requires different foundation work from an organisation building its first multi-account AWS environment.
Make sure the AWS foundation is ready
For larger or multi-workload migrations, the AWS foundation often needs to exist before production migration waves begin.
This is where an AWS landing zone becomes important.
A landing zone provides the governed AWS foundation in which workloads can operate. Depending on the organisation, that can include AWS account structure, identity and access, networking, security controls, logging and governance.
CloudOps Studio's AWS Landing Zone service focuses on building this multi-account AWS foundation before workloads scale across the environment.
The key planning principle is simple:
The target AWS environment should be ready before the migration wave needs it, not designed during cutover week.
Step 6: Estimate Migration and Ongoing AWS Costs
AWS migration planning should consider two different types of cost:
- the cost of carrying out the migration
- the ongoing cost of running the workloads in AWS
They are not the same thing.
Migration costs can include engineering time, consultancy, migration tooling, data transfer, temporary infrastructure and the cost of operating old and new environments simultaneously during transition.
The target AWS environment can introduce costs across areas such as:
- compute
- databases
- storage
- data transfer
- load balancing
- NAT gateways
- connectivity
- backup
- monitoring
- security services
- AWS Support
- software licensing
Estimates should be based on realistic workload requirements rather than simply reproducing the size of existing servers.
An on-premises virtual machine with eight vCPUs, for example, does not automatically mean the AWS workload needs an equivalent EC2 instance. Utilisation data may show that the existing server has been significantly over-provisioned.
At the same time, estimating only the obvious compute cost can understate the real AWS bill.
AWS provides tools that can support assessment, sizing and cost modelling, while AWS Transform can assist with migration assessment and planning activities. The exact tooling used will depend on the migration and the information available.
The aim at this stage is not to predict every penny of future spend. It is to build a sufficiently reliable cost model to support architecture and migration decisions, with assumptions clearly recorded.
Step 7: Prioritise Workloads and Build Migration Waves
Most multi-workload migrations should not be treated as one large cutover.
Instead, workloads can be grouped into migration waves.
A wave is a manageable group of workloads planned to migrate within a defined period.
The order should not be determined purely by which servers look easiest to move.
Consider:
- application dependencies
- business criticality
- migration complexity
- migration strategy
- technical risk
- data-transfer requirements
- maintenance windows
- business events
- target-environment readiness
- availability of application owners
- migration-team capacity
Start with a controlled migration wave
An early migration wave can help validate the process, architecture and tooling before more critical workloads move.
That does not mean the first wave should contain random low-value servers simply because they are easy.
A useful early workload should be manageable enough to control risk while still exercising enough of the migration process to reveal weaknesses.
Lessons from the first wave can then improve later waves.
Why dependencies affect migration sequencing
Imagine Application A depends on a database used by Applications A, B and C.
Moving the database solely because Application A is scheduled for the first wave could disrupt two applications that aren't yet ready to migrate.
The plan may instead need temporary hybrid connectivity, a different migration order or a wave that keeps tightly coupled components together.
This is why dependency discovery performed earlier becomes so important.
Wave planning turns the application inventory into an executable sequence.
Step 8: Define Security, Governance and Operational Readiness
Security and operations should be part of migration planning rather than activities added after workloads arrive.
Before a production workload moves, establish how it will be managed in AWS.
That can include:
- identity and access
- privileged access
- security logging
- encryption
- vulnerability management
- patching
- backups
- recovery procedures
- monitoring and alerting
- incident response
- compliance controls
- change management
- service ownership
- escalation procedures
This is particularly important when responsibility changes during the migration.
The team that builds the AWS environment may not be the team that operates the application afterwards.
Those responsibilities need to be clear.
A migration is not operationally complete simply because an application responds successfully from AWS. Someone needs to know how to monitor it, support it, recover it and respond when something fails the following morning.
Step 9: Create the Testing, Cutover and Rollback Plan
Production migration should not depend on improvisation.
For each workload or migration wave, define how it will be tested, how traffic or users will move to the AWS environment and what happens if the migration fails.
Pre-migration testing
Where possible, test the target environment before the production cutover.
Testing can cover:
- application functionality
- database connectivity
- integrations
- authentication
- network connectivity
- permissions
- performance
- monitoring
- backup and recovery
- security controls
The exact tests should reflect what makes the application successful from the user's perspective, not merely whether its infrastructure is online.
Cutover planning
A cutover runbook should set out the sequence of actions required to move production use to AWS.
Depending on the workload, this might include:
- confirming migration readiness
- notifying stakeholders
- implementing a change freeze
- completing final data synchronisation
- stopping or restricting writes to the source system
- switching DNS, routes or application traffic
- validating the AWS workload
- obtaining application or business sign-off
- monitoring the environment closely after cutover
Responsibilities should be assigned before the migration begins.
During a production incident is not the time to decide who has authority to continue or abandon a cutover.
Define rollback criteria before cutover
Saying "we can roll back if something goes wrong" is not a complete rollback plan.
Define:
- what conditions trigger rollback
- who makes the decision
- how long the decision window remains open
- how traffic returns to the original environment
- how data changes are handled
- whether the source remains available
- how users and stakeholders are informed
There may be a point during some migrations after which rollback becomes increasingly difficult because data has changed in the new environment.
That needs to be understood in advance.
Step 10: Validate the Workload After Migration
A successful cutover is the beginning of post-migration validation, not the end of the migration.
Confirm that the application operates correctly under real conditions.
Validation can include:
- user access
- application functionality
- database consistency
- integrations
- scheduled processes
- monitoring and alerts
- logging
- backups
- performance
- security controls
- business transactions
- recovery procedures
Application owners and business users may need to participate in acceptance testing.
Monitor the workload closely enough to identify problems that weren't visible during pre-migration testing.
Do not immediately remove the source environment simply because the first validation checks pass.
Decommissioning should happen according to the agreed migration and rollback plan, once the team is confident that the AWS workload is stable and the old environment is no longer required.
Step 11: Optimise and Hand Over the AWS Environment
Migration creates a new operational baseline.
It is rarely the final state.
Once workloads have stabilised, review opportunities to improve cost, performance, resilience, security and operational efficiency.
That might include:
- rightsizing AWS resources using real utilisation data
- adjusting scaling
- reviewing storage classes
- refining monitoring thresholds
- removing temporary migration resources
- reviewing backup retention
- improving resilience
- addressing security findings
- improving tagging and cost allocation
- identifying applications suitable for further modernisation
This is also the point where operational handover becomes critical.
Document:
- architecture
- support responsibilities
- monitoring
- alerts
- backup and recovery
- common operational procedures
- access requirements
- known issues
- remaining technical debt
If a workload was deliberately rehosted to reduce migration risk or meet a deadline, further replatforming or refactoring can become a separate optimisation programme rather than being forced into the original migration.
What Should Your Finished AWS Migration Plan Include?
After completing the planning process, you should have much more than a list of servers and a migration date.
A usable AWS migration plan should answer the following questions:
| Question | Planning output |
|---|---|
| Why are we migrating? | Objectives and success criteria |
| What is moving? | Verified application and infrastructure inventory |
| What does each workload depend on? | Dependency map |
| What could prevent migration? | Readiness assessment and constraints |
| How will each workload move? | Migration strategy |
| Where will it run? | Target AWS architecture |
| Is AWS ready to receive it? | Foundation and landing-zone readiness |
| What will it cost? | Migration and operating-cost estimates |
| What moves first? | Migration priorities and waves |
| What could go wrong? | Risk register and mitigations |
| How will we prove it works? | Testing and validation plan |
| How will production move? | Cutover runbook |
| What if the cutover fails? | Rollback criteria and procedure |
| Who owns it afterwards? | Operational handover plan |
If several of those questions still cannot be answered, the migration probably needs more planning before a production date is committed.
Turn Your Assessment Into an Initial AWS Migration Plan
If you're at the early planning stage and want a quicker way to structure the first decisions, CloudOps Studio's free AWS Migration Path Builder can help.
Provide information about your current workload and migration requirements and the tool generates a practical starting point covering areas such as the migration approach, proposed AWS architecture, migration steps, risks and indicative costs.
It isn't a replacement for detailed application discovery or production migration engineering, particularly for complex environments.
It is designed to help turn an initial idea to "move this workload to AWS" into something more structured that you can evaluate and develop into a full migration plan.
When Should You Get Help With an AWS Migration?
Some AWS migrations can be planned and delivered entirely by an internal team.
Others benefit from specialist support.
External migration expertise may be useful when:
- several applications have complex dependencies
- the workloads are business-critical
- internal AWS experience is limited
- the organisation is building its AWS foundation at the same time
- migration windows are tight
- downtime must be minimised
- security or compliance requirements are significant
- the target architecture is unclear
- multiple migration waves need coordinating
The important point is to bring that expertise in early enough to influence the plan.
Discovering during cutover that the target network, security controls or application dependencies were misunderstood is much more expensive than resolving those questions during assessment.
CloudOps Studio's AWS Migration Services can help businesses assess, plan and deliver migrations to AWS, from understanding the existing workload and designing the target architecture through to migration and validation.
AWS Migration Plan FAQs
How long does it take to create an AWS migration plan?
There is no reliable standard duration.
Planning a single well-documented application is very different from assessing hundreds of workloads spread across an existing data centre.
The time required depends on factors such as the number of applications, quality of existing documentation, technical complexity, dependencies, regulatory requirements and availability of application owners.
The aim should be to reach sufficient confidence to make migration decisions rather than forcing every assessment into an arbitrary planning period.
What are the three phases of an AWS migration?
AWS commonly structures the migration journey into three broad phases: Assess, Mobilize, and Migrate & Modernize.
Assessment establishes the current environment and migration case. Mobilisation prepares the organisation, AWS environment and migration plan. Migration and modernisation then moves workloads through the planned migration process and improves them where appropriate.
What are the 7 Rs of AWS migration?
The AWS migration strategies commonly referred to as the 7 Rs are: Rehost, Replatform, Refactor/Re-architect, Relocate, Repurchase, Retain and Retire.
Different applications within the same migration programme can use different strategies.
Do you need an AWS landing zone before migrating?
Not every migration requires the same landing-zone implementation, but the AWS foundation needed by the workload should be ready before production migration.
For multi-account or growing AWS environments, this can include account structure, identity, networking, centralised logging, security controls and governance.
Building those components before workloads arrive reduces the need to retrofit fundamental controls after migration.
You can learn more about this on the AWS Landing Zone Services page .
What is the difference between an AWS migration plan and a migration roadmap?
A migration roadmap describes the high-level sequence, priorities and expected timeline for moving workloads.
The migration plan goes deeper. It brings together discovery, dependencies, workload strategies, target architecture, migration waves, risks, testing, cutover, rollback and operational responsibilities.
The roadmap therefore forms part of the wider migration plan rather than replacing it.
Build the Plan Before You Move the Workload
A good AWS migration plan reduces uncertainty before production systems start moving.
It establishes what exists today, what each application depends on, which migration approach makes sense, what the target AWS environment should look like and how workloads will move safely through testing, cutover and validation.
It also makes assumptions visible.
That matters because many migration problems do not begin during the migration itself. They begin earlier, when an undocumented dependency, unrealistic downtime assumption or unfinished AWS foundation goes unnoticed during planning.
Start with accurate discovery. Make workload-level decisions. Build the AWS foundation early enough. Plan migration waves around dependencies rather than servers. And define how you will test, cut over, roll back and operate each workload before the migration window begins.
If you're still working through those initial decisions, start with the free AWS Migration Path Builder .
If you already know that you need help assessing, planning or delivering the migration, explore CloudOps Studio's AWS Migration Services .