Cloud Tracks · Migrating to AWS

Migrating to AWS

Amazon Web Services (AWS) is the biggest district in Cloudville, and it has a well-worn road for newcomers. That road has a name — the Migration Acceleration Program — plus a framework to plan by and a toolbox for every step. This page walks you down that road from first assessment to a running, optimized app.

The big picture: MAP, CAF, and the 7 R’s

☺ Like you’re 10: AWS gives you three things — a moving program with steps, a checklist of things to think about, and a menu of ways to move each item.

Before touching a single tool, it helps to know AWS speaks in three vocabularies you will hear constantly. Think of them as the plan (MAP), the planning lens (CAF), and the move options (7 R’s). They all fit the same migration journey you already learned. (This road assumes you’re coming from your own data center; if you’re already running in another cloud, the cloud-to-cloud path differs.)

• MAP — the Migration Acceleration Program, a proven, three-phase methodology AWS built from thousands of real migrations. It also comes with funding credits that an AWS partner can file on your behalf to offset migration costs.
• CAF — the Cloud Adoption Framework, a set of six lenses (called perspectives) for checking whether your organization — not just your servers — is ready.
• The 7 R’s — the seven ways to move any one application, which you can read about in depth on the 7 R’s page.

The rest of this page takes each of the three in turn — the phases (MAP), the readiness lenses (CAF), and the move options (7 R’s) — then hands you the toolbox that executes them.

MAP: the three phases

☺ Like you’re 10: First you count and plan (Assess), then you build the new house and pack the truck (Mobilize), then you actually drive over and unpack (Migrate & Modernize).

MAP organizes every migration into three phases. Nutty the Squirrel scouts the first one, Benny builds and moves in the last two.

The table is the summary; the three subsections below are what actually fill your weeks.

Phase 1 — Assess

☺ Like you’re 10: Count everything you own and work out whether moving will really save money.

Assess answers two questions: what do we have and is moving worth it. You inventory every server and app, map their dependencies, gauge how ready each one is for the cloud, and turn all of that into a business case — the money story that shows leadership the cloud bill will beat the cost of staying put. Nothing moves in this phase; you’re building the map the rest of the program follows.

Phase 2 — Mobilize

☺ Like you’re 10: Fix the problems you found, teach the team, and build the safe new home before any furniture arrives.

Mobilize closes the gaps Assess exposed. You build skills, set up the operating model, and — most importantly — stand up a secure landing zone: your pre-built, well-governed home in AWS, with accounts, networking, and security guardrails ready before a single workload lands. A small pilot migration often happens here to prove the path and sharpen the runbook.

Phase 3 — Migrate & Modernize

☺ Like you’re 10: Move the boxes in small batches, then, once they’re safe, make things nicer and cheaper.

Now you execute — moving applications wave by wave so a problem only ever hits one small batch. The AWS mantra here is migrate first, modernize when you’re ready: get the workload running safely, then optimize it for cost and performance, sometimes modernizing (replatforming or refactoring) as a follow-up rather than a risky all-at-once leap.

CAF: the six perspectives

☺ Like you’re 10: Moving isn’t just about boxes. Is your family ready? Who pays the bills? Are the doors locked? CAF makes you check all of that, not just the trucks.

The Cloud Adoption Framework groups readiness into six perspectives. The first two are about people and money; the last four are technical. A migration that only thinks about servers and forgets the human ones tends to stall.

The two non-technical perspectives: Business & People

☺ Like you’re 10: Make sure the move helps the whole company and that the people are ready for it.

• Business — do the cloud investments actually serve business goals?
• People — culture, skills, and org structure; the bridge between tech and business.

These are the perspectives migrations most often skip — and the ones most likely to stall a move that is otherwise technically fine.

The four technical perspectives: Governance, Platform, Security & Operations

☺ Like you’re 10: Who sets the rules, who builds it, who locks the doors, and who keeps it running.

• Governance — managing initiatives and risk while maximizing benefit.
• Platform — building the scalable, hybrid cloud platform and modernizing workloads.
• Security — confidentiality, integrity, and availability of your data.
• Operations — running the services day to day at the level the business needs.

The 7 R’s, as AWS frames them

☺ Like you’re 10: For each thing you own, you pick one of seven moves — from “throw it away” to “rebuild it brand new.”

Every application gets exactly one of seven strategies — the 7 R’s — and AWS orders them roughly from least to most effort. Here they are in three natural clusters; the dedicated 7 R’s page goes deeper on each.

The “don’t move it” R’s: Retire & Retain

☺ Like you’re 10: Some stuff you throw out, and some stuff you just leave where it is for now.

• Retire — switch off applications no one needs any more, so you never pay to move them. Discovery often reveals surprising numbers of these.
• Retain — deliberately keep an app where it is (on-premises) for now, because it isn’t ready, isn’t worth moving yet, or is due to be replaced.

The “move it as-is” R’s: Rehost & Relocate

☺ Like you’re 10: Pick the whole thing up and set it down in the cloud without changing it.

• Rehost — “lift and shift”: move a server to AWS unchanged (for example, onto EC2 with AWS Application Migration Service (MGN)). Fast and low-risk.
• Relocate — move infrastructure without buying new hardware or changing how you operate it — for example, lifting a whole VMware estate with Amazon Elastic VMware Service (EVS).

The “change it as you move” R’s: Repurchase, Replatform & Refactor

☺ Like you’re 10: While you move, you can swap it for something you buy, tweak it a little, or rebuild it a lot.

