What if the biggest risk in your cloud migration isn’t the technology at all, but the assumptions your team made before the first server moved? That question tends to surface about six months in, when the bill arrives, an application misbehaves, and someone asks why the old system was retired so quickly. This guide walks through what cloud migration actually involves, where teams go wrong, and how to plan a move that holds up after the launch party. (Cloud computing)
What Cloud Migration Really Means
Cloud migration is the process of moving applications, data, workloads, and IT processes from on-premises infrastructure, or from one cloud environment, to another. The term covers everything from lifting a single database into a managed service to rebuilding an entire platform as cloud-native software.
The vocabulary most migration plans use comes from the NIST definition of cloud computing, published as Special Publication 800-145 in September 2011. It describes five essential characteristics (on-demand self-service, broad network access, resource pooling, rapid elasticity, and measured service), three service models (IaaS, PaaS, SaaS), and four deployment models (private, community, public, hybrid). Writing a migration plan without that shared vocabulary is a common source of confusion, because “moving to the cloud” can mean wildly different things to a security lead, a developer, and a finance manager.
It is also worth saying plainly: migration is rarely a single event. Most organizations end up in hybrid or multi-cloud arrangements, and the work continues as optimization long after the initial cutover.
Why Organizations Migrate, and What They Expect
The stated reasons are usually consistent: retire aging hardware, gain elasticity for unpredictable demand, reduce operational overhead, improve disaster recovery, and support remote teams. The unstated reason is often a mandate from leadership or a board that has read the same analyst reports as everyone else.
Expectations deserve scrutiny. Vendor-sponsored surveys such as the annual cloud reports published by Flexera have repeatedly found that managing cloud spend ranks among the top challenges, and that most enterprises report spending more than expected. Those surveys are sponsored, so treat the percentages as directional rather than definitive. The pattern, however, shows up again and again: cost surprises are the most common post-migration complaint.
A second pattern is repatriation, where some workloads move back from public cloud to on-premises or private environments, often for cost or control reasons. Estimates vary widely by survey and methodology, and there is no agreed figure. The honest takeaway is that migration is not one-way, and a good plan leaves room to reverse a decision without a rebuild.
The Migration Strategies: The Six Rs and Their Limits
Gartner analyst Richard Watson described six common approaches in a 2011 blog post, and the framework stuck:
| Strategy | What happens | Typical use |
|---|---|---|
| Rehost | Lift and shift with minimal change | Fast exits, legacy apps, deadline pressure |
| Replatform | Small changes to use managed services | Databases, middleware, modest tuning |
| Repurchase | Replace with a SaaS product | Email, CRM, HR systems |
| Refactor | Re-architect for cloud-native design | High-value apps needing scale |
| Retain | Keep as-is for now | Regulated or poorly understood systems |
| Retire | Decommission | Duplicate or unused systems |
Some consultancies add a seventh “R” for relocate, and the exact list is a convention rather than a formal standard. That matters: teams sometimes treat the framework as a decision tree when it is really a shared label set. The useful move is to classify each application honestly, then ask what the business gains from each option.
Rehosting is popular because it is fast, but it carries the most hidden cost. A lifted server keeps its old sizing, its old patching habits, and its old assumptions about storage. Teams that lift and shift without a follow-up optimization pass often find they have simply moved their inefficiency to a more expensive address.
Start With an Inventory, Not a Vendor Meeting
The single most reliable predictor of a smooth migration is an accurate inventory. Before comparing providers or drawing architecture diagrams, teams need to know what they actually run. That includes application dependencies, data volumes, network flows, integration points, license terms, and the person who understands each system.
A structured approach helps. This guide to what to inventory before a cloud migration covers asset and dependency mapping that prevents nasty surprises later. The practical tip from teams that have done this well: interview the people who operate the systems as well as the ones who own the budget. The operator usually knows about the cron job nobody documented.
Common mistakes at this stage:
- Counting virtual machines instead of applications, which hides shared dependencies.
- Skipping data classification, then discovering regulated data in an unregulated system.
- Ignoring egress and interconnection costs until the first invoice.
- Assuming the application owner also understands the network path.
The Costs Nobody Budgets For
Compute and storage are the visible line items. The ones that surprise people are data transfer, cross-region replication, licensing that changes under a subscription model, and the engineering time spent on retries and rework.
Data transfer in particular deserves early attention. A clearer way to track cloud data transfer costs breaks down how egress, inter-region traffic, and service-to-service calls accumulate. The practical habit: model traffic flows during the inventory phase, not after go-live, and put a cost owner on each application.
Cost reviews also fail when they are run as finance exercises. Making cloud cost reviews useful to engineers explains how to frame spend so that the people who can change it actually engage. A dashboard nobody reads is not governance.
Security, Compliance, and the Rules That Shape the Move
Security is not a phase that happens after architecture. It shapes which workloads can move where.
In the United States, the Federal Risk and Authorization Management Program (FedRAMP), established in December 2011, provides a standardized security assessment and authorization process for cloud services sold to federal agencies. Even for private-sector teams, the FedRAMP model is a useful reference for how a structured authorization process looks in practice.
In Europe, data protection law constrains cross-border movement. The General Data Protection Regulation (Regulation (EU) 2016/679), applicable from 25 May 2018, restricts transfers of personal data to third countries. The Court of Justice of the EU’s Schrems II judgment on 16 July 2020 invalidated the EU–US Privacy Shield, which forced many migration plans back to the drafting table. Any migration touching EU personal data needs a transfer analysis before architecture is finalized, not after.
Portability is now a legal matter too. The EU Data Act (Regulation (EU) 2023/2854) includes provisions on switching between cloud providers and on phasing out switching charges, with obligations applying from 12 September 2025. Exit planning is no longer just good hygiene; in the EU it is increasingly a compliance expectation.
For teams thinking through the security architecture of a move, the material on enterprise AI and cloud security at 9481.org covers how identity, data boundaries, and controls fit together across environments. (9481.org)
Choosing Regions and Reading the Fine Print
Region selection is where latency, cost, and law collide. A region announcement rarely says everything a migration team needs to know, so it pays to read between the lines. How to read a cloud region announcement walks through what to check: service availability at launch, data residency commitments, and which features arrive later.
The practical tip here is to pilot in the target region before committing. Spin up the actual workload, measure real latency from real user locations, and confirm that the managed services you depend on exist there. Launch-day region pages are marketing documents as much as technical ones.
Account Structure and Workload Boundaries
A single cloud account for an entire enterprise becomes unmanageable fast. Blast radius grows, permissions get tangled, and cost attribution turns into guesswork. Splitting workloads across accounts is the usual remedy, and the guidance on when to split workloads across cloud accounts explains the trade-offs between isolation and operational overhead.
The rule of thumb that works in practice: separate by environment and by data sensitivity first, then by team or product line as scale demands. Over-splitting early creates its own tax in cross-account networking and duplicated guardrails.
A Migration Sequence That Holds Up
No two migrations look identical, but the sequence that tends to work looks like this:
- Inventory and classify. Document applications, dependencies, data sensitivity, and owners.
- Set the business case per application. Decide rehost, replatform, refactor, retain, or retire, with a named owner and a success measure.
- Design the landing zone. Accounts, networking, identity, logging, and guardrails before the first workload arrives.
- Pilot one real workload. Not a toy. Something with users, dependencies, and a support burden.
- Migrate in waves. Group applications by dependency, not by department politics.
- Optimize after cutover. Right-size, retire redundant services, and revisit commitments.
- Plan the exit. Document how to leave, even if you never do.
Step seven is the one most often skipped. Contracts, data formats, and proprietary services all create lock-in, and the EU Data Act’s switching provisions exist precisely because that lock-in has been a real problem.
What Actually Works in Practice
A few habits separate migrations that go smoothly from those that generate postmortems.
Migrate the boring things first. A file server or an internal tool is a low-risk way to test the landing zone, the runbooks, and the on-call rotation. Save the revenue-critical system for when the team has muscle memory.
Keep a rollback path for longer than feels necessary. Teams routinely decommission the old environment within weeks, then discover a dependency in month three. Keep the old system readable, if not writable, until the new one has survived a full business cycle.
Write the runbook before the cutover, not after. The people doing the 2 a.m. work should have written it while calm.
Treat the migration as a product, not a project. Projects end. A migration has an operating model attached to it, and that model needs an owner, a budget line, and a review cadence.
Measure something other than completion. Percentage of workloads moved is a vanity metric. Deployment frequency, incident rate, and cost per transaction tell you whether the move actually helped.
For teams building out the broader platform picture alongside the migration, the cloud infrastructure and architecture resources at 9481.org cover reference patterns for landing zones and workload design. Keeping an eye on how enterprise AI and cloud intelligence practices are evolving also helps, since AI workloads increasingly shape storage, networking, and identity decisions made during a migration.
Common Failure Modes Worth Naming
The big-bang cutover. Everything moves at once, and every problem arrives at once. Waves exist for a reason.
The invisible dependency. A reporting job, an integration account, or a scheduled export that nobody owned. Inventory catches these; assumptions do not.
The forgotten identity model. Permissions copied from on-premises rarely map cleanly. Rebuild roles around least privilege rather than translating old group structures.
The unowned bill. Without a named cost owner per application, spend drifts upward quietly.
The premature celebration. Declaring victory at cutover skips the optimization work that produces most of the value.
Conclusion
Cloud migration is less a technical event than a long series of judgment calls: what to move, what to leave, what to rebuild, and what to walk away from entirely. The teams that do it well are not the ones with the most sophisticated architecture diagrams. They are the ones who inventoried honestly, classified their applications, planned their costs, respected the legal constraints on their data, and kept a way back.
If there is one habit to take away, it is this: decide per application, not per program. A migration plan that treats every workload the same will be too slow for the simple ones and too careless with the complicated ones. Start with the inventory, pilot something real, and measure whether the move actually made anything better. The cloud is a means, not a finish line.
FAQ
How long does a typical cloud migration take?
It depends heavily on scope. A single application can move in weeks; an enterprise estate with hundreds of systems typically runs in waves over one to three years. The inventory and landing zone phases usually take longer than teams expect, while individual workload moves are often faster.
Is lift and shift always a bad idea?
No. Rehosting is a legitimate choice when speed matters, the application is near end of life, or the business needs a data center exit on a deadline. The mistake is treating rehosting as the destination rather than a first step. Plan an optimization pass after cutover, or the cost and operational benefits never materialize.
What is the difference between cloud migration and cloud adoption?
Migration is the movement of specific workloads. Adoption is the broader organizational shift: new operating models, skills, procurement, security practices, and governance. A company can complete a migration and still have poor adoption if teams keep working the old way.
How do I decide which workloads should stay on-premises?
Look for systems with strict latency requirements, specialized hardware dependencies, regulatory constraints that cannot be satisfied in the target environment, or economics that clearly favor owned infrastructure. Some workloads genuinely belong on-premises, and retaining them is a valid strategy rather than a failure.
What should be in a cloud exit plan?
At minimum: how data is exported and in what format, which proprietary services create dependency, notice periods and contractual terms, and who is authorized to trigger the exit. In the EU, switching provisions under the Data Act make this a compliance matter as well as a practical one.
How do I keep cloud costs from spiraling after migration?
Assign a cost owner per application, model data transfer during design, review spend with engineers rather than only with finance, and revisit commitments regularly. Most overspend comes from workloads that were never right-sized after the move, not from pricing changes.
