Around 90% of enterprises now run some workload in the cloud, yet a large share of migrations still miss their deadlines or budgets. The gap rarely comes from bad technology. It comes from skipping the unglamorous steps: honest assessment, tight scoping, and a rollback plan nobody bothered to test. This guide walks through the practices that separate smooth cutovers from the ones that turn into six-month rescue projects.
Start With an Honest Assessment, Not a Vendor Pitch
The most common mistake in cloud migration is treating it as a hardware swap. Teams inventory servers, pick a target platform, and start moving. Then they discover that a legacy application depends on a hard-coded IP address, a local print driver, or a database nobody has patched since 2019.
A proper assessment answers three questions before anything moves:
- What does each application actually depend on? Map network calls, authentication sources, scheduled jobs, and data flows in addition to the server list.
- What is the business criticality? An internal wiki and a payment processor should never share a migration wave.
- Who owns each system? If no one can name the owner, that application is not ready to move.
Practical tip: run the assessment as a spreadsheet with one row per application and columns for dependencies, owner, criticality, and target strategy. It sounds mundane. It is also the single document that keeps a migration on schedule, because it forces arguments about scope to happen early rather than during a cutover window.
It also helps to understand what you are migrating to. Teams that grasp the difference between object storage, block storage, and managed databases make far fewer architecture mistakes, and a primer on what cloud storage is and how it works is a cheap way to get everyone on the same page before design starts.
Choose a Migration Strategy Per Application
Not every workload should be modernized, and not every workload should be lifted and shifted. The widely used 6 Rs framework gives teams a shared vocabulary:
| Strategy | What It Means | Best For |
|---|---|---|
| Rehost | Move as-is to cloud infrastructure | Stable apps with tight deadlines |
| Replatform | Minor tuning, e.g. managed database | Apps that benefit from managed services |
| Repurchase | Switch to a SaaS product | Commodity functions like email or CRM |
| Refactor | Rearchitect for cloud-native patterns | High-value apps needing elasticity |
| Retire | Turn it off | Duplicated or unused systems |
| Retain | Keep where it is for now | Regulated or tightly coupled systems |
The trap is treating “refactor” as the default because it sounds ambitious. In practice, rehosting first and modernizing later often delivers value faster, provided you actually come back for the modernization phase. Many organizations never do, and end up paying cloud prices for on-premises architecture.
Retirement deserves more attention than it gets. Audits routinely find that 10% to 20% of applications have no active users. Turning those off before migration shrinks the project and the bill at the same time.
Get the Landing Zone Right Before the First Workload Moves
A landing zone is the pre-configured foundation: accounts, network segmentation, identity, logging, and guardrails. Building it after workloads arrive is like laying foundations after the walls go up.
What a solid landing zone includes:
- Identity and access: centralized identity provider integration, role-based access, and no shared admin accounts.
- Network design: IP address planning that leaves room to grow, plus private connectivity to on-premises systems.
- Logging and monitoring: centralized log storage with retention policies set from day one.
- Cost controls: budgets, alerts, and tagging standards enforced automatically.
- Guardrails: policies that block public storage buckets or unencrypted volumes by default.
Governance belongs here too. A clear set of AI governance principles, risks and best practices is worth reviewing even for non-AI workloads, because the same discipline around data classification and access review applies to everything you move.
Migrate in Waves, Not in One Big Bang
Big-bang cutovers make great war stories and terrible business outcomes. Wave planning groups applications by dependency and risk so each wave is small enough to fail safely.
A workable sequencing approach:
- Wave zero: non-critical, low-dependency systems. This is where the team learns the tooling.
- Early waves: internal tools with forgiving users.
- Middle waves: business applications with clear owners and tested rollback paths.
- Final waves: regulated, high-dependency, or high-traffic systems, moved once the process is proven.
Each wave should have an explicit exit criteria checklist: performance benchmarks met, monitoring live, backups verified by an actual restore test, and the owning team trained. Skipping the restore test is the mistake that shows up months later when someone needs a backup and finds it was never actually running.
Test Performance and Cost Before You Commit
Cloud performance problems are usually configuration problems. A database that ran fine on dedicated hardware can struggle on undersized instances, and a chatty application that made thousands of small calls inside a data center may behave very differently across availability zones.
Before each cutover, run load tests against the target environment using realistic traffic patterns. Compare latency, throughput, and error rates against the on-premises baseline. If the numbers do not match, fix the architecture rather than throwing bigger instances at the problem, which just hides it at a higher price.
Cost deserves the same rigor. FinOps practices, meaning shared accountability for cloud spend between engineering and finance, work best when introduced early. Tag every resource, set budget alerts per team, and review spend weekly during migration. The first bill after a lift-and-shift often surprises people because on-premises costs were hidden in depreciation and facilities budgets.
For teams comparing providers, a structured look at AWS vs Azure vs Google Cloud helps frame pricing models and service maturity before contracts are signed, since switching later is far more disruptive than choosing carefully up front.
Security and Compliance Cannot Be Bolted On Later
Migration changes your security perimeter. Data that never left a locked room now traverses networks and sits in storage buckets that can be misconfigured into public view. Misconfigured storage remains one of the most common causes of cloud data exposure.
Non-negotiables:
- Encrypt in transit and at rest, with keys managed deliberately rather than by default.
- Apply least privilege to every service account, and remove standing admin rights.
- Centralize logging so security teams can see across accounts and regions.
- Scan infrastructure as code before deployment, not after.
- Map data residency requirements to specific regions before workloads land.
Compliance teams should be involved in wave planning, not consulted at the end. Auditors want evidence of controls, and evidence is much easier to produce when logging and access reviews were designed in rather than reconstructed afterward.
Privacy architecture is evolving fast, and hybrid designs are becoming more common. Understanding initiatives like Apple private cloud compute on Google cloud shows how seriously large providers now treat confidential computing, which matters if you handle sensitive data and are weighing where processing can safely happen. (Cloud computing)
Train People and Document Everything
The most underrated migration risk is the knowledge gap. A team that has run the same data center for a decade knows every quirk. Move to managed services and that institutional memory no longer maps to the new environment.
What works in practice:
- Pair migrations: have the application owner work alongside the platform team during the move, so knowledge transfers rather than evaporates.
- Write runbooks during the migration, not after. A runbook written from memory three months later will be wrong.
- Run game days: deliberately break something in a test environment and see whether the on-call engineer can fix it using only the documentation.
- Budget for training in the target platform. Certification courses are cheaper than outages.
A common mistake is assuming that because the cloud console is easy to click, operations are easy to run. Managed services shift work from maintenance to configuration and cost management, and that is a different skill set.
Plan the Exit Before You Need It
Vendor lock-in is not a reason to avoid cloud, but it is a reason to avoid accidental lock-in. Use portable formats where practical, keep infrastructure definitions in version control, and document which services are deeply proprietary versus easily replaceable.
Multi-cloud strategies are sometimes oversold. Running everything on two providers doubles operational complexity for many teams. A more realistic middle ground is a primary provider plus deliberate portability for the handful of workloads where switching matters, such as core data stores and identity.
The same thinking applies to platform shifts. When providers change how their services work, as with Apple private cloud compute and Google Cloud in 2026, teams that kept their architecture loosely coupled adapt quickly. Teams that hard-coded every integration spend months catching up. (What is Cloud Migration?)
Measure Success With Business Metrics, Not Migration Counts
Counting migrated servers feels productive and tells you almost nothing. Better measures:
| Metric | Why It Matters |
|---|---|
| Cost per transaction | Shows whether the cloud bill buys real efficiency |
| Deployment frequency | Reveals whether agility actually improved |
| Mean time to recovery | Tests whether resilience survived the move |
| Application availability | Catches regressions the project plan missed |
| User satisfaction scores | Confirms the business feels the benefit |
Review these monthly for at least two quarters after migration completes. Many programs declare victory at cutover and never check whether the promised benefits arrived.
Conclusion
Successful cloud migration is less about the destination platform and more about discipline. Assess honestly, choose a strategy per application rather than one for everything, build the landing zone first, move in small waves, test performance and cost with real numbers, and treat security and training as part of the plan rather than cleanup work. The organizations that do this well rarely have dramatic stories to tell, and that is precisely the point. A migration nobody talks about afterward is usually one that worked.
Frequently Asked Questions
How long does a typical cloud migration take?
It depends on scale and complexity. Small environments with a handful of applications can move in weeks, while enterprise programs with hundreds of applications and regulatory constraints often run 12 to 24 months. The bigger predictor is not application count but how many undocumented dependencies exist. Teams that complete a thorough assessment usually finish closer to plan.
What is the biggest mistake in cloud migration?
Skipping the assessment and moving applications without understanding their dependencies. The second most common mistake is failing to test backups by actually restoring data. Both problems are cheap to prevent and expensive to fix, which is why experienced teams treat them as mandatory gates before any cutover.
Should we rehost or refactor first?
For most organizations, rehosting selected workloads first and refactoring later delivers faster value, provided the modernization phase is genuinely scheduled and funded. Refactoring everything up front slows delivery and increases risk. The right mix depends on how much business value a specific application gains from cloud-native patterns.
How do we control cloud costs during migration?
Tag every resource, set budgets and alerts per team, and review spend weekly rather than monthly during the migration period. Introduce shared cost accountability between engineering and finance early. Most cost overruns come from forgotten resources and oversized instances, both of which are visible within days if anyone is looking.
How much downtime should we plan for?
Ideally none for customer-facing systems. Blue-green deployments, database replication, and DNS cutover strategies can reduce downtime to seconds for many workloads. Plan a maintenance window anyway for the systems that genuinely need one, and always test the rollback path before the real cutover.
When should we involve security and compliance teams?
From the first planning meeting. Data residency, encryption standards, and access controls shape architecture decisions, and retrofitting them after workloads are live is slow and expensive. Bringing these teams into wave planning early also makes audit evidence far easier to collect later.