• Repurchase — drop the old app and move to a different product, often a SaaS subscription that replaces it outright.
• Replatform — “lift, tinker, and shift”: make a few cloud optimizations without changing the core architecture (for example, moving a self-managed database onto a managed database service).
• Refactor — re-architect the application to make the most of cloud-native features; the most effort, but the most reward.

The AWS toolchain, phase by phase

☺ Like you’re 10: AWS has a special tool for each job — one to count your stuff, one to move furniture, one to carefully carry dishes, and a giant box for when you have way too much.

Here is Benny’s toolbox, mapped to the phases. Names matter — and AWS reshuffled several of them in 2025–2026, folding discovery, assessment, and tracking into a new umbrella service called AWS Transform. Notably, AWS Transform MGN (formerly AWS Application Migration Service) is the successor to the older CloudEndure Migration (AWS acquired CloudEndure in 2019, and its technology became MGN). For a broader, provider-neutral view, see the tools page.

The table is the quick reference. Below, the same tools are grouped by the job they do, with a note on when to reach for each.

Discovery & assessment tools

☺ Like you’re 10: The tools that count your stuff and add up what the move will cost.

• AWS Application Discovery Service — collects an inventory of your on-premises servers, their specs, and their dependencies. Reach for it first, in Assess.
• Migration Evaluator — turns that discovery data into a cost projection, so you can justify the move with numbers rather than a hunch.
• AWS Migration Hub — a single dashboard that tracks migration progress across the other tools and accounts, through all three phases.

Server migration tools

☺ Like you’re 10: The tools that pick up a whole computer and set it down in AWS.

• AWS Application Migration Service (MGN) — replicates whole servers and cuts them over to run natively on AWS. Use it for a rehost; it’s the CloudEndure successor.
• Amazon Elastic VMware Service (EVS) — lifts an entire VMware estate to AWS with no re-architecting; it replaced VMware Cloud on AWS, which AWS no longer sells (2024). Use it for the “relocate” R when you want to keep running VMware as-is.

Database migration tools

☺ Like you’re 10: The tools that move the data, and — if needed — translate it for a different kind of database.

• AWS Database Migration Service (DMS) — moves data between databases with little downtime, even while the source keeps running. Use it whenever you’re copying a live database.
• AWS Schema Conversion Tool (SCT) — converts a database’s schema and code to a different engine (for example, Oracle → PostgreSQL). You only need it when the target engine differs from the source; same-engine moves skip it.

Data-transfer tools

☺ Like you’re 10: The tools for moving big piles of files — over the wire, or in a giant shipped box.

• AWS DataSync — moves large file/object data over the network into S3, EFS, or FSx. Use it when the network can carry the data in reasonable time.
• AWS Snow Family (Snowball) — retiring (closed to new customers Nov 2025; support ends Dec 2026 — AWS now points bulk moves to DataSync and its Data Transfer Terminal locations). Historically the answer when there is too much data to send over a wire. Use it when the online transfer would take too long.
• AWS Storage Gateway — gives on-premises apps low-latency access to cloud storage during the transition, bridging old and new while you move.

Landing-zone tools

☺ Like you’re 10: The tools that build the safe, well-organized new home before anything moves in.

• AWS Control Tower + Landing Zone Accelerator + AWS Organizations — together they set up a governed multi-account foundation with guardrails baked in. Stand this up in Mobilize, before any workload lands.

A worked example: rehost, then optimize

☺ Like you’re 10: First move the house exactly as-is so nothing breaks (fast). Once it’s safely there, swap the old fridge for a cloud one and turn off lights you don’t need (cheaper).

Say Fort Rusty runs a small online store: one web/app server and one MySQL database, sitting on aging hardware. A sensible, low-risk path is rehost-then-optimize — move it as-is, prove it works, then improve.

Why rehost first, optimize later

☺ Like you’re 10: Two big changes at once means two things that can break at once.

Rehosting changes where the app runs without changing how it’s built, so there’s very little to go wrong on the day. Once it’s stable in AWS, each optimization becomes a separate, reversible step — you’re never risking the move and the modernization in the same breath. That’s the same “migrate first, modernize when ready” rule from MAP’s third phase.

Phase by phase

☺ Like you’re 10: The same four steps — count, build, move, then improve.

• Assess — run Application Discovery Service to confirm the two servers and their dependency (the app talks to the database), and use Migration Evaluator to show the cloud bill will be lower than the hardware refresh.
• Mobilize — stand up a landing zone with Control Tower so the new account has security guardrails from day one.
• Migrate (rehost) — use MGN to replicate the app server and cut it over to an EC2 instance. Use DMS to copy the MySQL data into the cloud with minimal downtime; because it’s the same engine, no schema conversion (SCT) is needed.
• Optimize (replatform) — once stable, move the database from a self-managed instance to a managed database service (like Amazon RDS) so AWS handles backups and patching, and right-size the EC2 instance to stop paying for unused capacity.

The store moved quickly and safely first, then got cheaper and easier to run — without ever risking a big, all-at-once leap.

Check your answers

1. Assess, Mobilize, and Migrate & Modernize.
2. AWS Application Migration Service (MGN).
3. When you have too much data to move over the network in reasonable time — Snowball ships a physical device, while DataSync moves data online over the wire. (Note: the Snow Family closed to new customers in Nov 2025 and retires end-2026 — DataSync and AWS Data Transfer Terminal are the current answers.)
4. Any two of: Business and People (the others — Governance, Platform, Security, Operations — round out the six).