AWS Cloud Migration - Strategy, Costs, Tools and the Complete Process

This post is for CTOs, engineering leads and architects making the decision to migrate to AWS or already planning one. I cover migration strategies (the 7Rs), AWS migration tooling, what the real costs look like for each component, the step-by-step process, and the common mistakes that cause budget and timeline overruns. Everything here is based on migration projects we’ve delivered for companies in fintech, healthcare, SaaS and e-commerce.

How much does AWS cloud migration cost?

The most common question we get. Here’s the honest answer: it depends on scope, but we can give you ranges based on dozens of completed projects.

Migration project costs (one-time)

These are partner engagement costs (assessment, architecture, IaC, migration execution, post-migration support). The AWS MAP programme can cover 70-80% of these costs for qualifying migrations.

Ongoing AWS infrastructure costs (monthly)

Does migration cost more than staying on-premise?

Short answer: the migration itself is a one-time investment. The ongoing cloud costs are typically 30-60% lower than on-premise TCO when you account for:

• Hardware refresh cycles (every 3-5 years)
• Data centre space, power, and cooling
• Ops team salaries for hardware management
• Over-provisioning for peak capacity (you pay for idle resources 24/7)
• Disaster recovery infrastructure (hot standby sites)

The break-even point is usually 6-12 months post-migration. After that, you’re saving money every month while getting better scalability, security, and deployment velocity.

For UK-based teams - particularly in regulated sectors like fintech in Edinburgh and Leeds or healthtech working with NHS systems - FCA operational resilience and Cyber Essentials Plus requirements typically push project costs toward the upper end of these ranges. Additional budget covers security controls, audit logging, and UK data residency in AWS eu-west-2 (London). That said, the compliance investment pays for itself: regulated UK companies we’ve worked with report fewer post-migration security findings during audits compared to teams that bolt compliance on after the fact.

Can a migration realistically be delivered in 6 weeks?

Yes, for a single application or a small set of tightly-coupled services. A focused replatform of one web app + its database from Heroku or on-premise to ECS Fargate + RDS is achievable in 4-6 weeks including assessment, PoC, migration and stabilisation. Larger estates require wave-based planning.

For detailed cost tables including hidden costs, on-premise vs AWS TCO comparison, and how to reduce costs with AWS funding programmes, see our AWS migration cost calculator with real numbers by company size.

What AWS cloud migration involves

AWS cloud migration is the process of moving applications, databases and infrastructure from your current environment (on-premise, colocation, another cloud provider, PaaS) to Amazon Web Services. The scope depends on your starting point and goals:

• Lift-and-shift - moving applications 1:1 onto EC2 or containers without code changes. Fastest and cheapest approach, but you don’t get the full benefits of cloud-native architecture.
• Re-platforming - migrating with adaptation to managed services (e.g. replacing self-hosted PostgreSQL with managed RDS, replacing cron jobs with EventBridge + Lambda).
• Re-architecting - rebuilding applications for cloud-native architecture: microservices, containers, serverless, event-driven patterns. Largest upfront effort, but delivers the best long-term results.

In practice, most migration projects combine these approaches. Critical workloads may need re-architecting, while internal tools can often be moved lift-and-shift.

Migration to AWS doesn’t end when your applications are running. It also includes building automation (CI/CD), monitoring, observability, security policies and an operating model for the team that will maintain the environment post-migration.

The 7R migration strategies

AWS defines seven migration strategies (the “7Rs”) that determine how each workload moves to the cloud. Choosing the right strategy per application is the single biggest decision affecting project cost, timeline and outcome.

Retire

Some workloads don’t need to migrate at all. During assessment, you’ll often discover applications that are redundant, unused or can be replaced by a SaaS product. Retiring them before migration reduces scope and cost. In our experience, 10-20% of workloads in a typical enterprise portfolio fall into this category.

Retain

Not everything should move right now. Workloads with complex dependencies, regulatory constraints or upcoming end-of-life can stay on-premise temporarily. Retain isn’t “never migrate” - it’s “not in this wave.” You document these workloads and plan a future migration path.

Rehost (lift-and-shift)

Moving applications 1:1 to EC2 or containers without code changes. The fastest approach: typical rehost migrations complete in days to weeks per application. You get cloud benefits (elasticity, pay-as-you-go) immediately but don’t optimise for cloud-native patterns. Good for applications with a 1-2 year remaining lifespan or when speed matters more than optimisation.

AWS Application Migration Service (MGN) automates rehost by continuously replicating servers to AWS and orchestrating cutover with minimal downtime. For specialised estates such as SAP, rehost is often the first step before a later S/4HANA conversion - see our SAP to AWS migration guide.

