Migration Foundations · Best Practices

Best Practices

A great cloud migration is not luck — it is a set of habits repeated on purpose. Assess before you move, prove the plan on something small, automate the boring parts, and never leave home without a way back. This page gathers the proven habits that separate calm migrations from chaotic ones, and shows you not just what each habit is but why it matters and how to actually do it.

Assess and rationalize before you move

☺ Like you’re 10: Before you pack, walk through every room and count your stuff. You can't move boxes you didn't know you owned.

The very first best practice is to assess and rationalize the portfolio before touching anything. A portfolio is simply the full list of your applications and servers. Everything downstream — the business case, the waves, the budget — is built on this foundation, so a shaky assessment makes every later step shaky too. Nutty the Squirrel calls it "count before you pack." Skipping it is the classic mistake covered in anti-patterns.

Take inventory and map dependencies

Why it matters: you cannot plan a move around apps you don’t know exist, and the dependency you miss is the one that breaks a cutover. How to do it: good discovery produces two artifacts — an inventory (every app and server) and a dependency map (which apps talk to which). The dependency map is what later lets you group tightly-coupled apps into the same wave instead of splitting them across a slow, costly cloud/on-prem boundary.

☺ Like you’re 10: The dependency map is like knowing which toys are always played with together, so you pack them in the same box.

Rationalize each app with the 7 R’s

To rationalize means to decide, app by app, what deserves to move at all — some things you keep, some you retire, some you replace. This is where you pick a strategy for each app using the 7 R’s (rehost, replatform, refactor, and friends). The point is to avoid the trap of hauling everything: retiring a dead app or replacing it with a SaaS product is often cheaper than migrating it. Trade-off: deeper transformation (refactor) buys more long-term benefit but costs more time and risk up front, so most estates mix easy rehosts with a few high-value refactors.

Estimate Total Cost of Ownership (TCO)

Finish the assessment with a rough TCO — Total Cost of Ownership, the all-in cost of running something including servers, licenses, and people. A TCO comparison of "what it costs today" versus "what it will cost in the cloud" is the number your business case will lean on. Beginner warning: the honest TCO includes the un-glamorous parts — data-transfer fees, training, and the temporary period where you pay for both the old and new environments at once.

☺ Like you’re 10: TCO is the whole price of owning something, not just the sticker — like a puppy costs food and vet visits, not just the adoption fee.

Build the business case and define success

☺ Like you’re 10: Decide why you're moving and how you'll know it worked — like saying "we're moving to get a bigger yard, and we'll be happy if the dog has room to run."

Assessment tells you what you have; the business case decides why — and whether — you move. It is the document that keeps the migration honest when it gets hard.

Write the business case

Write down a short business case: the reason for the migration and the value expected (lower cost, faster releases, better reliability). Anchor it to the TCO you just estimated so the value is grounded, not wishful. A good business case names the driver — is this about saving money, shipping faster, escaping an ageing data centre, or all three? — because that driver quietly decides which of the 7 R’s you lean on.

Define measurable success metrics

Then define success metrics — measurable targets you can check later. Vague goals like "be more modern" can't be verified; concrete ones like "cut infrastructure cost 20%" or "deploy weekly instead of quarterly" can. The test of a good metric is simple: could a stranger look at a dashboard in six months and tell whether you hit it? If not, sharpen it until they could.

Set RTO and RPO from the start

Two safety numbers belong here from the very beginning, because you’ll test against them later during every cutover:

• RTO (Recovery Time Objective) — how long a system may be down before it hurts. "Back within 1 hour."
• RPO (Recovery Point Objective) — how much recent data you can afford to lose. "No more than 5 minutes of data."

You'll test against these later, so agree on them now — per app, since a marketing site and a payments service deserve very different promises. Setting them in the business case is what turns "it should stay up" into a target you can actually verify.

☺ Like you’re 10: RTO is "how fast must the lights come back on," and RPO is "how many minutes of homework you can afford to lose." Decide both before the storm, not during it.

Pilot small, then move in waves

