What Is Cloud Migration?

Most enterprises do not decide to “migrate to the cloud” in a single meeting. They arrive at it — a data center lease ending, a hardware refresh nobody wants to pay for, a vendor pulling support for the operating system underneath a critical application. Cloud migration is the move that answers those pressures: relocating the applications, data, and workloads a business runs on from infrastructure it owns to a cloud platform it rents. This first part defines what that actually means, what forms it takes, and the single decision that separates a migration that pays off from one that just changes the address on the invoice.

What cloud migration actually moves

A cloud migration moves three things, and they travel at different speeds. Applications — the code that does the work. Data — the databases and files the applications depend on, often the heaviest and most delicate part of the move. And workloads — the running combination of compute, storage, networking, and configuration that keeps the whole thing alive in production.

The destination is not a single place, and the right one depends on what each workload needs from latency, control, and compliance, not on which option is currently fashionable.

Destination	What it is	Best fit
Public cloud	Shared infrastructure rented from a hyperscale provider	Workloads that benefit from elastic scale and want no hardware to own
Private cloud	Cloud-style infrastructure dedicated to one organization, sometimes on its own premises	Workloads with strict control, latency, or compliance needs the shared model can’t meet
Hybrid	Some workloads on-premises, connected to cloud workloads as one system	Estates where some systems have public-cloud-shaped needs and others genuinely don’t

Most enterprises land on hybrid, not because it’s a compromise, but because a real estate rarely has uniform needs. A workload with strict data residency requirements and a customer-facing app with unpredictable traffic are not the same problem, and forcing both into the same destination usually costs more than treating them differently.

How a cloud migration actually happens

A migration is not one event. It moves through five stages, and the risk in a cloud migration concentrates in whichever one gets skipped.

• Assess. Inventory the estate, applications, data, and workloads, and understand what each one does, how coupled it is, and what the business actually needs from it. This is the input the 7 Rs framework in Part 2 runs on, and rushing it is how a migration ends up moving the wrong things the wrong way.
• Plan. Decide how much to change each workload as it moves and sequence the moves by value and dependency, proving the approach on a low-stakes system before touching the ones the business can’t afford to get wrong.
• Migrate. Execute the move in waves rather than a single cutover. Waves let the team learn from the first workloads before committing the harder ones, and they contain the blast radius when something doesn’t go as planned.
• Validate. Prove the migrated workload behaves the same as the one it replaced, same outputs, same data, same edge cases, before it carries real production traffic. This is the stage most often compressed under deadline pressure, which is exactly when it matters most. Parity validation is the discipline built for this step.
• Optimize. A workload that lands in the cloud and is left alone often costs more than it did on-premises, because elasticity and managed-service savings do not arrive automatically. Right-sizing instances, enabling autoscaling, and adopting managed services after the move is what actually captures the benefit the migration was supposed to deliver.

Teams that struggle with cloud migration are rarely stuck on the migrate step. They skipped assess, so they moved things that didn’t need to move, or skipped optimize, so the workload runs in the cloud at on-premises efficiency and a cloud-sized bill.

The decision that matters: how much to change

Here is the part most “what is cloud migration” explanations skip. Moving a workload to the cloud is a logistics problem with a known solution. The decision that determines whether the migration was worth doing is how much you change the workload as you move it.

At one extreme, you relocate the system as-is — same code, same architecture, now running on cloud infrastructure. This is fast and low-risk, and it changes exactly one thing: where the system runs. At the other extreme, you re-architect the system to fit the cloud — restructuring it to scale elastically, fail gracefully, and be changed safely. This is slower and riskier, and it changes how the system is built.

Everything in cloud migration strategy is a choice along that line. The industry organizes those choices into a framework — the “7 Rs” — which Part 2 covers in full.

Why “migrated” and “modernized” are not the same word

The most expensive misunderstanding in this whole topic is treating cloud migration as if it were modernization. It is not.

A workload you lift to the cloud unchanged is exactly as hard to change the day after the migration as it was the day before. The coupling is still there. The undocumented behavior is still there. The scarce skills are still required. What changed is the billing model — a capital hardware expense became a monthly operating one. That can be a perfectly good reason to migrate. But it does not make the system more maintainable, and presenting it as “modernization” sets up an expectation the move cannot meet.

Moving a system to the cloud changes its address. Modernizing it changes its future.

Modernization changes how the system is built so the next change is cheap and safe. Cloud migration can be the vehicle for that — re-architecting a workload as you move it — but only if you choose to change the system, not just its location. The relationship between the two is worth its own treatment; we cover it in Application Modernization vs Cloud Migration.

What the cloud actually buys you

When a migration is done well, the cloud delivers properties that are genuinely hard to get on owned hardware: elastic capacity that scales with demand instead of being sized for the worst day of the year; managed services that hand off database, queue, and storage operations to the provider; geographic resilience across regions; and a shift from capital to operating expense that changes how the spend is funded and forecast.

None of these arrive automatically. Elasticity requires an application that can actually scale horizontally. Managed services require adapting the workload to use them. The cloud is an environment that rewards well-architected systems and punishes poorly-architected ones — which is why the same move can cut costs for one company and inflate them for another.

The direction of travel is clear: Gartner projects that by 2028, 70% of workloads will run in a cloud computing environment (Gartner, 2023). That is a reason to plan the move deliberately — not a reason to rush a workload into a place it isn’t ready for.

The cloud is not always the answer

Cloud migration is a tool, not a destination, and it is not universally correct. Workloads with steady, predictable load and no need for elastic scaling can be cheaper to run on owned hardware. Systems with hard latency requirements may need to stay close to where the work happens. Data subject to strict residency or air-gap requirements may not be allowed in public cloud at all — a real constraint we treat in Part 6.

The honest first question is never “how do we get to the cloud?” It is “what does this workload need that its current home can’t provide?” If the answer is nothing, the migration is motion without value. The cloud earns its place when a workload needs elasticity, resilience, a managed operating model, or an exit from infrastructure that is ending — not because moving is the fashion.

Where this leads

This part defined the move and the one decision that governs its payoff: how much to change each workload as it travels. That decision is not made workload-by-workload from instinct — there is a framework for it, refined over thousands of migrations into seven named options. Part 2, Cloud Migration Strategy and the 7 Rs, lays out all seven, what each one costs, what it buys, and how to assign the right one to each system in your estate — so the migration becomes a deliberate plan rather than a hopeful relocation.