AWS migration, end to end: the 7 Rs, the MAP phases, the tools and an honest timeline.

IWhat an AWS migration involves

It is a planned program, not an ad-hoc rebuild. The compute is rarely the hard part. The data, the dependencies and the cutover are.

Common triggers: a Heroku or DigitalOcean bill that no longer scales, an Azure or GCP commitment ending, a data-centre lease coming due, a licence renewal, or a decision to consolidate on one cloud. The trigger is usually commercial; the work is technical.

A real migration touches five layers: compute (servers, containers, functions), data (databases, object and file storage, and the replication that keeps them in sync until cutover), networking (VPCs, DNS, load balancers, links back to anything you keep), identity and security (IAM, secrets, encryption, guardrails), and operations (monitoring, CI/CD, backups, runbooks).

The best predictor of a smooth migration is how well you understand the current system first: what runs where, what talks to what, how much data moves, and the real recovery targets. That discovery work is what separates a short rehost from a long archaeology project.

IIThe 7 Rs: what to do with each workload

You do not migrate "the system". You migrate a portfolio, and each workload gets a decision. Run every application through the 7 Rs during assessment and you have a plan.

• Retire: Turn it off. Discovery almost always finds workloads nobody uses. Every retired workload is migration cost you never pay.
• Retain: Leave it where it is for now (pending replacement, data residency, mid-amortisation) and plan the hybrid link. Make it a decision, not a default.
• Rehost: Lift and shift with minimal change, usually with AWS Application Migration Service (MGN) replicating servers into EC2. Fastest way off the source.
• Relocate: Move a virtualised or containerised layer as it is, for example a Kubernetes cluster to EKS with minimal manifest changes.
• Repurchase: Drop self-hosted software for a SaaS equivalent and move the data out. Right for commodity workloads.
• Replatform: Move while swapping the undifferentiated work for a managed service: self-managed Postgres to RDS or Aurora, a container on a VM to ECS on Fargate. The code barely changes; patching and failover go away.
• Refactor: Re-architect for cloud-native patterns. Biggest long-term payoff and biggest cost and risk. Do it selectively, after you are off the old platform.

IIIThe MAP phases: Assess, Mobilize, Migrate and Modernize

The Migration Acceleration Program (MAP) is AWS's methodology for larger migrations, delivered with AWS Migration Competency Partners. It runs in three phases with a go or no-go gate between each.

AWS describes MAP on its program page as tools, training, partner expertise and financial investments, in a three-phase framework.

IVHow MAP funding works, honestly

AWS wants your long-term usage, so it co-invests in getting you there. Here is what that means in practice, and the conditions.

Partner-filed funding: AWS says MAP helps offset initial migration costs. Your matched partner files it when the migration qualifies and AWS approves. For startups this is typically $50K to $150K. Depends on the workload; AWS approves. It is not a blank cheque: MAP is built for migrations with meaningful ongoing AWS spend, so a single small app may not qualify. A good partner tells you which case you are in before you commit. The rules, phases and who files are in our guide to the AWS MAP program.

AWS Activate: separate from MAP, and you apply yourself. Activate Founders gives self-funded startups $1,000 to start, up to $5,000. Activate Portfolio gives up to $200,000 with the Org ID from your VC, accelerator or angel group, if it is an Activate Provider. A consulting partner cannot file Activate for you.

CloudRoute's role is the match: one partner who can both run the migration and file the funding, so it actually gets claimed. Startups pay CloudRoute nothing. Partners pay CloudRoute a monthly membership plus 10% of AWS-approved funding.

VThe AWS migration toolchain in 2026

You do not need to operate these yourself if a partner runs the migration, but knowing what does what makes you a better buyer. Several tools changed in the last year.

• AWS Application Migration Service (MGN): The default rehost engine. An agent replicates each source server into AWS continuously; at cutover you launch it on EC2 with minimal downtime.
• AWS Database Migration Service (DMS): Moves databases with a full load and, where the source allows it, ongoing change data capture so the source stays live until cutover.
• AWS Schema Conversion Tool and DMS Schema Conversion: Convert schemas, stored procedures and SQL between different engines (for example Oracle to Aurora PostgreSQL) and report what needs manual rework.
• AWS Transform: AWS's agentic service for migration and modernisation planning and execution. AWS Migration Hub and Application Discovery Service closed to new customers on November 7, 2025, and AWS points new users to AWS Transform.
• Migration Evaluator: Builds a business case comparing current costs with AWS, at no cost.
• AWS DataSync and Transfer Family: Bulk movers for files and objects (DataSync) and SFTP workflows (Transfer Family). For physical transfers, AWS points new customers to AWS Data Transfer Terminal; Snowball Edge is no longer open to new customers.
• AWS Startup Advisor: For startups moving from GCP or Heroku, AWS Startup Advisor generates a migration plan (service mapping, cost estimates, IaC templates, a runbook). It does not move data for you.

VISource platforms: what moves where

The target depends on where you start. The pattern is the same everywhere: compute to containers or serverless, databases to RDS or Aurora, storage to S3. The difficulty is almost always the data.

VIITimeline and cost

Every migration is different. These are the drivers, not promises.

Timeline is driven by estate size, data volume and how much refactoring is in scope, not by AWS itself. A small PaaS app with one database can move in weeks. A mid-size estate with dozens of servers and several databases is a multi-month program. Large, regulated estates or heavy database conversions run longer and in several waves. The pilot in Mobilize is what turns these estimates into your real numbers.

Cost has two parts people mix up: the one-time project (discovery, landing zone, execution, partner time) and the ongoing AWS bill after you land. MAP is designed to help with the first. The second is what your assessment should model, with right-sizing and Savings Plans applied. See aws migration cost.

Downtime per workload depends on the data. With continuous replication (MGN for servers, DMS CDC where the database allows it), cutover is a short window for the final sync and checks. Where replication is not possible, it is the time a dump and restore takes.

VIIIRisks, downtime and rollback

A credible plan names its failure modes and has an answer for each.

• Cutover downtime: Continuous replication moves bulk data ahead of time. The risk is underestimating the final sync and validation, which is what the pilot measures.
• Data consistency: The target must be complete and correct at the cutover instant, with no lost writes. Use replication validation, reconciliation checks and a defined cutover point.
• Schema conversion: Oracle and SQL Server conversions never fully automate. The conversion report should size the manual backlog before you commit a date.
• Hidden coupling: Undocumented dependencies (a hard-coded IP, a shared file mount, a service calling a database it should not) surface during discovery or, worse, at cutover.
• No rollback plan: Until cutover is validated, keep the source running and reversible: replication you can reverse or DNS you can point back. Rehearse it.