Why Migrate to AWS in 2025?
According to IDC, 70% of European enterprises will have migrated at least 50% of their workloads to the cloud by end of 2026. The drivers are clear: end of life for Windows Server 2012/2012 R2 (October 2023), rising on-premise hardware refresh costs, and competitive pressure to accelerate innovation. But a migration without a solid methodology is a recipe for budget overruns, service disruptions, and amplified technical debt. This guide gives you a complete roadmap.
The 7R Framework: Choosing the Right Strategy per Application
AWS defines seven migration strategies. The right choice depends on the expected value, technical complexity, and business constraints of each application.
Retire — Decommission
Between 10 and 20% of an enterprise's application portfolio is unused or redundant. Identifying and decommissioning these before migration generates immediate savings and reduces the migration surface. Audit licence usage logs and talk to business teams — you will be surprised how many applications nobody uses anymore.
Retain — Keep On-Premise
Some applications cannot or should not migrate in the near term: strong regulatory constraints (healthcare data under HDS, classified data), network latency requirements incompatible with cloud (industrial real-time systems), or an imminent end of life that makes migration investment unjustifiable.
Rehost — Lift and Shift
Migration as-is to EC2, without code or architecture changes. This is the fastest strategy (a few hours per server with AWS MGN) and the lowest short-term risk. It does not generate immediate optimisation, but it allows you to exit the data centre quickly. Cloud ROI (rightsizing, reservations) is realised in a second phase.
Relocate — VMware Cloud on AWS
For enterprises heavily invested in VMware, this strategy migrates VMware VMs to VMware Cloud on AWS without rewriting applications or changing tooling. The same vCenter, the same operational playbooks — but hosted on AWS infrastructure. Ideal as a first step before eventual replatforming.
Repurchase — Replace with SaaS
Why migrate an on-premise CRM to EC2 when Salesforce exists? This strategy abandons a proprietary application in favour of a SaaS equivalent. It typically applies to ERPs, CRMs, collaboration tools, and HR solutions. The effort is primarily on data migration and change management.
Replatform — Lift, Tinker and Shift
Migration with light optimisations that leverage AWS managed services without rewriting the application: self-managed MySQL to Amazon RDS (no more patching, automated backups), Tomcat on VM to AWS Elastic Beanstalk, cron jobs to AWS Batch. The effort-to-benefit ratio is excellent for stable long-lived applications.
Refactor / Re-architect — Cloud-Native
Partial or full rewrite to adopt cloud-native architectures: microservices, event-driven, serverless. This is the most expensive strategy in time and effort, but it delivers the maximum long-term value — elastic scalability, native resilience, accelerated time-to-market. Reserve it for strategic applications with high business impact.
Simplified Decision Tree
- Application unused → Retire
- Hard regulatory blocker → Retain
- VMware, need to exit fast → Relocate
- SaaS equivalent available → Repurchase
- Standard application, no refactor planned → Rehost
- Stable application, managed services available → Replatform
- Strategic application, technical debt → Refactor
Phase 1: Discovery — Inventory to Decide
A successful migration starts with precise knowledge of the current state. AWS provides two complementary tools.
AWS Application Discovery Service (ADS)
ADS automatically collects performance and configuration data from your on-premise servers via lightweight agents (Windows and Linux) or agentless mode via VMware vCenter.
# Install ADS agent on Linux
wget https://s3.amazonaws.com/aws-discovery-agent/linux/latest/aws-discovery-agent.tar.gz
tar -xzf aws-discovery-agent.tar.gz
sudo ./install -r eu-west-1 -k ACCESS_KEY -s SECRET_KEY
# Start continuous export
aws discovery start-continuous-export --region eu-west-1
# Check active agents
aws discovery describe-agents --filters "name=agentHealthStatus,values=HEALTHY"After two weeks of collection, you get for each server: CPU/RAM/disk utilisation, active network connections, running processes. This data feeds automatically into AWS Migration Hub.
AWS Migration Evaluator
Migration Evaluator analyses your ADS inventory and generates a quantified business case: estimated on-premise vs AWS cost over 3 years, sizing recommendations, projected savings. This is the document you will present to the executive team to validate the migration budget.
Dependency Mapping
ADS generates a network dependency map between your servers (who talks to whom, on which port). This map is essential for building your migration waves: tightly coupled applications must migrate together to avoid inter-datacenter latency issues.
Phase 2: Planning — Migration Hub and Wave Planning
AWS Migration Hub centralises the tracking of all your migrations from a single console, regardless of the region or tool used (MGN, DMS, DataSync).
Building Migration Waves
A wave is a group of applications migrated together during the same sprint. Wave composition criteria are: shared dependencies, responsible application team, tolerance for service interruption, and business criticality.
- Wave 0: Infrastructure (VPC, Transit Gateway, Direct Connect or VPN, Landing Zone)
- Wave 1: Non-critical applications — dev and staging environments
- Wave 2: Supporting applications (monitoring, internal tools)
- Waves 3 to N: Production applications, in order of increasing criticality
Cost Estimation with AWS Pricing Calculator
For each application, estimate the target AWS cost using the sizing recommendations from ADS. Do not forget to include: data transfer costs, AWS Support (Business or Enterprise depending on required SLAs), and third-party licences (Windows Server, SQL Server, Oracle).
Phase 3: Migration — Patterns and Tools
Rehosting with AWS Application Migration Service (MGN)
AWS MGN (formerly CloudEndure Migration) is the reference tool for lift-and-shift. It continuously replicates source servers to AWS, enabling a cutover with an RPO under 1 second and an RTO under 1 hour.
# AWS MGN migration workflow
# 1. Install MGN agent on source server (Windows or Linux, 1 agent per server)
# 2. Configure Launch Template for each server
# - Target EC2 instance type
# - Destination VPC and subnet
# - Security groups
# - Mandatory tags
# 3. Launch test cutover
aws mgn start-test --source-server-ids s-xxxxxxxxxx --account-id 123456789012
# 4. Validate application on test instance
# 5. Launch real cutover in maintenance window
aws mgn start-cutover --source-server-ids s-xxxxxxxxxx --account-id 123456789012
# Typical RTO: 45 minutes
# RPO: < 1 second (continuous replication)Database Migration with AWS DMS and SCT
Database migrations are often the critical path of a migration programme. AWS Database Migration Service (DMS) handles both homogeneous migrations (MySQL to RDS MySQL) and heterogeneous migrations (Oracle to Aurora PostgreSQL, SQL Server to RDS).
For heterogeneous migrations, start with AWS Schema Conversion Tool (SCT), which analyses the source schema, estimates the conversion effort, and automatically generates the target DDL with type and function conversions.
# DMS task configuration — Oracle to Aurora PostgreSQL
# 1. Create source and target endpoints
aws dms create-endpoint --endpoint-identifier oracle-source --endpoint-type source --engine-name oracle --server-name oracle-prod.internal --port 1521 --database-name PRODDB --username dms_user --password "****"
aws dms create-endpoint --endpoint-identifier aurora-target --endpoint-type target --engine-name aurora-postgresql --server-name aurora-cluster.cluster-xxx.eu-west-1.rds.amazonaws.com --port 5432 --database-name proddb
# 2. Create replication task (Full Load + CDC)
aws dms create-replication-task --replication-task-identifier oracle-to-aurora --source-endpoint-arn arn:aws:dms:... --target-endpoint-arn arn:aws:dms:... --replication-instance-arn arn:aws:dms:... --migration-type full-load-and-cdc --table-mappings file://table-mappings.jsonKeep CDC (Change Data Capture) replication active for 2 to 4 weeks before the final cutover. This gives you time to validate data quality and fix any conversion issues.
Replatform: Containerisation to ECS Fargate
For Java, Python, or Node.js applications deployed on VMs, containerisation offers an excellent effort-to-benefit ratio without application rewriting.
# Sample Dockerfile for a Java Spring Boot application
FROM amazoncorretto:17-alpine
WORKDIR /app
COPY target/application.jar app.jar
EXPOSE 8080
ENTRYPOINT ["java", "-jar", "app.jar"]
# Build and push to Amazon ECR
aws ecr create-repository --repository-name myapp --region eu-west-1
aws ecr get-login-password --region eu-west-1 | docker login --username AWS --password-stdin 123456789012.dkr.ecr.eu-west-1.amazonaws.com
docker build -t myapp .
docker tag myapp:latest 123456789012.dkr.ecr.eu-west-1.amazonaws.com/myapp:latest
docker push 123456789012.dkr.ecr.eu-west-1.amazonaws.com/myapp:latest
# ECS Fargate deployment (Terraform excerpt)
resource "aws_ecs_task_definition" "myapp" {
family = "myapp"
requires_compatibilities = ["FARGATE"]
network_mode = "awsvpc"
cpu = 512
memory = 1024
execution_role_arn = aws_iam_role.ecs_execution.arn
container_definitions = jsonencode([{
name = "myapp"
image = "${aws_ecr_repository.myapp.repository_url}:latest"
portMappings = [{ containerPort = 8080 }]
logConfiguration = {
logDriver = "awslogs"
options = {
"awslogs-group" = "/ecs/myapp"
"awslogs-region" = "eu-west-1"
}
}
}])
}Phase 4: Post-Migration Optimisation
Tagging Strategy
Without rigorous tagging, cloud cost allocation quickly becomes impossible. Define a mandatory tagging standard before the migration and enforce it via AWS Config Rules.
# Mandatory tags on all resources
Environment = "production" | "staging" | "development"
Team = "backend" | "frontend" | "data" | "infra"
CostCenter = "CC-001" | "CC-002" | ...
Application = "myapp" | "erp" | ...
MigrationWave = "wave-1" | "wave-2" | ...Rightsizing with AWS Compute Optimizer
Lift-and-shifted instances are systematically oversized — they were provisioned for on-premise peaks that no longer manifest the same way in the cloud. Wait for 14 days of stable metrics, then apply Compute Optimizer recommendations.
aws compute-optimizer get-ec2-instance-recommendations --filters name=Finding,values=OVER_PROVISIONED --region eu-west-1On average, our clients reduce their EC2 bill by 25% within 60 days of migration through rightsizing alone.
Reserved Instances and Savings Plans
Once the workload is stable (2 to 3 months post-migration), commit to Reserved Instances or Compute Savings Plans for predictable workloads. A 1-year Compute Savings Plan generates 30% savings over on-demand; a 3-year commitment delivers up to 50%.
Common Pitfalls to Avoid
Ignoring Network Latency
A 3-tier application with the front-end migrated to AWS and the database remaining on-premise will see performance degrade if connectivity is not sized appropriately. Measure current latency between application tiers, calculate the impact of an additional 20-50 ms, and either migrate tightly coupled tiers together or establish AWS Direct Connect (1 to 10 Gbps) before migrating latency-sensitive workloads.
Underestimating Data Transfer Costs
Data transfer out from AWS to the internet costs $0.09/GB in eu-west-1. For an application exporting 10 TB per month, this is $900/month in transfer fees — a cost line often absent from the initial business case. Use the AWS Pricing Calculator to model these costs before migration, and consider AWS CloudFront to reduce direct transfer volumes.
No Rollback Plan
Every migration must have a documented and tested rollback procedure. With AWS MGN, the source server remains active during the post-cutover validation period — keep it running for at least 7 days before decommissioning. For DMS database migrations, keep reverse replication active during the validation period.
Migrating Without Cleaning Up Technical Debt
A lift-and-shift of a poorly configured application produces a poorly configured application in the cloud, but more expensive to run. Identify quick-win cleanup items (unarchived logs, orphaned DB connections, redundant cron jobs) and address them before or during migration.
The Move2Cloud Methodology: 4-Week Assessment + 90-Day Sprint
At Move2Cloud, we apply a structured two-phase approach.
4-week assessment: ADS agent deployment, metrics collection, dependency mapping, 7R scoring of each application, business case construction, and wave plan. This deliverable is the foundation of the entire migration.
90-day sprint: execution of waves 0, 1, and 2 (infrastructure, dev/staging, first production applications). By the end of this sprint, the client team has gained autonomy on AWS tools and the migration processes are industrialised for subsequent waves.
Our clients typically see a 30 to 40% reduction in infrastructure costs within 12 months of migration, combining rightsizing, reservations, and elimination of unused resources.
Conclusion
A successful AWS migration is not a technical event — it is a transformation programme that touches teams, processes, and tools. The key to success lies in preparation: a rigorous discovery phase, a realistic wave plan, and cloud governance in place before the first workload arrives. Move2Cloud accompanies enterprises from start to finish, from initial assessment to post-migration optimisation. Contact us to start your free assessment.