Phase 2: Planning your AWS migration strategy
The planning phase translates assessment findings into a concrete migration roadmap that sequences workload moves by priority, risk, and interdependency. This is where you choose the right migration strategy for each workload and design the target AWS architecture.
The 6 Rs: choosing the right strategy per workload
AWS defines six migration strategies, commonly called the 6 Rs. Each represents a different balance between migration speed and long-term optimization:
- Rehost (lift-and-shift): move the application as-is to AWS EC2 instances. Fastest path with minimal code changes, ideal for stable workloads where speed matters most.
- Replatform (lift-and-reshape): make targeted optimizations during the move, such as switching to Amazon RDS for database management or adopting Elastic Beanstalk for deployment, without rewriting application logic.
- Refactor (re-architect): redesign the application to use cloud-native services like AWS Lambda, Amazon ECS/EKS, or Amazon Aurora. Highest effort but delivers the greatest long-term scalability and cost efficiency.
- Repurchase: replace an on-premises application with a SaaS equivalent (e.g., moving from self-hosted CRM to a cloud-native platform).
- Retain: keep the workload on-premises when migration does not make technical or financial sense in the current phase.
- Retire: decommission applications that are redundant, unused, or superseded by other systems.
Most enterprise migrations use a mix of strategies. A common pattern is to rehost 60-70% of workloads for speed, replatform 20-25% where quick optimizations are available, and earmark 5-15% for refactoring in a subsequent phase.
Designing the landing zone
Before any workload moves, your team must provision a well-architected AWS landing zone. This foundational environment includes:
- Multi-account structure using AWS Organizations for isolation and governance.
- Networking architecture with VPCs, subnets, and connectivity back to on-premises (via AWS Direct Connect or VPN).
- Identity and access management (IAM) policies aligned with least-privilege principles.
- Security baselines including GuardDuty, Security Hub, and CloudTrail logging.
- Cost management guardrails with AWS Budgets and tagging policies.
Wave planning
Workloads are grouped into migration waves based on dependency clusters, business criticality, and team capacity. A typical wave plan follows this sequence:
- Wave 0 (foundation): landing zone provisioning, network connectivity, and security baseline deployment.
- Wave 1 (pilot): two to five representative workloads that validate tooling, processes, and team readiness.
- Waves 2-N (production): remaining workloads in progressively larger batches, with each wave applying lessons from the previous one.
- Final wave (optimization): right-sizing, reserved capacity, and modernization planning for rehosted workloads.
Phase 3: Migration execution
The execution phase is where workloads actually move to AWS, and success depends on using the right tools, following tested runbooks, and maintaining rollback capability throughout. This phase applies the strategies and wave plans developed during planning.
AWS migration tools and services
AWS provides a comprehensive toolkit purpose-built for migration. Using these native services reduces manual effort and provides built-in tracking and validation:
| Tool | Purpose | Best for |
|---|---|---|
| AWS Migration Hub | Central dashboard for tracking migration progress across tools | Portfolio-level visibility |
| AWS Application Migration Service (MGN) | Automated lift-and-shift with continuous replication and quick cutover | Server rehosting with minimal downtime |
| AWS Database Migration Service (DMS) | Database migration with support for homogeneous and heterogeneous moves | Database transfers with continuous replication |
| AWS DataSync | High-speed online data transfer between on-premises storage and AWS | Large dataset migration (up to 10x faster than open-source tools) |
| AWS Snow Family | Physical devices for offline data transfer at petabyte scale | Environments with limited bandwidth or massive data volumes |
| AWS Application Discovery Service | Automated inventory and dependency mapping of on-premises servers | Assessment and planning data collection |
Executing the cutover
Each workload cutover follows a repeatable pattern that minimizes risk:
- Pre-migration testing: validate the replicated environment against functional and performance benchmarks.
- Cutover rehearsal: run a dry cutover during a maintenance window to measure actual switchover time and identify gaps.
- Production cutover: execute the final switch with DNS updates, traffic redirection, and monitoring escalation.
- Post-cutover validation: confirm application functionality, data integrity (using checksums), and performance against SLA targets.
- Rollback window: maintain the source environment for a defined period (typically 48-72 hours) to enable quick rollback if critical issues emerge.
For detailed guidance on server migration specifically, see our AWS migration services overview.
Phase 4: Post-migration optimization
Migration is the starting point for cloud-native operations, not the finish line, and the optimization phase is where the largest cost savings materialize. Organizations that skip post-migration optimization leave 20-35% of potential savings on the table.
Key optimization activities in the first 90 days after migration:
- Right-sizing: analyze actual resource utilization with AWS Compute Optimizer and resize instances to match real demand rather than on-premises assumptions.
- Reserved capacity planning: commit to Savings Plans or Reserved Instances for stable workloads once utilization patterns are clear (typically after 30-60 days of cloud operation).
- Auto-scaling configuration: implement horizontal and vertical scaling policies so infrastructure adjusts automatically to demand fluctuations.
- Storage tiering: move infrequently accessed data to S3 Intelligent-Tiering, S3 Glacier, or EBS cold storage to reduce storage costs.
- Monitoring and alerting: tune CloudWatch dashboards, set billing alarms, and establish operational runbooks for the cloud environment.
- Security hardening: review IAM policies, enable automated compliance checks with AWS Config, and validate encryption at rest and in transit.
Opsio's cloud infrastructure optimization services continue beyond migration, providing ongoing right-sizing, security management, and cost governance.
AWS migration checklist: essential steps at each phase
This checklist consolidates the critical activities across all four migration phases into a single reference you can use to track progress and catch gaps.
| Phase | Step | Status |
|---|---|---|
| Assessment | Complete application and infrastructure inventory | |
| Assessment | Map all application dependencies | |
| Assessment | Score business criticality for each workload | |
| Assessment | Review compliance and data residency requirements | |
| Assessment | Build TCO comparison and business case | |
| Planning | Assign migration strategy (6 Rs) per workload | |
| Planning | Provision AWS landing zone with security baselines | |
| Planning | Design network connectivity (Direct Connect or VPN) | |
| Planning | Create wave plan grouped by dependencies | |
| Planning | Set up FinOps tooling and budget alerts | |
| Execution | Complete pilot wave and document lessons learned | |
| Execution | Execute production waves with rehearsed cutovers | |
| Execution | Validate data integrity with checksums after each wave | |
| Execution | Maintain rollback capability for 48-72 hours post-cutover | |
| Optimization | Right-size instances based on 30 days of utilization data | |
| Optimization | Implement Savings Plans or Reserved Instances | |
| Optimization | Configure auto-scaling and storage tiering | |
| Optimization | Establish ongoing monitoring and operational runbooks |
Common AWS migration risks and how to mitigate them
Every migration carries risk, but each risk category has proven mitigation strategies that experienced teams apply consistently. Understanding these risks before you start allows your team to build the right safeguards into the migration plan from day one.
- Data loss or corruption: mitigated through incremental replication, checksum validation at source and target, and parallel-run periods where both environments serve traffic.
- Extended downtime: mitigated through phased cutovers with pre-tested rollback procedures, blue-green deployments, and rehearsed cutover windows.
- Cost overruns: mitigated through detailed consumption modeling during assessment, FinOps tooling from day one, and reserved capacity planning after utilization stabilizes.
- Compliance violations: mitigated through pre-migration compliance mapping, automated policy enforcement with AWS Config rules, and post-migration audit validation.
- Skill gaps: mitigated through targeted team training, documented runbooks, and partnering with experienced migration consultants who transfer knowledge throughout the engagement.
- Application dependency surprises: mitigated through thorough discovery using AWS Application Discovery Service and manual validation of critical integrations before wave scheduling.
AWS migration best practices for 2026
Migration tooling and cloud services continue to evolve, and the practices that deliver the best results in 2026 reflect lessons from thousands of completed migrations.
- Automate infrastructure provisioning. Use Infrastructure as Code (IaC) with AWS CloudFormation or Terraform for every environment. Manual provisioning creates configuration drift that compounds across migration waves.
- Embed security from the start. Implement DevSecOps practices, policy-as-code guardrails, and automated security scanning before the first workload moves. Retrofitting security after migration is significantly more expensive.
- Start FinOps during assessment. Cloud financial management should begin when the first consumption estimates are built, not after the first unexpected invoice arrives.
- Rehearse every critical cutover. Blue-green deployments and dry-run cutovers are not optional for production workloads. Teams that rehearse complete cutovers 3x faster with fewer incidents.
- Plan for Day 2 operations from Day 1. Monitoring, alerting, incident response, and knowledge transfer documentation should be part of the migration plan, not afterthoughts.
- Measure outcomes against the business case. Track cost savings, performance improvements, deployment frequency, and incident rates against the benchmarks established during assessment.
For a broader view of cloud migration strategy beyond AWS, see our cloud workload migration guide.
FAQ
What are the main phases of the AWS migration process?
The AWS migration process follows four phases: discovery and assessment (inventorying workloads and dependencies), planning (choosing strategies and designing the target architecture), migration execution (moving workloads using AWS tools like MGN and DMS), and post-migration optimization (right-sizing, reserved capacity, and ongoing cost governance). Each phase has defined entry and exit criteria that keep the program on track.
How long does an AWS migration typically take?
Timeline depends on portfolio size and complexity. A focused migration of 20-50 applications typically completes in three to six months. Mid-market organizations with 100-200 workloads should plan for six to twelve months. Large enterprises with hundreds of applications and legacy dependencies may require twelve to eighteen months with phased waves. Assessment alone takes two to six weeks regardless of total scope.
What AWS tools help simplify the migration process?
AWS provides several purpose-built migration tools. AWS Application Migration Service (MGN) automates server rehosting with continuous replication and quick cutover. AWS Database Migration Service (DMS) handles database transfers with minimal downtime. AWS Migration Hub provides centralized tracking across all migration workstreams. AWS DataSync accelerates large-scale data transfers, and the AWS Snow Family supports offline data movement at petabyte scale.
How do I choose between rehost, replatform, and refactor?
Choose rehost (lift-and-shift) when speed is the priority and the application runs well as-is. Choose replatform when targeted optimizations like managed databases or container orchestration deliver clear value without requiring code rewrites. Choose refactor when the application needs fundamental redesign to meet scalability, performance, or cost targets. Most enterprises use a mix: rehost for 60-70% of workloads, replatform for 20-25%, and schedule refactoring for the remainder in later phases.
How can I reduce downtime during AWS migration?
Minimize downtime through continuous data replication (AWS MGN and DMS both support this), phased cutovers with pre-tested rollback procedures, and rehearsed cutover windows. Blue-green deployment patterns let you run both source and target environments in parallel, switching traffic only after validation passes. For critical workloads, schedule cutovers during maintenance windows and keep rollback capability active for at least 48-72 hours.
What does post-migration optimization involve?
Post-migration optimization focuses on right-sizing instances based on actual utilization data (using AWS Compute Optimizer), committing to Savings Plans or Reserved Instances for stable workloads, configuring auto-scaling policies, implementing storage tiering for infrequently accessed data, and establishing ongoing monitoring with CloudWatch. This phase typically delivers 20-35% additional cost savings beyond the initial migration and should begin within the first 30-90 days after cutover.