☺ Like you’re 10: Move one small room first to learn the tricks. Then move the rest a few rooms at a time — never the whole house in one crazy day.

Prove the path with a low-risk pilot

Pick a low-risk pilot — a small, non-critical app — as your first move. Its job isn’t to move something important; it’s to prove the path — that the landing zone works, the tools work, and the team knows the runbook — while the stakes are low. It teaches your team the tools and surfaces surprises (a forgotten firewall rule, a slow data copy) where a mistake costs almost nothing.

Then roll out in waves

After the pilot, plan the rest in waves: batches of related apps moved together and verified before the next batch begins. This is the heart of the migration journey. Waves beat the tempting "big-bang" (everything at once), which Gizmo the Gremlin loves precisely because it removes your safety net — one giant switch means one giant thing to break, with nowhere to retreat. See Wave planning for the full method — how to group, sequence, size, and run each wave, and how each wave’s retrospective makes the next one faster.

☺ Like you’re 10: The first small room proves your plan; the waves are you repeating that proven plan a few rooms at a time.

Automate with Infrastructure as Code

☺ Like you’re 10: Instead of building each new room by hand, write down the exact instructions so a robot can build identical rooms perfectly every time.

Why Infrastructure as Code wins

Use Infrastructure as Code (IaC) — defining your servers, networks, and settings in text files instead of clicking buttons. Clicking works once, for one environment, on a good day; it does not scale to dozens of waves. IaC makes environments repeatable (the same every time), reviewable (changes go through code review like any other change), and quick to rebuild — which also makes rollback easier, because if you can rebuild an environment from a file, "go back" becomes "redeploy the previous version."

Picking your IaC tools

Provider-neutral tools like Terraform, or provider-specific ones (AWS CloudFormation, Azure Bicep, Google Cloud Deployment Manager), all serve the same idea: describe it once, deploy it consistently. Trade-off: a provider-neutral tool keeps you portable across clouds, while a provider-native tool often exposes the newest features first. Either way, the win is the same — your infrastructure becomes something you can read, review, and reproduce. See provisioning for how these fit the wider toolchain.

Land in a secure, well-designed home

☺ Like you’re 10: Set up the new house with locks, smoke alarms, and labeled rooms before you carry the furniture in — not after.

Build the landing zone first

Build a landing zone first: a pre-configured, secure cloud foundation (accounts, networks, identity, guardrails) that every workload lands into. It is "wave zero" — it must exist before any app moves, or your pilot has nowhere safe to land. Designing it once, up front, means every later wave inherits the same accounts, network layout, and guardrails instead of each team improvising its own (and each making its own mistakes). Design it around the Well-Architected Framework — a set of six pillars the major clouds all publish to describe a healthy cloud workload.

Security-by-design and zero trust

