What makes a cloud migration succeed when so many stall halfway? The pattern is rarely about which provider a team picks. It is about whether the team treated migration as a series of tidy technical moves or as a business change with a long tail of decisions. The hard work starts long before the first server is copied and continues well after the last one is switched off.
This article walks through the practices that separate migrations that finish from migrations that drag on for years. It covers inventory, workload strategy, security, cost, sequencing, and the human side of the work.
Start With a Real Inventory, Not a Spreadsheet Guess
Every migration that goes sideways has a moment where someone says, “Wait, what is that system?” The fix is a proper inventory before anything moves.
A useful inventory captures more than server names. It should record:
- Owner and business purpose for each application
- Dependencies between systems, including undocumented ones
- Data volumes and growth rate
- Traffic patterns and peak load
- Compliance or residency requirements
- Licensing terms that may change in a cloud model
The dependency map is where most teams underinvest. A migration looks simple until a reporting tool turns out to query three databases directly over a private link. A practical approach is to run network flow analysis for a few weeks rather than rely on architecture diagrams that were last updated two years ago. For a structured checklist, this guide on what to inventory before a cloud migration covers the categories teams most often miss. (What is cloud migration?)
One common mistake: teams inventory infrastructure but forget the people. Who actually understands the legacy batch job that runs at 2 a.m.? If the answer is “a contractor who left,” that is a migration risk, not a footnote.
Choose a Migration Strategy Per Workload
The industry shorthand for migration strategies is the 6 Rs, and it is worth knowing even if the attribution to any single analyst firm is murky and the count varies by source. Some frameworks list seven by adding “relocate,” which covers moving workloads such as VMware estates to a managed VMware environment without re-architecting.
| Strategy | What It Means | When It Fits |
|---|---|---|
| Rehost | Lift and shift with minimal change | Tight deadlines, low-value apps, first wave |
| Replatform | Small changes to use managed services | Databases, middleware, container moves |
| Repurchase | Replace with a SaaS product | Commodity functions like email or HR |
| Refactor | Rewrite or re-architect | Apps that need elasticity or new capability |
| Retire | Turn it off | Duplicated or unused systems |
| Retain | Keep where it is | Latency-sensitive or regulated workloads |
The trap is treating rehost as the “easy” option for everything. Lift and shift gets workloads into the cloud quickly, but it also carries old inefficiencies with them. A server that was oversized on-premises stays oversized, and the bill reflects it. A better rule: rehost to hit a date, then replatform on a planned schedule. Write that second step into the plan or it never happens.
Define Success Before You Move Anything
Migration projects that lack a definition of done tend to expand. A clear success definition might include retiring a data center lease, cutting recovery time from hours to minutes, or passing an audit that the old environment could not satisfy.
The Cloud Adoption Framework published by AWS organizes adoption into phases such as envision, align, launch, and scale, with readiness assessed across business, people, governance, platform, security, and operations. Microsoft’s framework uses a different set of phases (strategy, plan, ready, adopt, govern, manage). These are not interchangeable, and blending the names creates confusion in steering meetings. Pick one and use its vocabulary consistently.
For teams building out the target environment, the architecture material on cloud infrastructure and architecture at 9481.org is a useful reference for structuring landing zones and account boundaries before workloads arrive.
Treat Security as a Design Input, Not a Gate
Security reviews bolted on at the end of a migration become bottlenecks. The better pattern is to define the guardrails first, then let teams move inside them.
The shared responsibility model is the foundation here. The provider secures the cloud itself; the customer secures what runs in it. That split shifts depending on whether you use infrastructure, platform, or software services, and it differs by provider. Assuming the provider covers patching, identity, or data classification is one of the most expensive misunderstandings in cloud work.
NIST’s guidance on security and privacy in public cloud computing is a solid neutral baseline for governance and data protection decisions. The same organization’s definition of cloud computing sets out the essential characteristics, including on-demand self-service, resource pooling, and measured service, which helps teams explain to stakeholders why cloud cost behaves differently from a fixed data center bill.
Practical guardrails that work:
- Centralize identity and enforce multi-factor authentication before the first workload moves.
- Encrypt data at rest and in transit by default, with exceptions documented.
- Log everything to a central account the workload teams cannot alter.
- Classify data before migration, not after.
- Test recovery in the new environment, not backup alone.
The security team’s detailed guidance on enterprise AI and cloud security covers how these controls extend to newer workloads that combine data pipelines with AI services.
Get Cost Visibility Early or Pay for It Later
Cloud cost is the most predictable surprise in migration. On-premises costs are lumpy and amortized; cloud costs are metered and visible monthly, which is both an advantage and a shock.
Data transfer and egress charges deserve special attention. Moving large datasets into the cloud is often cheap or free, but pulling data out, replicating between regions, or serving traffic across zones can add up quickly. Pricing changes often, so any figure should be checked against the provider’s current pricing page rather than quoted from a blog post. A method for tracking cloud data transfer costs clearly helps teams separate this line item from general compute spend.
The FinOps Foundation publishes a framework that emphasizes cost visibility before and during migration. The practical version: tag every resource with owner, environment, and application before launch. Retrofitting tags onto thousands of resources is miserable work that nobody volunteers for.
Another habit that pays off is reviewing cost with engineers rather than only with finance. When a developer can see that a forgotten snapshot or an oversized instance is costing real money, behavior changes. Guidance on making cloud cost reviews useful to engineers explains how to frame those conversations so they inform rather than blame.
Sequence the Migration in Waves
Big-bang cutovers are dramatic and rarely necessary. Wave-based migration lets teams learn on lower-risk workloads before touching the systems that keep revenue flowing.
A workable wave plan looks like this:
- Wave zero: landing zone, identity, logging, network, and guardrails.
- Wave one: low-risk, low-dependency applications. These build confidence and expose gaps in tooling.
- Wave two: mid-tier systems with known dependencies.
- Wave three: business-critical and regulated workloads, migrated once the process is proven.
Each wave should end with a retrospective. What broke? What took longer than expected? Which runbook step was missing? Teams that skip this step repeat the same mistakes four times.
Account structure matters here too. Splitting workloads across separate cloud accounts limits blast radius and simplifies billing, but splitting too aggressively creates a maze of cross-account permissions. The tradeoffs are covered in this piece on when to split workloads across cloud accounts.
Design for Reliability From Day One
The Well-Architected Frameworks from the major providers organize design guidance into pillars such as operational excellence, security, reliability, performance efficiency, and cost optimization. Several now include sustainability as well. The pillar sets differ slightly between providers, so pick the one matching your platform.
Two reliability practices matter most during migration:
Test failure on purpose. Kill an instance in a staging environment and see what happens. If nobody notices, the monitoring has a gap. If everything falls over, the architecture has a single point of failure that the cloud did not create but will happily expose.
Automate recovery, then test the automation. A runbook that has never been executed is a wish, not a plan. Schedule game days before critical workloads move.
Plan the People Side
Migrations fail for organizational reasons more often than technical ones. Three practices help:
- Name an owner for every application. Shared ownership means no ownership.
- Train before you need the skill. Teams that learn infrastructure-as-code during a cutover learn it badly.
- Communicate the retirement date. People plan around certainty. If the old data center has no end date, teams will keep using it.
Reading a provider’s region announcement properly also matters when latency or data residency drives design. This explainer on how to read a cloud region announcement covers what the marketing language actually commits the provider to.
Common Mistakes Worth Avoiding
A short list of patterns that show up again and again:
- Migrating everything at once because the data center lease ends in six months.
- Skipping the dependency map and discovering a hidden integration during cutover.
- Assuming cloud means automatically highly available.
- Forgetting to decommission the old environment, so costs run in parallel for a year.
- Treating the migration as a project with an end date when the operating model has permanently changed.
That last point deserves emphasis. Migration is a phase. Operating in the cloud is forever. The teams that do well build practices, and project plans are not the whole effort. Broader context on enterprise AI and cloud intelligence shows how these operating habits extend into data and AI work.
Conclusion
Cloud migration best practices are less about clever tooling and more about discipline. Inventory honestly, pick a strategy per workload instead of one for everything, define success up front, build security and cost visibility into the foundation, and move in waves that let you learn. None of that is glamorous. All of it is what separates a migration that finishes from one that becomes a permanent line item.
FAQ
How long should a cloud migration take?
It depends on scope, but most mid-sized migrations run in waves over 12 to 24 months. The first wave often takes longer than expected because it includes building the landing zone, identity, and network foundations. Later waves speed up once the pattern is proven. A common mistake is compressing the timeline to match a data center lease deadline, which pushes teams toward lift and shift for everything.
What are the 6 Rs of cloud migration?
The 6 Rs are rehost, replatform, repurchase, refactor, retire, and retain. They describe how a workload moves. Some frameworks add a seventh, relocate, for moving workloads to a managed version of their existing platform without re-architecting. The origin of the framework is inconsistently attributed, so treat the categories as a practical checklist rather than a formal standard.
Is lift and shift always a bad idea?
No. Rehosting is a reasonable choice when a deadline is tight, the application is low value, or it is scheduled for retirement soon. The problem is treating it as the default for everything and never revisiting it. A better approach is to rehost to hit a date and then replatform on a planned schedule, with that second step written into the roadmap.
How do I control cloud costs during migration?
Tag resources before launch, review cost with engineers rather than only finance, and watch data transfer charges closely since they are easy to overlook. Cost visibility should exist before the first workload moves, not after the first surprising invoice. Pricing changes frequently, so verify figures against the provider’s current pricing pages rather than relying on older estimates.
Who is responsible for security in the cloud?
Under the shared responsibility model, the provider secures the cloud infrastructure and the customer secures what runs in it. The exact split shifts depending on whether you use infrastructure, platform, or software services, and it varies by provider. Assuming the provider handles patching, identity, or data classification is one of the most costly misunderstandings in migration work.
What should be in a migration readiness assessment?
A readiness assessment should cover business drivers, people and skills, governance, platform foundations, security controls, and operations. The goal is to find gaps before they block a cutover. Teams that skip this step often discover missing logging, unclear ownership, or untested recovery procedures during the migration itself, when fixing them is far more expensive.