Relocate

Moving infrastructure at the hypervisor level - primarily relevant for VMware workloads moving to VMware Cloud on AWS. The application, OS and configuration remain identical. Useful when you need to vacate a data centre quickly without touching application stacks.

Replatform

Migrating with targeted adaptations to managed services. Examples: replacing self-hosted PostgreSQL with RDS, swapping cron jobs for EventBridge + Lambda, moving from self-managed Redis to ElastiCache. You keep the application architecture but offload operational burden.

Replatforming typically adds 2-4 weeks per workload compared to rehost, but reduces ongoing maintenance costs by 40-60%. For most mid-complexity applications, this is the sweet spot between effort and benefit.

Refactor / Re-architect

Rebuilding applications for cloud-native patterns: microservices, containers (ECS/EKS), serverless (Lambda), event-driven architecture (EventBridge, SQS, SNS). The most expensive and time-consuming approach, but delivers the best long-term results: independent deployments, horizontal scaling, reduced blast radius.

Reserve re-architecting for core business applications where you need capabilities that the current architecture can’t deliver: true horizontal scaling, multi-region deployment, or zero-downtime deployments.

Repurchase

Replacing custom-built software with a commercial SaaS product. Example: migrating a self-hosted CRM to Salesforce, or replacing a custom monitoring stack with Datadog. The application doesn’t move to AWS - it moves to a vendor. Include repurchase in your migration strategy for workloads where building in-house no longer makes business sense.

How to choose

In practice, most migration projects combine 3-4 strategies. A typical distribution for a 20-application portfolio:

• Retire: 3-4 applications
• Retain: 2-3 applications (migrate in next wave)
• Rehost: 5-7 applications (internal tools, legacy apps)
• Replatform: 5-8 applications (the majority)
• Refactor: 2-3 applications (core products)
• Repurchase: 1-2 applications

We determine the strategy per workload during the assessment phase based on business value, technical complexity, team capacity and timeline constraints.

We break down each of the seven strategies - when to choose it, what it costs, and the risk it carries - in the dedicated 7 Rs of AWS cloud migration guide.

AWS migration tools

AWS provides a suite of migration services that handle different aspects of the process. Knowing which tools exist helps you understand what’s automated vs. what requires custom engineering.

AWS Migration Hub

The central dashboard for tracking migration progress across all workloads. Migration Hub aggregates status from other tools (MGN, DMS, etc.) and provides a single view of which applications have been assessed, are in progress or are complete. It’s free - you only pay for the underlying migration tools.

Migration Hub also includes Strategy Recommendations: an automated assessment tool that analyses your on-premise servers and suggests the optimal migration strategy (rehost, replatform or refactor) based on application characteristics.

AWS Application Migration Service (MGN)

The primary tool for rehost (lift-and-shift) migrations. MGN installs a lightweight agent on source servers that continuously replicates data to AWS. When you’re ready to cut over, it launches target instances from the replicated data with minimal downtime (typically minutes).

MGN replaces the older CloudEndure Migration service and handles both Linux and Windows workloads. It supports test migrations (launch a copy without cutting over) so you can validate before committing.

AWS Database Migration Service (DMS)

Migrates databases with minimal downtime using continuous data replication (CDC - Change Data Capture). DMS supports homogeneous migrations (PostgreSQL → RDS PostgreSQL) and heterogeneous ones (Oracle → Aurora PostgreSQL) with the Schema Conversion Tool (SCT).

Key capability: DMS can keep source and target databases in sync during migration, allowing you to validate the target before switching traffic. This eliminates the need for long maintenance windows. For heterogeneous migrations, expect 2-4 weeks of schema conversion and testing.

For the full picture - Full Load vs CDC modes, replication instance sizing, common pitfalls, and how Database Savings Plans cut the cost of long-running CDC - see our dedicated AWS DMS guide.

AWS Schema Conversion Tool (SCT)

Analyses source database schemas and converts them to the target format. For PostgreSQL-to-PostgreSQL this is straightforward. For Oracle-to-Aurora or SQL Server-to-PostgreSQL, SCT identifies constructs that require manual intervention (stored procedures, proprietary extensions, data types).

SCT generates an assessment report showing what percentage of schema converts automatically and what needs manual refactoring. This is critical input for timeline and cost estimation.

AWS Transfer Family

Managed SFTP, FTPS and FTP service for migrating file-based workflows. If your legacy system relies on file transfers (batch processing, partner integrations), Transfer Family provides a drop-in replacement backed by S3 or EFS without changing client configurations.

Choosing the right tool combination

How do you choose the right AWS migration tool? Start with the workload type - each tool is designed for a specific migration scenario:

For most mid-scale migrations (5-20 applications), the combination of MGN (for servers) + DMS (for databases) + Migration Hub (for tracking) covers 80% of needs. The remaining 20% is custom automation built with Terraform and CI/CD pipelines.

Why teams migrate to AWS

Scalability and elasticity

AWS lets you scale resources up and down (vertically) based on demand. Instead of buying servers sized for peak traffic, you pay for what you actually use. ECS Fargate scales containers horizontally on demand. With ECS on EC2, Auto Scaling Groups adjust instance count to match traffic. This is particularly valuable for applications with seasonal traffic or unpredictable spikes.

Cost optimisation

Paradoxically, cloud can be more expensive than on-premise if you don’t manage costs consciously. But with proper configuration (right-sizing, Reserved Instances, Savings Plans, spot instances for workloads that tolerate instance loss) AWS is significantly cheaper than maintaining your own infrastructure sized for peak capacity. You also eliminate fixed costs: data centre maintenance, power, cooling, hardware replacement.

Security and compliance

AWS offers certifications that would be expensive and time-consuming to achieve on your own infrastructure: SOC 2, ISO 27001, HIPAA, PCI DSS. The shared responsibility model means AWS handles physical infrastructure security while you handle application-level configuration. Services like GuardDuty, Security Hub, WAF and KMS provide the building blocks for a secure environment that meets regulatory requirements.

Managed services ecosystem

Over 200 AWS services means you don’t need to build and maintain infrastructure components yourself. Managed databases (RDS, DynamoDB), queues (SQS), cache (ElastiCache), search indexing (OpenSearch), streaming (Kinesis) - each of these services is one less operational responsibility for your team.

The AWS migration process step by step

Every AWS cloud migration we deliver follows a similar pattern. Writing here from the perspective of an AWS partner delivering the migration, it typically consists of six phases. The order matters - skipping the environment assessment or PoC is the most common cause of budget and timeline overruns.

AWS cloud migration costs - what they consist of

The cost of migrating to AWS depends on several factors: environment complexity, chosen migration approach, compliance requirements and number of environments. Below I break down the main ongoing cost components after migration.

Compute (ECS Fargate / EKS / EC2)

Compute is typically the largest line item on your AWS bill. Platform choice directly affects cost:

• ECS Fargate - you pay per vCPU and memory per task. A typical web application (0.5 vCPU, 1 GB RAM) is ~$15-25/month per task. No instance management overhead.
• EKS - $0.10/h per cluster (~$73/month) plus node costs (EC2 or Fargate). EKS makes sense from 10+ microservices, or when you need the Kubernetes ecosystem for other reasons.
• EC2 - cheapest per-unit, but requires instance management. M6i.large (2 vCPU, 8 GB) is ~$70/month on-demand, ~$44/month with a 1-year Reserved Instance.

For most migrations we recommend ECS Fargate: it eliminates server management, scales automatically and is operationally simpler than EKS.

Databases (RDS, DynamoDB)

• RDS PostgreSQL/MySQL - db.m6g.large (2 vCPU, 8 GB) is ~$120-140/month. Multi-AZ (for high availability) doubles compute cost but is required for production.
• RDS Aurora - ~20% more expensive than standard RDS, but better performance and automatic failover. Makes sense when you need <1s failover.
• DynamoDB - pay-per-request model from $1.25 per million writes. For applications with predictable load, provisioned capacity is cheaper.

On top of that: storage (GP3 SSD from $0.08/GB/month), backups and cross-AZ data transfer.

Data transfer and networking

Data transfer is often a hidden cost that surprises teams after migration:

• Egress (data leaving AWS to the internet) - $0.09/GB after the first 1 GB. At 1 TB/month that’s ~$90.
• Cross-AZ transfer - $0.01/GB in each direction. Small per-request, but adds up to significant costs at high traffic volumes. This type of traffic should be minimised.
• NAT Gateway - $0.045/h (~$33/month) plus $0.045/GB of processed data. Required when private subnets need internet access.

Infrastructure as Code and automation

IaC implementation is a one-time investment in the migration project:

• Terraform module development - VPC, ECS, RDS, IAM, monitoring configuration. Typically 1-2 weeks of engineering work depending on complexity, with AI tooling assistance.
• CI/CD pipeline - GitHub Actions, GitLab CI or AWS CodePipeline. Build, test and deploy configuration. 1-2 weeks.
• Ongoing IaC maintenance - provider upgrades, new modules, configuration changes. An operational cost, but significantly lower than manual infrastructure management.

Funding - AWS MAP and PoC programmes

