A successful AWS migration in 2026 follows a phased, measurable approach with rollback capability at every stage. Teams that rush migrations with big-bang cutovers experience 3x more incidents and 40% longer stabilization periods than those using phased approaches. This checklist covers pre-migration foundations, phased execution, rollback design, validation gates, and the most common pitfalls to avoid.
If you are evaluating operational ownership models first, start with Services Overview. For planning and support options, see Pricing.
Pre-Migration Foundations
Before migrating any workload, establish the organizational and technical foundations that make the migration safe and measurable.
Define Measurable Goals
Every migration needs explicit success criteria. Vague goals like "move to the cloud" lead to scope creep and unmeasurable outcomes.
| Goal Category | Example Metric | Baseline | Target |
| Cost | Monthly infrastructure spend | $15,000/mo | $12,000/mo (20% reduction) |
| Reliability | Monthly uptime percentage | 99.5% | 99.9% |
| Performance | API P95 latency | 450ms | 200ms |
| Deployment | Deploy frequency | Weekly | Daily |
| Recovery | RTO for critical services | 4 hours | 30 minutes |
Document these baselines before migration begins. You cannot prove improvement without a measured starting point.
Dependency Mapping
Map every application, database, integration, and shared service. Identify which components depend on each other and which can be migrated independently.
Dependency Map Template:
Service: [name]
Owner: [team]
Dependencies:
- Database: [type, version, size, connection count]
- Cache: [type, size]
- Message Queue: [type, topics/queues]
- External APIs: [list with latency requirements]
- Shared filesystems: [mount points, size]
- Internal services: [list with communication pattern]
Data volume: [GB/TB, growth rate]
Traffic pattern: [steady/bursty/seasonal]
Compliance: [PCI/HIPAA/SOC2/none]
Migration complexity: [low/medium/high]
Security and Governance Foundations
Set up AWS security controls before any workloads arrive:
- AWS Organizations: Multi-account structure with separate accounts for production, staging, development, and security
- IAM: Federated identity (SSO), least-privilege policies, no long-lived access keys
- Logging: CloudTrail enabled on all accounts, centralized to security account
- Guardrails: Service Control Policies (SCPs) to prevent dangerous actions (disabling CloudTrail, opening 0.0.0.0/0 security groups)
- Networking: VPC design with private subnets, NAT gateways, and VPN/Direct Connect for hybrid connectivity
<h1>Verify CloudTrail is enabled</h1>
aws cloudtrail get-trail-status --name management-trail
<h1>Check for overly permissive security groups</h1>
aws ec2 describe-security-groups --query \
"SecurityGroups[?IpPermissions[?IpRanges[?CidrIp=='0.0.0.0/0']]]"
<h1>List IAM users with long-lived access keys</h1>
aws iam generate-credential-report
aws iam get-credential-report --query Content --output text | base64 -d
Backup and DR Policy
Establish backup and disaster recovery before migration, not after:
- Define RPO/RTO per service tier
- Configure automated backups for all databases (RDS snapshots, DynamoDB PITR)
- Set up cross-region replication for critical data
- Document and test the restore process before relying on it
Phase 0: Baseline and Assessment (Weeks 1-4)
Capture the complete picture of what you are migrating and establish acceptance thresholds for each workload.
Assessment Checklist
- [ ] Inventory all applications, databases, and integrations
- [ ] Measure current performance baselines (latency, throughput, error rates)
- [ ] Calculate current infrastructure costs with full allocation
- [ ] Identify compliance and data residency requirements
- [ ] Classify workloads by migration strategy (rehost, replatform, refactor)
- [ ] Estimate data transfer time for each database
- [ ] Identify workloads with hard dependencies on on-premise hardware
- [ ] Map DNS and networking requirements
Migration Strategy per Workload
| Strategy | Description | Effort | Risk | Best For |
| Rehost (Lift & Shift) | Move as-is to EC2/containers | Low | Low | Legacy apps, quick wins |
| Replatform | Minor changes for managed services | Medium | Medium | Databases, caching |
| Refactor | Redesign for cloud-native | High | Medium | Core services, long-term |
| Repurchase | Replace with SaaS | Low | Low | Email, CRM, monitoring |
| Retire | Decommission | None | None | Unused applications |
Phase 1: Pilot Low-Risk Workloads (Weeks 5-8)
Migrate 2-3 non-critical workloads to validate your migration process, monitoring setup, and rollback procedures.
Pilot Selection Criteria
- Low business criticality (internal tools, staging environments)
- Minimal external dependencies
- Small data volume (< 50 GB)
- Team familiar with the application code
- Representative of larger workloads to come
Pilot Validation Checklist
- [ ] Application deploys and starts correctly
- [ ] All health checks pass
- [ ] Monitoring and alerting produces correct signals
- [ ] Logging captures expected detail level
- [ ] Performance meets or exceeds baseline
- [ ] Rollback procedure tested and documented
- [ ] DNS cutover works as planned
- [ ] Backup and restore verified
- [ ] Team has operational confidence
Lessons Learned Documentation
After each pilot, document:
- What worked well in the migration process
- What required manual intervention or unexpected effort
- Time taken vs. estimated
- Process improvements for the next batch
Phase 2: Core Workloads (Weeks 9-16)
Migrate production workloads by business domain. Group services that share databases or tight dependencies into migration batches.
Batch Planning
Batch 1: User authentication + profile service + user database
Batch 2: Product catalog + search service + product database
Batch 3: Order processing + payment integration + order database
Batch 4: Analytics pipeline + reporting service + data warehouse
Data Migration
Data migration is the highest-risk component. Plan carefully:
- Small databases (< 100 GB): pg_dump/pg_restore or mysqldump during maintenance window
- Medium databases (100 GB - 1 TB): AWS DMS with continuous replication
- Large databases (> 1 TB): AWS DMS with initial full load via S3, then CDC replication
<h1>Estimate data transfer time</h1>
<h1>1 TB over 100 Mbps = ~22 hours</h1>
<h1>1 TB over 1 Gbps = ~2.2 hours</h1>
<h1>1 TB over Direct Connect 10 Gbps = ~13 minutes</h1>
<h1>Start DMS replication task</h1>
aws dms start-replication-task \
--replication-task-arn arn:aws:dms:us-east-1:123456789:task:ABC123 \
--start-replication-task-type start-replication
<h1>Check replication task progress (CDCLatencySource/CDCLatencyTarget are</h1>
<h1>CloudWatch metrics for the task, not fields on ReplicationTaskStats)</h1>
aws dms describe-replication-tasks --query \
"ReplicationTasks[].ReplicationTaskStats"
For each batch, enforce validation gates before declaring migration complete.
Phase 3: Critical Workloads (Weeks 17-24)
Critical workloads (payment processing, primary customer-facing services) require the most conservative migration strategy.
Blue-Green or Canary Migration
Go/No-Go Criteria
| Metric | Go Threshold | No-Go Threshold |
| Error rate | < 0.1% | > 0.5% |
| P99 latency | < 500ms | > 1000ms |
| Data consistency | 100% | < 99.99% |
| Throughput | >= baseline | < 90% baseline |
| Security controls | All passing | Any critical failure |
Phase 4: Optimization and Decommission (Weeks 25-32)
After all workloads are migrated and stable, optimize for cost and performance, then decommission source infrastructure.
Post-Migration Optimization
- Rightsize EC2 instances based on 2+ weeks of utilization data
- Evaluate Reserved Instances or Savings Plans for stable workloads
- Implement auto-scaling for variable workloads
- Review and optimize storage tiers (S3 lifecycle policies, EBS volume types)
- Enable cost allocation tags and set budget alerts
Decommission Checklist
- [ ] All traffic confirmed routing to AWS (zero traffic to source)
- [ ] Final backup of source environment taken and verified
- [ ] Source environment powered down for 30 days (monitoring for issues)
- [ ] Source infrastructure decommissioned
- [ ] DNS records updated and TTLs restored to normal
- [ ] VPN/Direct Connect removed if no longer needed
- [ ] Source hosting contracts cancelled
For cloud computing architecture guidance, review Cloud Computing and Documentation.
Rollback Strategy
Every migration phase must have a tested rollback path. Without rollback capability, a failed migration becomes a prolonged outage.
Rollback Design Principles
- Define objective triggers: Rollback when error rate exceeds X% or latency exceeds Y ms. Do not rely on subjective judgment during incidents.
- Pre-stage DNS and traffic controls: DNS changes should be ready to execute in minutes, not hours. Use low TTLs (60-300 seconds) during migration windows.
- Keep source running: Maintain the source environment in a ready state for at least 14 days after migration.
- Data synchronization: If the application writes data to AWS during the migration period, plan for reverse data sync in case of rollback.
- Game-day drills: Run a full rollback drill during Phase 1 pilots. Verify that the team can execute rollback within the target RTO.
Common Migration Pitfalls
Need a tailored migration roadmap for your stack? Contact the Arxentra team for a guided assessment.
Frequently Asked Questions
Q: How long does a typical AWS migration take?
For a mid-size company (20-50 services, 5-10 databases), plan for 6-9 months from assessment to full decommission. Smaller teams with fewer services can complete in 3-4 months. The timeline depends primarily on data volume, compliance requirements, and team familiarity with AWS.
Q: Should we use AWS Migration Hub or manage migration manually?
AWS Migration Hub provides useful tracking and discovery features but does not automate the actual migration. Use it for visibility and tracking across teams. The actual migration work (data transfer, application deployment, DNS cutover) still requires hands-on engineering.
Q: How do we handle database migrations with zero downtime?
Use AWS DMS (Database Migration Service) with continuous replication. Set up DMS to replicate changes from source to target in real-time. When ready to cut over, stop writes to the source, wait for replication to catch up (typically seconds), then redirect the application to the target database.
Q: What is the biggest cost surprise in AWS migrations?
Data transfer costs. AWS charges for data leaving AWS (egress) but not for data entering (ingress). During migration, egress is minimal. After migration, cross-region transfers, API responses, and CDN origin pulls generate ongoing egress costs. Model these carefully.
Q: Should we refactor applications during migration or after?
Migrate first, refactor second. Combining migration with refactoring doubles the risk and extends timelines unpredictably. Rehost applications to AWS, stabilize operations, then refactor individual services when there is a clear business case for cloud-native redesign.