Bake in security-by-design (security built into the foundation, not bolted on after an incident) and zero trust (never automatically trust a request just because it's "inside" the network — always verify identity and permission). The practical habits: least-privilege access so each identity can do only what it needs, encryption for data at rest and in transit, and guardrails that make the insecure option the hard one. Doing this in the landing zone is far cheaper than retrofitting it across a hundred already-migrated apps.

Apply the Well-Architected Framework

☺ Like you’re 10: A good house needs six things at once: it runs smoothly, it's safe, it doesn't fall down, it's fast, it isn't wasteful, and it's kind to the planet. Each best practice feeds one of those.

What the framework is and how to use it

The Well-Architected Framework is a shared checklist of six qualities every healthy cloud workload should have. Its real power isn’t the list — it’s the review: you hold a workload up against the six pillars and ask "where are we weak?" A migration is a natural moment to run that review, because you’re rebuilding the workload anyway. Use it as a lens, not a grade: no workload is perfect on all six, and the pillars genuinely trade off against each other — spending more can buy performance, and the strongest security sometimes adds friction.

A quick tour of the six pillars

Every practice on this page maps to a pillar. Here is the cheat sheet:

Read the table two ways. Left-to-right, it defines each pillar in plain words. Right-to-left, it shows that a single good habit often serves several pillars at once — right-sizing, for example, quietly improves performance, cost, and sustainability together. That overlap is why the pillars reinforce rather than compete when you get the fundamentals right.

Watch the money: cost management and FinOps

☺ Like you’re 10: The cloud is like a pay-as-you-go arcade — leave a machine running and it keeps eating coins. Label your machines and turn off the ones nobody plays.

What FinOps is

FinOps (Financial Operations) is the practice of managing cloud spend as a team habit, not a yearly surprise. On-prem, you buy a server once and it’s a fixed cost; in the cloud, every running resource is a meter ticking by the hour, so cost becomes an everyday engineering concern shared by the people who create it. Done well, FinOps is the pillar of cost optimization turned into a routine.

The three staples: tagging, right-sizing, budgets

Sol the Sloth's three staples:

• Tagging — labeling every resource with its owner and purpose, so you know who's spending what. Without tags a cloud bill is one giant unaccountable number; with them, every cost has a name attached.
• Right-sizing — matching each server's power to what it actually needs, instead of copying an oversized on-prem box. A "lift and shift" that keeps the old, generous sizing is the single most common source of cloud waste.
• Budgets and alerts — setting spend limits that warn you before the bill surprises you, so a runaway cost is caught in hours, not discovered at month-end.

See what's happening, and prove it works

☺ Like you’re 10: Put smoke alarms and a dashboard in the new house so you notice problems early — then actually test that everything works before you sleep there.

Build observability from day one

Build observability — logs, metrics, and traces that let you see how a system is behaving — from day one, not after the first outage. Wire it into the landing zone so every wave arrives already visible. You cannot verify a migration you can’t see, and you cannot right-size or meet an RTO you aren’t measuring, so observability is what makes the reliability, performance, and cost pillars checkable rather than hopeful.

Test and validate against RTO/RPO

Then test thoroughly: functional tests (does it work?), performance tests (is it fast enough?), and recovery drills that validate against your RTO/RPO targets. A recovery drill is where you deliberately practise failing over and timing it, so the numbers you promised in the business case turn out to be true when it counts. Timmy's rule: an untested migration is a rumor, not a result.

Always keep a way back: rollback and runbooks

☺ Like you’re 10: Always know the road back to the old house, and keep a written checklist for moving day — so nobody has to remember the steps at midnight.

The rollback / backout plan

The rollback plan is the single most important safety habit on this page. It converts a failed cutover from an outage into a quick switch-back — but only if it was written and tested before the cutover, not improvised during it.

The cutover runbook

The cutover runbook is the precise, step-by-step script for the switch itself: every command, every check, every go/no-go decision, and the exact steps to reverse it. Writing it forces you to think the cutover through in daylight instead of at 2 a.m., and it lets anyone on the team run the move the same way. This is where each wave in wave planning gets its own rehearsed, refined runbook.

Don't forget the people

☺ Like you’re 10: Moving isn't just boxes — it's teaching everyone where the new light switches are.

Change management

Invest in change management (helping people adjust to new tools and ways of working). A migration changes how people deploy, monitor, and support their systems; if you move the technology but not the habits, the shiny new platform gets operated the old, painful way. Communicate early, name owners for each migrated system, and give teams time to adjust.

Skills and training

Invest in skills too — training your team on the cloud they now operate. The team that ran on-prem servers may be new to cloud networking, identity, or IaC, and a skills gap quietly slows every wave. Technology rarely fails migrations on its own; unprepared people and unclear ownership do.

Put together, these habits form your migration checklist — the running list you tick off on every move so nothing important is left to memory.

Check your answers

1. A pilot lets the team learn the tools and hit surprises while the stakes are low; waves then move batches of apps with verification between each, avoiding a risky big-bang.
2. RTO is how long a system may be down before it hurts; RPO is how much recent data you can afford to lose. You agree on both up front, in the business case, and test against them later.
3. Operational excellence, security, reliability, performance efficiency, cost optimization, and sustainability.
4. Because if the new system fails at cutover, a tested rollback (backout) plan is your only safe way back to the old system — without it you have no safety net.