The Journey — Process & Frameworks
Moving to the cloud is not one giant leap — it is a walk along a well-marked trail with four rest stops. In this lesson you will learn the migration lifecycle: assess what you have, get ready, move and improve, then keep things running smoothly. You will also meet the big vendor frameworks (AWS, Azure, Google) and discover they all tell the same story.
Imagine your family is moving from an old house (Fort Rusty) to a bright new city (Cloudville). You don't just grab everything at once. First you walk through every room and count your stuff, then you pack a few boxes as a test, then you move room by room, and finally you unpack, hang the pictures, and make the new place feel like home. The trail has four stops — and every good moving company follows the same map.
The migration lifecycle: one trail, four stops
☺ Like you're 10: Every move has the same four steps — look around, get ready, carry the boxes, then settle in. Learn those four and you understand every migration.
A migration lifecycle is simply the ordered set of stages a project passes through, from "should we even do this?" to "we've turned off the old servers." AWS packages this into its Migration Acceleration Program (MAP), which names three big phases — but it is easiest to think in four stops along a trail:
- Assess — understand what you have and whether the move makes sense.
- Mobilize — get ready: build a plan, fix skill gaps, and prepare a safe place to land.
- Migrate & Modernize — actually move the workloads, improving them where it's worth it.
- Operate & Optimize — run the new environment and keep tuning cost, speed, and security.
The trail is a loop, not a dead end. Once you are operating in Cloudville, you keep assessing and improving — the cloud rewards continuous tidying. The four stops below walk through each phase and the real activities inside it.
Stop 1 — Assess: count before you pack
☺ Like you're 10: Before packing, walk through every room and write down what you own — and which things are secretly tied together, like a lamp plugged into a hidden socket.
This is Nutty's favorite stop. You cannot move what you cannot see, so the Assess phase answers a simple question — what exactly do we have, and is moving it worth it? — before anyone touches a workload. It produces the hard facts that every later decision leans on.
Discovery & dependency mapping
☺ Like you're 10: First you count every box, then you find the hidden strings tying some boxes to others.
Discovery means automatically scanning your data center to build an inventory of servers, applications, and databases — often with lightweight agents installed on machines, or agentlessly by watching network traffic. Good discovery captures not just what each thing is, but how big it is and how hard it works (CPU, memory, and storage usage), which later feeds right-sizing in the cloud. Alongside it comes dependency mapping: figuring out which apps talk to which, so you don't move a website and leave its database behind. Those maps are exactly what wave planning later uses to decide which apps must travel together.
Portfolio assessment & rationalization
☺ Like you're 10: Sort your stuff into keep, upgrade, and throw-away piles before you pack.
With the inventory in hand, you review every application and decide its fate. Rationalization means trimming the pile: retire what nobody uses, consolidate duplicates, and keep what still earns its space — every app you don't move is one you never have to pay to run again. This is also where you choose a migration strategy for each surviving app; see the 7 R's (rehost, replatform, refactor, and the rest).
Business case & TCO
☺ Like you're 10: Add up what the old house really costs — not just rent, but heating, repairs, and your time — then compare it to the new one.
TCO (Total Cost of Ownership) is the full cost of running something, not just the sticker price: hardware, power, cooling, data-center space, software licenses, and the people who maintain it. A business case compares today's TCO with the expected cloud cost — plus the harder-to-count benefits like speed, security, and reliability — to prove the move is worth it. (Sol the Sloth loves this slow, careful math.)
Readiness & risk review
☺ Like you're 10: Flag the fragile, precious things that will need extra care on moving day.
Finally, you look for the workloads that will be tricky, sensitive, or risky to move — anything with strict compliance rules, heavy dependencies, ancient technology, or no appetite for downtime. Naming these risks early means they get the careful planning (and the later, more-practised waves) they deserve, instead of surprising you at 2 a.m.
The Assess phase produces two treasures: a complete inventory (what you have) and a dependency map (how it's connected). Skip these and every later step turns into a guessing game.
Stop 2 — Mobilize: get ready to move
☺ Like you're 10: Before the truck arrives you rent it, learn to drive it, and get the keys to the new house. Mobilize is all the "get set" work.
Mobilize is where planning becomes concrete — you build the foundations, the schedule, and the skills so that the actual move is boring, in the best possible way. Four pieces do the heavy lifting.
The landing zone
☺ Like you're 10: The new house, cleaned and wired, with the locks already changed — before you carry in a single box.
A landing zone is a pre-built, secure, well-organized cloud environment ready to receive workloads. It bakes in the essentials up front — accounts and how they're structured, networking, identity and access, logging, and security guardrails — so every wave lands in a safe, consistent home instead of a hand-made one. Build it once, well, and you never have to retrofit security onto a hundred apps that have already moved.
Wave planning
☺ Like you're 10: Split the big move into small batches, and move the easy batch first to practise.
Wave planning is grouping applications into waves (batches) that move together. You rarely move everything at once; instead you start with a small, low-risk wave, learn from it, and roll the lessons into the next. Related apps that depend on each other usually travel in the same wave, so their constant chatter doesn't have to cross the slow link between Fort Rusty and Cloudville. This is a craft in its own right — the dedicated Wave Planning lesson covers grouping, sequencing, sizing, and running a wave end to end, so we only summarize it here.
Pilot / proof of concept
☺ Like you're 10: Pack and move one test box first, to make sure your plan actually works.
Mobilize runs a pilot (also called a proof of concept, or PoC) — moving one or two real workloads to prove the approach works before you scale up. A good pilot is small and non-critical: its job isn't to move something important, but to prove that the landing zone, the tools, and the team's runbook all behave. It's the packing-a-test-box moment, and it turns unknowns into knowns while the stakes are still low.
People, skills & tooling
☺ Like you're 10: Make sure everyone knows how to drive the truck before moving day.
Mobilize also closes the gaps in people and skills — training the team, defining who owns what, and setting up the tooling and automation (including Infrastructure-as-Code) that will move each wave quickly and repeatably. The more of the move you automate now, the faster and safer every later wave becomes.
Pretend you're moving 12 apps. On paper, sort them into 3 waves. Put the simplest, least-connected app in Wave 1 (your pilot). Group any apps that share a database into the same wave. Write one sentence explaining why your Wave 1 choice is the safest place to start.
Stop 3 — Migrate & Modernize: carry the boxes
☺ Like you're 10: Now you actually move — and while you're at it, you throw out the broken chair and buy a nicer one instead of hauling junk to the new house.
This is Benny's stop, where workloads finally travel from Fort Rusty to Cloudville. It has two flavors that often blend together, and every wave runs the same tight loop from copy to cutover.
Migrate vs Modernize
☺ Like you're 10: Move it as-is, or make it better on the way.
- Migrate — move the workload with little or no change (a "lift and shift"). Fast and low-risk.
- Modernize — improve the workload as part of the move, for example repackaging it into containers or serverless functions. More effort, bigger payoff. Mira the Butterfly leads this work; see modernization.
Most estates do both: rehost the simple, stable apps to get them off the old hardware quickly, and modernize the few where the extra effort clearly pays back. Which app gets which treatment was decided back in Assess with the 7 R's.
The per-wave mini-cycle
☺ Like you're 10: Every batch follows the same little checklist, over and over.
Each wave marches through a repeatable mini-cycle. First comes migration execution — building the target environment and copying the data across, often with continuous replication so the cloud copy stays in sync with the live system right up to the switch. Then testing & validation asks the crucial question: does it actually work correctly in the cloud, with the right data? Only a wave that passes moves on to cutover; the rest of this section walks the steps that follow.
Cutover
☺ Like you're 10: The moment you flip the switch and everyone starts using the new place.
Cutover is the moment you switch real users from the old system to the new one. It's the highest-stakes step in the wave, which is why it is rehearsed first, scheduled into a maintenance window, and always paired with a written rollback plan. How you flip the traffic — all at once, or gradually — is a design choice of its own, one that wave planning and the provider tracks explore in depth.
Hypercare
☺ Like you're 10: Right after moving in, watch everything extra-closely for a few days.
Right after cutover comes hypercare: a short period of extra-attentive support where the team watches the new system closely and fixes hiccups fast. Most problems surface in the first hours or days, so hypercare is how you catch them before your users do.
Decommissioning
☺ Like you're 10: Once the new place is definitely working, turn off the old one so you stop paying for it.
Once a workload is confirmed healthy, you perform decommissioning — safely turning off and retiring the old servers so you stop paying for them. Skipping this quietly wastes money: the whole point of moving was to stop feeding the old data center, and a forgotten server keeps billing forever. Make "retire the source" the official last step of every wave.
Don't decommission the old system the instant cutover finishes. Keep it available (but idle) through hypercare so you have a rollback — a way to switch back — if something goes wrong. Turning off Fort Rusty too early is a favorite gremlin trick.
RTO & RPO: two words that guide the whole move
☺ Like you're 10: How long can it be broken, and how much recent work can you afford to lose?
These two measures decide how careful your cutover must be:
| Term | Question it answers | Plain meaning |
|---|---|---|
| RTO — Recovery Time Objective | How long can we be down? | The maximum acceptable time to get a system back up. An RTO of 1 hour means users can't be offline longer than an hour. |
| RPO — Recovery Point Objective | How much data can we lose? | The maximum acceptable amount of recent data loss, measured in time. An RPO of 5 minutes means you can't lose more than the last 5 minutes of data. |
Think of a video game: RTO is how long it takes to restart after a crash; RPO is how far back your last save point was. A critical banking app needs both very small; a hobby blog can tolerate much larger numbers. These targets shape how you replicate data and plan the cutover — Ellie the Elephant leans on them in data migration.
Stop 4 — Operate & Optimize: settle in and tidy up
☺ Like you're 10: You've moved in — now you arrange the furniture, learn where the light switches are, and slowly make the place cheaper and comfier to live in.
Migration doesn't end when the boxes arrive. In this ongoing phase you run the new environment day-to-day and keep improving it. Three habits matter most.
Optimize cost (FinOps)
☺ Like you're 10: Turn off the lights in empty rooms and pick right-sized furniture so you don't overpay.
In the cloud you pay for what you use, so waste is easy — and expensive. Cost optimization means right-sizing resources (matching each workload to the smallest machine that comfortably runs it), shutting down idle things, and committing to capacity you'll use long-term in exchange for a discount. Doing this as a continuous team habit — measure, question, adjust — is called FinOps. Sol the Sloth keeps the receipts.
Security, performance & reliability
☺ Like you're 10: Keep checking the locks, the speed, and that nothing falls over.
Operating well also means continuously tightening security, improving performance, and increasing reliability — patching, monitoring, tuning, and building in redundancy so the new home is safer and steadier than the old one ever was. The cloud makes these changes easy, which is exactly why you're expected to keep making them.
Why the trail loops back
☺ Like you're 10: A tidy house never stays tidy by itself — you keep looking around and improving.
Because the cloud lets you change things easily, optimization is never "done" — which is why the trail loops back to Assess. You reassess what you're running, spot the next thing worth improving or modernizing, and go around again. A migration ends; the tidying never quite does.
The vendor frameworks: same trail, different signposts
☺ Like you're 10: Three different moving companies wrote three different maps — but if you lay them side by side, they all point down the exact same path.
Each big cloud provider publishes a Cloud Adoption Framework (CAF) — a guidebook of best practices for moving to and thriving in their cloud. They use different words, but the shape is identical, as this side-by-side shows:
| Trail stop | AWS | Microsoft Azure | Google Cloud |
|---|---|---|---|
| Assess | Assess (MAP) | Strategy + Plan | Assess |
| Mobilize | Mobilize (MAP) | Ready (landing zone) | Plan |
| Migrate & Modernize | Migrate & Modernize (MAP) | Adopt (Migrate & Modernize) | Deploy |
| Operate & Optimize | Operate & Optimize | Govern + Manage | Optimize |
Under those shared stops, each provider adds its own detail worth knowing.
AWS: CAF + MAP
AWS CAF looks at readiness through six perspectives: Business, People, Governance, Platform, Security, and Operations. The first three are about people and process; the last three are about technology. Its migration engine is the three-phase MAP (Migration Acceleration Program) — Assess, Mobilize, Migrate & Modernize — the very phases this lesson is built around. Go deeper in the AWS track.
Azure CAF
Azure CAF walks through Strategy → Plan → Ready → Adopt, wrapped by two ongoing disciplines, Govern and Manage. "Ready" is where you build the landing zone; "Adopt" is Migrate & Modernize. Go deeper in the Azure track.
Google Cloud Adoption Framework
Google Cloud Adoption Framework keeps it to a tidy four-phase path: Assess → Plan → Deploy → Optimize. Go deeper in the Google Cloud track.
The takeaway: learn the four-stop trail once, and you can read any vendor's map. Want to go even deeper? Browse the tools that automate discovery, replication, and cutover.
Every framework says the same thing: understand, prepare, move, improve — then keep improving. The vocabulary changes; the journey doesn't.
Professor Owl: Today's map has four stops: Assess, Mobilize, Migrate & Modernize, Operate. Nutty, where do we begin?
Nutty: Assess! I already counted every box in Fort Rusty and drew lines showing which ones are tied together. Ninety-four apps, and twelve are secretly holding hands with the billing database.
Gizmo: Boooring. Skip all that counting — just throw everything on one truck tonight and floor it to Cloudville! Big bang!
Timmy: Fact-check: that's how you lose the billing database and blow your RPO. We move in waves, test each one, then cut over — with the old house still standing in case we need to roll back.
Professor Owl: Precisely. And notice, Gizmo — AWS, Azure, and Google all wrote it down the same way. There is no shortcut around the trail.
Nutty: Count before you pack. Always.
1. Name the four stops of the migration trail, in order. 2. What two things does the Assess phase produce, and what is a landing zone? 3. In plain words, what's the difference between RTO and RPO? 4. Why do the AWS, Azure, and Google frameworks all count as "the same trail"?
Check your answers
- Assess → Mobilize → Migrate & Modernize → Operate & Optimize (and it loops back to Assess).
- Assess produces an inventory (what you have) and a dependency map (how it's connected). A landing zone is a pre-built, secure, organized cloud environment ready to receive workloads — the new house cleaned and wired before the boxes arrive.
- RTO is how long you can be down (recovery time); RPO is how much recent data you can afford to lose (recovery point). Restart speed vs. last save point.
- They use different words but follow the identical shape — understand, prepare, move, then keep improving. AWS's Assess/Mobilize/Migrate, Azure's Strategy/Plan/Ready/Adopt/Govern/Manage, and Google's Assess/Plan/Deploy/Optimize all map onto the same four stops.