Funding programmes are a real way to lower the barrier to entry. For companies migrating from on-premise or another cloud environment, MAP can cover consulting costs, migration tooling and team training.

When AWS migration makes sense

Migrating to AWS is an investment that isn’t always justified. Here are situations where migration almost always delivers measurable returns:

• Rising infrastructure costs - if your hosting bill (Heroku, DigitalOcean, on-premise) is growing faster than revenue, AWS with proper configuration will reduce TCO by 30-60%.
• Compliance requirements - SOC 2, ISO 27001, HIPAA, NIS2 require infrastructure controls (at-rest and in-transit encryption, network isolation, audit logging) that are difficult or impossible to implement on many platforms.
• Scaling needs - if your application needs to handle traffic spikes (seasonality, marketing campaigns, events), elastic AWS scaling eliminates the need to maintain excess capacity.
• Stack modernisation - moving to containers (ECS/EKS), serverless (Lambda), managed databases (RDS/Aurora) reduces operational burden on the team.
• Multi-region presence - expanding to new markets requires presence in multiple regions. AWS has 33 regions globally, including Europe (Frankfurt, Ireland, Paris, Stockholm).

If you have a small application with low traffic, no compliance requirements and a 2-3 person team, consider whether the simplicity of your current solution is worth the premium. Migration makes sense when the benefits (cost, security, scalability) outweigh the one-time effort.

Read our Heroku to AWS migration case study to see what a real project looks like, from audit through migration to business outcomes.

If your company is considering migrating from another PaaS, see our post on migrating from Heroku to AWS. I cover service mapping and common mistakes in detail there.

Common AWS cloud migration mistakes

After delivering dozens of migration projects, these are the patterns that consistently cause timeline overruns, budget surprises or post-migration instability.

1. Skipping the assessment phase

Teams eager to start migrating often jump directly to building infrastructure. Without a proper assessment, you discover dependency problems mid-migration: a service that depends on an internal API you haven’t migrated yet, or a database connection that assumes single-digit millisecond latency between components.

Fix: Invest 3-5 days in assessment. Map every application, its dependencies, data flows and SLA requirements. The dependency map saves weeks of troubleshooting later.

2. Not accounting for data transfer costs

Data transfer out of AWS (egress) costs $0.09/GB. Teams that don’t model egress during planning get surprised by bills 2-3x higher than expected. This is especially common when applications communicate with systems still on-premise or with third-party APIs.

Fix: Model egress costs during PoC. Use VPC endpoints for AWS service traffic (eliminates NAT Gateway charges for S3, DynamoDB, etc.). Consider Savings Plans for predictable compute, and architect to minimise cross-AZ traffic.

3. Treating cloud like a data centre

Deploying oversized EC2 instances that run 24/7 and never scale - essentially recreating on-premise patterns in the cloud. You pay cloud prices without cloud benefits.

Fix: Right-size from day one. Use Auto Scaling Groups. Schedule non-production environments to shut down outside business hours (saves 65% on dev/staging). Adopt Savings Plans or Reserved Instances for baseline load.

4. Big-bang migration

Attempting to migrate everything at once over a single weekend. When something goes wrong (and it always does), the blast radius is your entire stack. Troubleshooting is exponentially harder when multiple systems fail simultaneously.

Fix: Migrate in waves. Start with the lowest-risk workload, validate, then proceed to the next. Each wave builds confidence and reveals patterns you’ll reuse.

5. Neglecting security from the start

Security added as an afterthought leads to wide-open security groups, overly permissive IAM policies and unencrypted data stores. Retrofitting security is 3-5x more expensive than building it correctly from the start.

Fix: Define security baseline before migrating the first workload. Implement least-privilege IAM from day one. Encrypt everything at rest and in transit. Enable CloudTrail, GuardDuty and Security Hub from the start. Security is cheaper when it’s built into the foundation than when it’s patched on later.

Frequently asked questions

How we can help

We’ve delivered AWS migrations for companies across industries and starting points: from Heroku, DigitalOcean, on-premise and other cloud providers. Every project ships with full infrastructure as code (Terraform), automated CI/CD and operational documentation.

Our cloud migration services cover the entire process: from initial environment assessment, through PoC and infrastructure build, to post-migration support. Target architecture is designed following the AWS Well-Architected Framework. We’ve delivered AWS migrations for UK teams since 2010 - see our UK cloud and DevOps services.

For startups built with AI coding tools (Lovable, Cursor, Bolt) on Supabase/Vercel, our SmartVibe productised migration delivers a fixed-price, full-stack transition to production AWS in under four months.

Planning an AWS migration?

Book a free 30-minute call. We'll discuss your setup and prepare an initial cost comparison.

Book a call Send us a message