Quick Answer: What is cloud migration?
Cloud migration is the process of moving applications, data, and IT workloads from on-premises data centers or one cloud provider to another cloud environment. It usually happens in phases: assess what you have, choose a strategy for each workload, move it, and then tune cost and performance. Teams can act on it through rehosting, replatforming, refactoring, or retiring systems entirely. (Cloud computing)
It differs from cloud adoption, which is the broader shift in how an organization buys and runs technology, and from modernization, which can happen without any move at all. A migration can be a single database lift or a multi-year program covering hundreds of applications.
Before acting, compare workload dependencies, data gravity, compliance and data residency rules, downtime tolerance, licensing terms, network egress costs, and the skills your team already has.
Why the Definition Matters More Than It Sounds
Ask ten engineers what cloud migration means and you will get ten answers, most of them technically correct and practically useless. One person means “we moved our website to a virtual machine.” Another means “we spent three years rebuilding our order system as microservices.” Both call it migration. The word hides an enormous range of work.
That ambiguity causes real problems. Budgets get approved against the cheapest interpretation. Timelines slip because nobody agreed on scope. A migration that sounds like a weekend project turns into an eighteen-month program with a steering committee.
So the useful definition is this: cloud migration is the deliberate relocation of computing assets from one operating environment to another, with a plan for what happens to each asset before, during, and after the move. The plan is the part that separates a migration from an accidental sprawl.
The Destination: What Cloud Actually Means
You cannot describe a move without describing where you are moving to. The most widely used reference is the cloud computing definition published by NIST in Special Publication 800-145, which sets out five essential characteristics: on-demand self-service, broad network access, resource pooling, rapid elasticity, and measured service. It also defines the three service models most teams work with: infrastructure as a service, platform as a service, and software as a service.
That vocabulary matters during migration planning because each model changes what you are responsible for. Move a workload to infrastructure as a service and you still patch the operating system. Move it to platform as a service and the provider handles that layer. Move to software as a service and you are mostly managing users and data.
Practical tip: write down the target service model for every workload before you estimate effort. Teams that skip this step routinely discover halfway through that they have traded a data center bill for a pile of unmanaged virtual machines that behave exactly like the servers they left behind.
The Six (or Seven) Migration Strategies
Most migration plans borrow a taxonomy of strategies, often called the Rs. Gartner’s cloud migration strategies framework is the version most commonly cited. The count varies by source, and providers such as AWS document their own variants in migration guidance, so treat the labels as a shared vocabulary rather than a rigid standard.
| Strategy | What Happens | Typical Use |
|---|---|---|
| Rehost | Move as-is with minimal change | Fast exits, legacy apps, tight deadlines |
| Replatform | Small optimizations during the move | Managed databases, containerization |
| Refactor | Redesign for cloud-native patterns | Systems needing scale or new features |
| Repurchase | Replace with a SaaS product | Commodity functions like email or HR |
| Retire | Switch off what nobody uses | Duplicate or abandoned systems |
| Retain | Keep on-premises for now | Latency, licensing, or compliance limits |
The seventh R, relocate, appears in some frameworks and describes moving a workload to a different hosting platform without redesigning it. In practice, the exact number matters far less than the discipline of assigning one strategy per workload and writing down why.
Rehosting and Its Reputation Problem
Rehosting, or lift and shift, gets criticized a lot. The criticism is partly fair. Lifting a poorly understood application into the cloud tends to preserve every inefficiency and add a monthly bill on top. But rehosting is also the fastest way to exit a data center lease, and speed has genuine value when a contract deadline is approaching.
The mistake people make is rehosting everything and calling it a strategy. A better pattern is to rehost the workloads that are low-risk and well understood, then replatform or refactor the ones where cloud capabilities actually pay for themselves.
Refactoring Is Not Automatically Better
Refactoring sounds like the mature choice, and sometimes it is. But a rewrite carries its own risks: scope creep, feature drift, and the classic trap of rebuilding a system nobody fully documented. A refactor that takes two years has a worse payback than a rehost that takes six weeks, especially if the original application is stable and rarely changed.
The Migration Lifecycle in Practice
Provider frameworks describe similar phases with different names. Microsoft’s Cloud Adoption Framework, for example, treats migrate as one stage within a broader adoption journey that includes strategy, planning, and governance. Rather than memorizing any single vendor’s diagram, most teams do well with four stages.
- Assess. Inventory applications, dependencies, data volumes, integrations, and owners. This is where most migrations are won or lost.
- Plan. Assign a strategy per workload, sequence the waves, and define success criteria and rollback conditions.
- Migrate. Move in small batches, validate functionality, and cut over with a tested reversal path.
- Optimize. Right-size resources, fix cost surprises, tighten security, and retire what is no longer needed.
A useful discipline before stage one is deciding what to inventory before a cloud migration, because unknown dependencies are the single most common cause of failed cutovers.
What Actually Goes Wrong
In practice, the failures cluster around a few predictable patterns. Undiscovered dependencies top the list: an application that looks standalone turns out to call a hard-coded IP address on a server in a closet. Data transfer costs catch teams off guard, particularly when large datasets move repeatedly during testing. Identity and access rules get rebuilt inconsistently, leaving gaps. And nobody agrees on who owns the application after the move.
The fix is unglamorous. Trace network traffic. Read the runbooks. Talk to the person who has maintained the system for a decade. Then build a clearer way to track cloud data transfer costs before the first terabyte moves, not after finance notices the bill.
Cost, Contracts, and the Parts Nobody Warns You About
Migration budgets usually cover compute, storage, and tooling. They often miss three things: egress charges for data leaving the old environment, duplicate running costs during parallel operation, and the engineering time spent on cutover rehearsals. A workload can run in two places for weeks. That overlap is not waste; it is insurance. But it belongs in the forecast. (9481.org)
Cost reviews also tend to fail because they happen in a finance spreadsheet rather than in the tools engineers use daily. Making cloud cost reviews useful to engineers is less about dashboards and more about attributing spend to the teams who can actually change it.
There is a structural angle too. Splitting workloads across separate cloud accounts or subscriptions limits blast radius, simplifies billing, and makes access control cleaner. Knowing when to split workloads across cloud accounts prevents the “one giant account” pattern that becomes unmanageable at scale.
Compliance and Data Residency
Any migration involving personal data needs legal review early, not at the end. In the European Union, moving personal data to cloud services engages the General Data Protection Regulation, including its rules on transfers outside the bloc. Regulators have published detailed guidance on what safeguards may be needed when data leaves the EU, and reading it before architecture decisions are locked saves painful rework later.
Public-sector bodies often face additional rules. In the United Kingdom, government cloud policy has for years pushed public bodies to consider cloud options before alternatives, which shapes procurement timelines and evidence requirements.
Practical advice: involve legal and security in the assessment phase and give them a specific question, such as “can this dataset be processed in this region under these contract terms?” Vague requests produce vague answers.
Security After the Move
Security does not disappear when a provider takes over the hardware. It changes shape. The provider secures the physical layer and much of the platform. Your team still owns identity, configuration, data classification, and access policy.
The most common post-migration weaknesses are familiar: overly broad permissions granted during the rush, storage buckets left publicly readable, logging that was never turned on, and encryption keys managed by whoever set things up first. A structured approach to enterprise AI and cloud security helps here, because the same identity and data controls that protect migrated workloads also protect whatever gets built on top of them.
One habit worth adopting: run a security review at the end of every migration wave, not at the end of the program. Small, frequent checks catch drift while it is still cheap to fix.
How Long Does a Migration Take?
There is no honest universal answer, but there are useful patterns. A single application with few dependencies can move in weeks. A departmental portfolio of twenty applications typically takes several months. An enterprise program covering hundreds of systems and a data center exit runs for years and is best treated as a portfolio of smaller migrations rather than one project.
The variable that predicts duration best is not application count. It is the quality of the inventory and the availability of people who understand the systems. Teams that invest two extra weeks in discovery frequently save two months in cutover.
Conclusion
Cloud migration is a relocation project with a strategy problem at its center. The technology is rarely the hard part. Deciding what to move, what to change, what to retire, and what to leave alone is where the real work sits.
The teams that do this well share a few habits. They inventory obsessively before touching anything. They pick a strategy per workload and write down the reasoning. They move in small waves with tested rollback paths. They watch cost and security from the first day rather than the first invoice. And they accept that a rehost is sometimes the right answer, even when refactoring sounds more impressive.
Start with the destination in mind, but plan the move one workload at a time. That is the difference between a migration and an expensive experiment.
Frequently Asked Questions
Is cloud migration the same as cloud adoption?
No. Cloud adoption is the broader organizational shift toward cloud-based technology, including culture, procurement, and operating model. Migration is the specific act of moving workloads. An organization can adopt cloud services for new projects without migrating anything, and it can migrate workloads without changing how it works.
What is the difference between rehosting and replatforming?
Rehosting moves an application with little or no change, usually to virtual machines. Replatforming makes targeted changes during the move, such as switching to a managed database or containerizing the application. Replatforming takes more effort but often reduces long-term operating burden.
Can a migration happen without downtime?
Sometimes, but rarely for complex systems. Stateless web tiers can often be moved with near-zero downtime using traffic shifting. Stateful databases usually need a planned maintenance window or a replication-based cutover. The realistic goal is a short, rehearsed window rather than no window at all.
Who should be involved in a migration plan?
At minimum: application owners, infrastructure and network engineers, security, finance, and legal or compliance. The most frequently forgotten participant is the person who actually operates the system day to day, whose knowledge of quirks and workarounds is often the best documentation available.
What happens to data during a migration?
Data is typically copied to the target environment, synchronized while the source stays live, then validated before the cutover. The source is kept intact until the new system is proven. Retention and deletion of the old copies should be planned deliberately, since compliance rules often govern how long those copies may exist.
Does moving to the cloud always reduce costs?
No. Costs fall when workloads are right-sized and idle capacity is removed. They rise when teams rehost everything unchanged, leave non-production environments running continuously, or move large volumes of data repeatedly across network boundaries. Cost outcomes depend far more on operating discipline than on the choice of provider.
