Practice & Reference · The Tools Landscape

The Tools Landscape

Every migration needs the right tool for each job — one to count what you own, another to lift the servers, another to move the databases without spilling a single row, and more to reshape apps for the cloud. This page is a friendly map of those tools, grouped by purpose rather than by brand. Then a picker lets you flip between AWS, Azure, and Google Cloud to see the real product names side by side.

Why tools come in families

☺ Like you’re 10: You don’t use a hammer to wash dishes. Each moving-day job has its own gadget, and the gadgets come in matched sets.

No single tool does a whole migration. Instead, each cloud offers a family of tools, one per stage of the migration journey. Think of five big jobs that show up on almost every move:

• Discovery & assessment — count what you have, map how it connects, estimate the cost. This is Nutty’s “count before you pack.”
• Server / VM migration — copy running machines (a VM, or virtual machine, is a whole computer that lives as software) up to the cloud.
• Database migration — move the data that apps read and write, often while the app keeps running.
• Data transfer — bulk-move files and objects, either online (over the network) or offline (on a shipped appliance).
• Modernization / IaC / containers — reshape apps into modern forms and define the cloud setup as code.

The good news for beginners: once you learn these five buckets, every cloud looks the same. Only the product names change. That maps neatly onto the the 7 R’s — discovery tools help you decide a strategy, server tools handle rehost, and modernization tools handle replatform and refactor.

Meet the five tool families

☺ Like you’re 10: Five drawers in one toolbox. Here’s what each drawer is for and when you open it.

The diagram above names the five drawers; this section opens each one. For every family you’ll get the same two answers a beginner needs: what it’s for (the job it does) and when you reach for it (where it shows up in the migration journey). The product names come later — in the table and the picker below. Right now we’re learning the jobs.

1. Discovery & assessment

☺ Like you’re 10: Before you touch a single box, you count them all, label them, and draw lines showing what’s plugged into what.

What it’s for: you can’t move what you haven’t counted. Discovery tools scan your data center and build an inventory — every server, how big it is, how busy it runs, and which apps talk to which (the dependency map). Assessment adds judgement on top of the raw count: how ready each workload is for the cloud, how to size it, and what it will cost to run — the total cost of ownership (TCO).

When you reach for it: at the very start, in the assess phase, and again every time you plan a new batch of apps — discovery’s inventory and dependency map are exactly what wave planning groups apps from. This is Nutty’s “count before you pack,” and skipping it is how hidden dependencies break a cutover.

2. Server / VM migration

☺ Like you’re 10: The dolly that rolls a whole machine — still switched on — up to the cloud.

What it’s for: copying an entire server — a VM, or virtual machine, meaning a whole computer that lives as software — up to the cloud with its operating system, applications, and settings intact. The clever part is replication: the tool keeps copying changes while the original stays running, so the actual switch-over needs only a short window of downtime.

When you reach for it: when you want to move a machine as-is without rewriting it. This is the workhorse of a rehost (“lift and shift”) — the most common R for a first migration, and the fastest way to get out of an aging data center.

3. Database migration

☺ Like you’re 10: Padded crates for the fragile stuff — the data — so not a single row spills on the way.

What it’s for: moving the data an app reads and writes, usually while the app keeps running. Like server tools, database tools continuously replicate changes from the live source until the moment you cut over, so users barely notice. When the source and target database engines differ — say Oracle moving to PostgreSQL — a schema-conversion step first rewrites the structure (tables, keys, stored procedures) to fit the new engine.

When you reach for it: any time an application’s database has to move, and especially when that database can’t take much downtime. For the deeper story on keeping data safe and in sync, see data migration.

4. Data transfer — online vs offline appliance

☺ Like you’re 10: A big truck for the online drive — or a shipping container when the truck would be too slow.

What it’s for: bulk-moving plain files and objects — photo archives, backups, data lakes — rather than running machines or live databases. It comes in two flavors. Online transfer pushes the data over the network. Offline transfer ships you a physical, ruggedized appliance: you fill it up on-site, then mail it back for the cloud to load directly.

When is a truck faster than the internet? More often than beginners expect. If you have hundreds of terabytes and an ordinary network link, uploading could take weeks or months — longer than it takes to drive a hard-drive-packed box across the country. The rule of thumb: a steady trickle your bandwidth can handle goes online; a flood too big to push over the wire in reasonable time goes on the offline appliance. Choosing wrong — trying to shove 400 TB over office wifi — is a classic anti-pattern.

5. Modernization / IaC / containers

☺ Like you’re 10: Instead of just carrying the old furniture over, you rebuild some rooms smarter — and write the blueprint down so you can rebuild them anytime.

What it’s for: reshaping apps to fit the cloud better instead of moving them untouched — packaging them into containers (lightweight, portable boxes that hold an app and everything it needs to run), breaking a big app into smaller services, or shifting to managed platforms. Alongside sits Infrastructure as Code (IaC): writing the entire cloud setup as text files so it’s repeatable, reviewable, and rebuildable on demand instead of clicked together by hand.

When you reach for it: when a plain lift-and-shift isn’t enough and you want the cloud’s real payoff — scaling, resilience, lower running cost. These tools power the replatform and refactor R’s; the whole topic gets its own tour on the modernization page.

The cross-cloud overview

☺ Like you’re 10: Same five gadgets, three different toy brands. Here they are lined up so you can see the matching pieces.

Read this table by row: pick a job on the left, then look across to see what each cloud calls its tool for that job. The names differ, but the jobs are identical everywhere.

Pick your cloud

☺ Like you’re 10: Choose one toy brand from the dropdown and you’ll see just its gadgets, with a one-line note on what each does.

Use the picker below to see one cloud’s toolset at a time, organized by the same five purposes. Watch for the online vs offline note under data transfer — online means “over the internet,” offline means “a physical appliance is shipped to you, filled, and mailed back.”

Check your answers

1. Discovery & assessment; server/VM migration; database migration; data transfer; and modernization / IaC / containers.
2. Discovery & assessment — hosted by Nutty the Squirrel, the Scout who inventories and maps dependencies before anything moves.
3. Online tools push data over the network (good for a trickle your bandwidth can handle); offline appliances are physical boxes shipped to you, filled, and mailed back (good for floods of data too large to send over the wire).
4. AWS Database Migration Service (DMS); Azure Database Migration Service (DMS); Google Cloud Database Migration Service (DMS) — each pairs with schema tools when engines differ.