The AWS migration process follows four phases — Assess, Mobilize, Migrate, and Optimize — that systematically move workloads from on-premises or other cloud environments to AWS. This playbook covers each phase with specific tools, timelines, and best practices for 2026.
The 6 R's of Migration Strategy
Every workload in your portfolio should be classified using the 6 R framework, which determines the migration approach, effort level, and expected benefit.
| Strategy | Description | Effort | Best For |
| Rehost (Lift & Shift) | Move as-is to EC2 | Low | Legacy apps, quick wins |
| Replatform | Minor optimizations during move | Medium | Database to RDS, app to Beanstalk |
| Refactor | Re-architect for cloud-native | High | Core apps needing scalability |
| Repurchase | Replace with SaaS | Medium | CRM, email, HR systems |
| Retire | Decommission | Low | Unused or redundant systems |
| Retain | Keep on-premises | None | Compliance-restricted workloads |
Phase 1: Assess Your Portfolio
Assessment identifies what you have, where it runs, and how applications depend on each other — data that drives every subsequent decision. Use these AWS tools:
- AWS Application Discovery Service: Deploys agents or agentless connectors to discover servers, processes, and network dependencies automatically
- AWS Migration Evaluator: Analyzes on-premises usage data to produce a directional business case with right-sized AWS recommendations
- AWS Migration Hub: Centralizes discovery data and migration tracking in a single dashboard
Assessment typically takes 2-4 weeks for portfolios under 500 servers. For larger environments, plan 4-8 weeks including dependency mapping and application owner interviews.
Phase 2: Mobilize and Plan
Mobilization transforms assessment data into an actionable migration plan with landing zone infrastructure, security baselines, and team readiness. Key activities include:
- Building the AWS Landing Zone with Control Tower for multi-account governance
- Establishing hybrid connectivity through Direct Connect or Site-to-Site VPN
- Configuring security baselines: GuardDuty, Security Hub, IAM Identity Center
- Running pilot migrations (typically 5-10 servers) to validate the approach
- Training operations teams on AWS services and incident response procedures
Plan 4-8 weeks for mobilization. This phase is the foundation for everything that follows — rushing it leads to costly rework during migration waves.
Phase 3: Migrate Workloads
Migration execution moves workloads in planned waves, typically processing 10-50 servers per wave with increasing velocity. Primary migration tools include:
- AWS Application Migration Service (MGN): Automated server replication for lift-and-shift migrations. Replaces the deprecated Server Migration Service.
- AWS Database Migration Service (DMS): Continuous database replication supporting homogeneous and heterogeneous migrations
- AWS DataSync: High-speed data transfer supporting up to 10 Gbps for file and object storage migrations
- AWS Transfer Family: Managed SFTP, FTP, and FTPS for file-based data migration workflows
Each migration wave follows a cutover window pattern: replicate continuously, test in parallel, cut over during a maintenance window, and validate before decommissioning the source. For migration consulting support, see our MAP program guide.
Phase 4: Optimize and Operate
Post-migration optimization typically identifies 30-40% cost savings through right-sizing, reserved capacity, and architecture improvements.
- Right-sizing: Use AWS Compute Optimizer to match instance types to actual utilization patterns
- Cost management: Implement Reserved Instances or Savings Plans for predictable workloads
- Performance tuning: Enable auto-scaling, optimize storage tiers, and configure CloudFront for static content
- Governance: Set up AWS Budgets, Cost Explorer alerts, and tagging enforcement policies
Schedule a Well-Architected Review 90 days after migration to identify improvement opportunities across all five pillars.
Migration Timeline and Cost Estimates
Realistic migration timelines depend on portfolio size, complexity, and organizational readiness.
- Small (10-50 servers): 3-6 months end-to-end, including assessment and optimization
- Medium (50-200 servers): 6-12 months with 3-5 migration waves
- Large (200+ servers): 12-24 months with dedicated migration teams and factory-model execution
Budget for 3-6 months of dual-running costs where both on-premises and cloud infrastructure operate simultaneously. AWS MAP credits can offset these overlapping expenses. Use the AWS Pricing Calculator to model your specific cost profile.
AWS Migration Best Practices
Organizations that follow structured migration practices achieve faster timelines and fewer post-migration issues.
- Start with non-critical workloads to build team confidence and refine processes
- Automate everything possible using infrastructure as code (CloudFormation, CDK, or Terraform)
- Document runbooks for each migration pattern before starting wave migrations
- Establish rollback procedures and test them before every cutover window
- Track progress in AWS Migration Hub for centralized visibility
Frequently Asked Questions
How long does a typical AWS migration take?
Small migrations (under 50 servers) take 3-6 months. Medium portfolios (50-200 servers) take 6-12 months. Large enterprise migrations (200+ servers) typically span 12-24 months including optimization.
What does AWS migration cost?
Migration costs include AWS service charges, partner consulting fees, and dual-running infrastructure expenses. AWS MAP credits offset a significant portion of these costs. Budget approximately $500-$2,000 per server for consulting and tooling, depending on complexity.
What is the difference between MGN and the deprecated SMS?
AWS Application Migration Service (MGN) replaced Server Migration Service (SMS). MGN offers continuous replication, automated testing, and faster cutover times. All new migrations should use MGN.
Can I migrate databases and servers simultaneously?
Yes, but coordinate carefully. Database migrations using DMS typically run continuously in the background while server migrations happen in planned cutover windows. Ensure application servers point to the correct database endpoints after cutover.
Do I need to migrate everything at once?
No. The wave-based approach migrates applications in groups of 10-50 servers, allowing teams to learn and improve with each wave. Some workloads may be retained on-premises permanently.
Editorial standards: This article was written by a certified practitioner and peer-reviewed by our engineering team. We update content quarterly to ensure technical accuracy. Opsio maintains editorial independence — we recommend solutions based on technical merit, not commercial relationships.