What Is Cloud Migration? Complete Guide 2026
- 11 minutes ago
- 30 min read
A data center lease expires. A vendor discontinues the server hardware your finance system runs on. A retailer needs to handle ten times its normal traffic for one weekend in November. In each case, the fastest and often cheapest fix is not a new building or a truck full of servers — it is cloud migration, the deliberate process of moving workloads and data from where they run today to a cloud environment built to absorb that kind of change.
TL;DR
Cloud migration is the process of moving applications, data, and infrastructure from one computing environment — typically on-premises or another cloud — into a cloud environment.
Organizations migrate for reasons that include data center exits, scalability, disaster recovery, and access to managed services — not for cost savings alone, which depends on execution.
The 7 Rs (rehost, relocate, replatform, repurchase, refactor, retire, retain) give every application in a portfolio a defined strategy instead of a one-size-fits-all approach.
A typical migration follows assess, plan, migrate, and optimize phases, built on a secure “landing zone” foundation before large-scale workload movement begins.
Security, cost, and downtime outcomes depend on how migration is executed — the cloud provider secures the underlying infrastructure, but configuration, identity, and data protection remain the customer's responsibility.
What Is Cloud Migration?
Cloud migration is the process of moving applications, databases, and IT infrastructure from an on-premises data center, a private hosting environment, or one cloud provider into a cloud computing environment. It can involve a full data center exit, a workload-by-workload move, or a transfer between two public clouds (cloud-to-cloud migration). The right approach depends on each workload's dependencies, risk tolerance, and business goals.
Table of Contents
What Is Cloud Migration?
Cloud migration is the process of moving applications, databases, files, virtual machines, networking configurations, and entire IT estates from where they currently run into a cloud computing environment. The National Institute of Standards and Technology (NIST) defines cloud computing itself as a model for enabling on-demand network access to a shared pool of configurable computing resources — servers, storage, applications, and services — that can be provisioned quickly with minimal management effort (Mell and Grance, NIST SP 800-145, 2011). Migration is how an organization gets its existing systems into that model.
A migration project can involve any combination of the following:
Business applications, from custom-built software to commercial off-the-shelf systems
Relational and non-relational databases
Unstructured files, backups, and archival datasets
Physical servers and virtual machines
Networking and security configurations, such as firewall rules and access policies
Entire data centers, in the case of a full exit
Individual, narrowly scoped workloads, such as a single reporting service
Migration also covers more than one direction of movement. The most familiar pattern is on-premises to cloud, but organizations also migrate from a private hosting provider to a public cloud, from one public cloud to another (cloud-to-cloud migration), or move only part of an estate while the rest stays put in a hybrid arrangement.
Cloud migration is a distinct activity from two related ideas it often gets confused with. Simply subscribing to a Software-as-a-Service (SaaS) product, such as switching from an on-premises email server to a hosted email service, is a form of cloud adoption but does not involve migrating an existing workload. Likewise, building a brand-new, cloud-native application from scratch is cloud-native development, not migration — there is no source environment to move from. Migration specifically implies an existing system with a defined origin and destination.
How Cloud Migration Works
At a high level, cloud migration follows a predictable arc: understand the source environment, decide what target environment and strategy fit each workload, move the workload, confirm it works correctly, and then tune it. The technical detail varies enormously by workload, but the shape stays the same.
Stage | What Happens |
|---|---|
Assessment | Inventory the source environment, map dependencies between systems, and evaluate technical readiness and business priority for each workload. |
Target design | Decide on the destination environment (public, private, or hybrid cloud) and the migration strategy for each workload, informed by cost and architecture goals. |
Migration | Replicate, copy, or rebuild the workload and its data in the target environment, typically starting with a low-risk pilot before larger waves. |
Validation | Test functionality, performance, and security in the new environment, and compare it against the original before committing to cutover. |
Optimization | After cutover, rightsize resources, decommission the old environment where appropriate, and continue tuning cost and performance. |
Each of these stages is covered in depth in the process section later in this guide, but this is the mental model worth holding onto: migration is not a single event. It is a sequence of assessed, deliberate decisions repeated across many workloads, usually organized into waves rather than attempted all at once.
What Can Be Migrated to the Cloud?
Not everything in an IT estate is equally easy to move, and the difficulty differs by category.
Category | Typical Migration Difficulty | Why |
|---|---|---|
Stateless web applications | Lower | Few dependencies on local hardware; often rehostable with limited changes. |
Relational databases | Moderate to high | Data volume, replication needs, and downtime tolerance during cutover matter. |
Legacy monolithic applications | High | Tight coupling between components and hidden dependencies increase risk. |
Unstructured files and backups | Lower to moderate | Straightforward to copy, but large volumes affect transfer time and cost. |
Specialized or licensed hardware workloads | High | May require specific hardware, drivers, or licensing terms unsuited to the cloud. |
Networking and security configuration | Moderate | Must be redesigned for cloud-native constructs rather than copied directly. |
This is why a single migration strategy rarely fits an entire estate. A payroll database and a static marketing website have almost nothing in common technically, even though both might appear on the same migration project plan.
Why Organizations Migrate to the Cloud
Migration decisions are usually driven by several business and technical pressures at once.
Exiting a data center lease or owned facility that is expensive or nearing end of life
Avoiding a hardware refresh cycle for aging on-premises servers and storage
Gaining elasticity to handle unpredictable or seasonal demand without over-provisioning
Improving resilience and disaster recovery options across geographic regions
Expanding into new geographic markets faster than building local infrastructure would allow
Accessing managed services for databases, analytics, and AI without operating the underlying infrastructure
Supporting mergers, acquisitions, or divestitures that require consolidating or separating IT estates
Enabling a distributed or remote workforce that needs access from many locations
Retiring platforms that vendors no longer support or patch
Pursuing cost optimization, though this outcome depends heavily on how the migration and the resulting environment are managed
That last point deserves emphasis. Moving to the cloud can lower costs, but it is not automatic. Costs shift from fixed capital expenditure to variable operating expenditure, and ungoverned variable costs can grow as easily as they shrink. Organizations that realize savings pair migration with rightsizing, automation, and ongoing cost governance — not just a change of address.
Types of Cloud Migration
Migration projects are usually described by their scope and direction. Understanding which type applies helps set expectations for complexity and timeline.
Data-center-to-cloud migration — moving an entire physical facility's workloads to the cloud, often tied to a lease expiration or facility closure.
Application migration — moving a specific application and its supporting components, independent of the rest of the estate.
Data and database migration — moving datasets or database engines, sometimes independently of the applications that use them.
Workload-specific migration — targeting a narrow function, such as a batch reporting job or a single microservice.
Cloud-to-cloud migration — moving workloads from one public cloud provider to another, often for cost, feature, or contractual reasons.
Hybrid migration — moving some components to the cloud while intentionally keeping others on-premises or in a private cloud, connected by dedicated networking.
Selective or partial migration — migrating only the workloads that clearly benefit, while leaving others in place indefinitely.
These categories are not mutually exclusive — a single program might combine a data-center exit with individual application migrations, some public cloud and some deliberately hybrid.
Cloud Deployment and Service Models Relevant to Migration
The target operating model shapes which migration strategy makes sense, so it helps to be precise about the terms.
Deployment models
Public cloud — infrastructure owned and operated by a third-party provider and shared across multiple customers (NIST SP 800-145).
Private cloud — infrastructure provisioned for exclusive use by a single organization, which may be managed on-premises or by a third party.
Hybrid cloud — a combination of public and private (or on-premises) infrastructure, connected so workloads and data can move between them.
Multicloud — use of more than one public cloud provider, whether by deliberate strategy or as a result of mergers and independent team decisions.
Service models
Infrastructure as a Service (IaaS) — the provider manages physical infrastructure; the customer manages the operating system, runtime, and application.
Platform as a Service (PaaS) — the provider also manages the operating system and runtime, so the customer focuses on application code and data.
Software as a Service (SaaS) — the provider manages the entire stack, and the customer consumes a finished application.
Moving a VM to IaaS unchanged is a very different project than moving that workload's function to a PaaS-managed database or SaaS replacement. The service model target is one of the biggest levers in choosing which of the 7 Rs applies.
The 7 Rs of Cloud Migration
The 7 Rs give every application in a portfolio a defined strategy instead of assuming that everything should be moved the same way. The framework traces back to an earlier Gartner "5 Rs" model and has been formalized and expanded by AWS into the seven strategies used most widely today: rehost, relocate, replatform, repurchase, refactor, retire, and retain (AWS, "What Is a Cloud Migration Strategy?").
Rehost
Rehost, often called “lift and shift,” moves an application to the cloud with little or no change to its code or architecture. The operating system and application stack move largely as-is onto cloud virtual machines.
When it makes sense: tight deadlines, such as an expiring data center lease, or limited in-house cloud expertise.
Advantages: fastest path to the cloud; lowest short-term risk and effort.
Limitations: does not take advantage of cloud-native features, so cost and performance gains may be limited until further optimization.
Example: moving an existing virtual-machine-based application to cloud virtual machines with minimal architectural change.
Relocate
Relocate moves compatible virtualized infrastructure to a cloud-based equivalent at the hypervisor level, without touching the guest operating system or application.
When it makes sense: an existing virtualization platform, such as VMware, has a matching cloud-hosted equivalent.
Advantages: very fast, since applications are untouched; minimal retraining for operations teams.
Limitations: still runs on the same virtualization stack, so it captures fewer cloud-native benefits than replatforming or refactoring.
Example: moving a set of VMware virtual machines to a cloud-based VMware environment with little application change.
Replatform
Replatform, sometimes called “lift, tinker, and shift,” makes limited, targeted changes during migration — often adopting a managed service — without changing the application's core architecture.
When it makes sense: a workload can gain real operational benefit from a managed service without a full rewrite.
Advantages: reduces operational burden (patching, backups) by shifting it to the provider; moderate effort for moderate benefit.
Limitations: still carries forward some of the original design's constraints and technical debt.
Example: moving a self-managed database to an appropriate managed database service while making limited changes to the application that connects to it.
Repurchase
Repurchase, or “drop and shop,” replaces an existing application with a commercial SaaS alternative rather than migrating the original system at all.
When it makes sense: the application is a commodity function, such as HR, CRM, or expense management, where a mature SaaS product exists.
Advantages: shifts maintenance and upgrades entirely to the vendor; often the fastest way to gain modern functionality.
Limitations: may require data migration, process change, and user retraining; introduces dependency on the new vendor.
Example: replacing an on-premises commodity application with an equivalent SaaS product.
Refactor (Re-architect)
Refactor redesigns an application to take fuller advantage of cloud-native capabilities, such as containers, microservices, or serverless functions.
When it makes sense: a strategically important application needs improved scalability, agility, or feature velocity that its current architecture cannot deliver.
Advantages: unlocks the largest long-term gains in scalability, resilience, and development speed.
Limitations: the most time-consuming and expensive strategy, and carries the highest technical risk; AWS Prescriptive Guidance notes it is generally not recommended for large-scale migrations because of this complexity.
Example: redesigning a strategically important monolithic application into cloud-native, independently deployable services.
Retire
Retire decommissions an application that no longer provides business value rather than migrating it at all.
When it makes sense: usage analysis shows the application has little or no active use, or its function has been absorbed elsewhere.
Advantages: removes cost, licensing, and security surface area before migration effort is spent on it.
Limitations: requires confidence that no hidden dependency relies on the system; needs a defined decommissioning process.
Example: shutting down an internal reporting tool that has been superseded and confirming no other system depends on it.
Retain
Retain deliberately keeps a workload in its current environment for now, rather than migrating it on the current timeline.
When it makes sense: the workload is latency-sensitive, tied to specialized hardware, recently upgraded, or blocked by regulatory constraints.
Advantages: avoids forcing a migration where the business case, technical fit, or timing is not yet right.
Limitations: the workload still needs to be operated and secured in its current environment, and it may need to be revisited later.
Example: keeping a latency-sensitive industrial control system in a local data center rather than migrating it prematurely.
Retain and retire are legitimate portfolio decisions, not failures to migrate. A realistic migration plan treats “not now” and “never” as valid outcomes for specific workloads, provided the decision is based on an honest technical and business assessment rather than inertia.
Strategy | Effort | Best Fit | Main Trade-off |
|---|---|---|---|
Rehost | Low | Fast data center exits, limited cloud skills | Limited cloud-native benefit until optimized later |
Relocate | Low | Existing virtualization platform with a cloud equivalent | Still bound to the original virtualization stack |
Replatform | Moderate | Workloads that benefit from a managed service | Some legacy design constraints remain |
Repurchase | Moderate | Commodity applications with mature SaaS options | Vendor dependency and data migration effort |
Refactor | High | Strategic applications needing cloud-native scale | Highest cost, time, and technical risk |
Retire | Very low | Applications with no remaining business value | Requires confidence dependencies are cleared |
Retain | None (for now) | Latency-sensitive, regulated, or recently upgraded systems | Still must be operated and secured where it is |
Before assigning strategies workload by workload, most organizations first rationalize the portfolio — identifying overlap, dead weight, and strategic importance — so effort is not spent moving something that should have been retired.
The Cloud Migration Process: Step by Step
Cloud providers describe this journey with slightly different labels, but the underlying phases converge. AWS Prescriptive Guidance, Microsoft's Cloud Adoption Framework, and Google Cloud's migration framework all organize migration around assessment, foundation-building, execution, and post-migration optimization (AWS Prescriptive Guidance; Microsoft Learn, Cloud Adoption Framework; Google Cloud Architecture Center, "Migrate to Google Cloud: Get started").
Phase | Key Activities |
|---|---|
1. Define objectives | Establish business goals and success criteria; secure executive sponsorship and budget. |
2. Discover and assess | Inventory the estate, map application and data dependencies, and evaluate technical readiness. |
3. Classify and strategize | Assign a 7 Rs strategy to each workload and build the business case and total cost of ownership (TCO) model. |
4. Build the foundation | Select cloud provider and services, and establish the landing zone: identity, networking, security, and governance. |
5. Sequence and pilot | Prioritize workloads, group them into migration waves, and run a low-risk pilot migration. |
6. Migrate | Replicate data, migrate applications, and prepare rollback and contingency plans for each wave. |
7. Validate and cut over | Test functionality and performance, then execute production cutover on a defined schedule. |
8. Decommission and optimize | Retire legacy resources where appropriate, and continue rightsizing and modernizing after go-live. |
A few of these steps deserve more detail because they determine whether a migration goes smoothly or turns into a source of recurring incidents.
Discovery and dependency mapping
Discovery means building an accurate, current inventory of servers, applications, and data, not the inventory that existed on paper two years ago. Dependency mapping then traces which systems talk to which others, since an app that looks self-contained may quietly depend on a shared service running elsewhere. Migrations that skip this step are the ones most likely to discover a hidden dependency during cutover.
Building the business case and TCO model
A credible business case compares the fully loaded cost of the current environment (hardware, facilities, licensing, labor) against the anticipated cloud environment (compute, storage, transfer, managed services, labor). TCO models that omit data egress fees, parallel-running costs, or retraining tend to understate the real cost of the move.
Pilot migrations and waves
Rather than migrating an entire estate at once, most programs run a pilot on a low-risk, well-understood workload first. Lessons from that pilot — tooling gaps, unexpected dependencies, process bottlenecks — get folded into the plan before larger migration waves begin. This is covered further in the section on migration waves below.
Cutover and rollback
Cutover is the moment operations formally move to the new environment. Because it carries the highest project risk, most migrations pair cutover with a tested rollback plan: a defined way to revert if validation fails. Ongoing data replication and phased cutover can reduce downtime, but requirements vary by workload, and zero downtime is not a universal guarantee.
What Is a Cloud Landing Zone?
A landing zone is the secure, governed foundation built in the cloud before migrating workloads at scale. Microsoft's Cloud Adoption Framework describes an Azure landing zone as “a proven and flexible architecture for governing, securing, and scaling a multi-subscription” cloud environment (Microsoft Learn, "What is an Azure landing zone?"). Equivalent concepts exist across providers under names like landing zones, foundations, or organizations.
A landing zone typically defines:
Identity — how users and services authenticate and what they are authorized to do
Accounts, subscriptions, or projects — how resources are organized and isolated from one another
Network architecture — connectivity between the cloud environment, on-premises systems, and the internet
Security baseline — default policies for encryption, access control, and monitoring
Logging and observability — centralized visibility into activity and system health
Policies and governance — automated guardrails that enforce standards across every workload
Cost controls — budgets, tagging standards, and alerts that keep spending visible
Setting up this foundation first reduces risk considerably. Without it, each migrated workload reinvents its own security and network approach, multiplying the chance of misconfiguration.
Migration Waves and Dependency Mapping
Migrations are almost always phased into waves rather than executed as a single cutover, because moving hundreds or thousands of interconnected systems simultaneously is operationally unmanageable and dramatically increases risk.
Application groups — workloads with shared dependencies are usually migrated together so that connections between them are not broken mid-project.
Business criticality — lower-risk, less critical systems are often migrated earlier to build confidence and refine process.
Technical complexity — simpler, well-documented systems tend to move in early waves; complex or poorly understood systems move later, once the team has more experience.
Pilot waves — an initial small wave validates tooling, process, and assumptions before committing to the full schedule.
Learning between waves — each wave's retrospective feeds into the plan for the next, refining timelines and identifying overlooked dependencies.
Cutover coordination — waves that touch shared infrastructure, like a common database or identity system, require tighter coordination to avoid conflicting changes.
Dependency mapping is what makes sensible sequencing possible. Without it, sequencing is guesswork, and it is common to discover mid-migration that a “later wave” system is actually required by something already migrated.
Benefits of Cloud Migration
Cloud migration can deliver real advantages, but each one depends on conditions being met rather than arriving automatically the moment a workload lands in the cloud.
Potential Benefit | Condition Needed to Realize It |
|---|---|
Scalability and elasticity | Application architecture must support scaling out, and auto-scaling must be configured correctly. |
Faster provisioning | Infrastructure-as-code and self-service processes must replace manual procurement steps. |
Resilience and disaster recovery | Multi-region or multi-zone architecture and tested recovery procedures must be in place. |
Access to managed services and AI/analytics | Teams must adopt the managed services rather than replicating self-managed infrastructure in the cloud. |
Reduced hardware management burden | Workloads must actually move off self-managed infrastructure, not just relocate the same operational model. |
Cost optimization | Rightsizing, automation, and ongoing FinOps discipline must be applied continuously, not just at launch. |
Improved developer productivity | Teams need modern deployment pipelines and managed platforms, not just cloud-hosted equivalents of old processes. |
The common thread: migration creates the opportunity for these benefits, but realizing them takes deliberate architecture and operating-model choices on top of the move.
Cloud Migration Challenges and Risks
Migrations fail or run over budget for recognizable, recurring reasons. Naming them in advance helps mitigate them.
Challenge | Why It Happens | Mitigation |
|---|---|---|
Hidden dependencies | Discovery was incomplete or outdated. | Invest in automated dependency mapping before sequencing. |
Downtime during cutover | Cutover windows underestimated or rollback untested. | Rehearse cutover, replicate data ahead of time, define rollback criteria. |
Data loss or corruption | Tooling or process lacks validation checkpoints. | Checksum and reconcile data before/after transfer; keep the source intact until validated. |
Skills gaps | Teams know on-premises operations but not cloud-native tooling. | Train early and pair staff with experienced partners in the first waves. |
Cost overruns and cloud sprawl | Resources provisioned without tagging or budget discipline. | Apply tagging standards and regular utilization reviews from day one. |
Security misconfiguration | Cloud-native controls differ from on-premises defaults. | Use landing zone security baselines and validate configurations before go-live. |
Compliance and data residency gaps | Requirements were not mapped to specific regions. | Confirm residency and compliance needs per workload before selecting regions. |
Vendor lock-in concerns | Heavy use of provider-specific services reduces portability. | Weigh portability against managed-service benefits deliberately, not by default. |
Data transfer time and egress costs | Large datasets cost more to move and access than expected. | Estimate transfer volumes and evaluate offline transfer for very large datasets. |
Incomplete testing | Testing covers functionality but skips performance and failure scenarios. | Test performance, failover, and security, not just feature parity. |
Most of these risks share a root cause: rushing past discovery and validation to hit a deadline. Programs that protect time for assessment and testing report fewer post-migration incidents.
Cloud Migration Security and Compliance
Migrating to the cloud does not make a workload automatically more secure or automatically less secure — responsibility for security shifts and changes shape, but it does not disappear. Every major provider operates under a shared responsibility model: the provider secures the underlying infrastructure (“security of the cloud”), while the customer remains responsible for securing what they build and configure on top of it (“security in the cloud”), including data, identity, and application-level controls (AWS, "Shared Responsibility Model").
A migration security checklist typically includes:
Identity and access management with least-privilege permissions
Multi-factor authentication (MFA) for administrative and privileged accounts
Encryption in transit and at rest for data moved to and stored in the cloud
Centralized secrets and key management rather than credentials embedded in code or configuration files
Network segmentation to limit the blast radius of a compromised system
Data classification to identify which datasets carry the highest sensitivity or regulatory weight
Centralized logging and monitoring across the migrated environment
Ongoing vulnerability management and patching
Tested backup and disaster recovery procedures
Security testing — including configuration review — before cutover, not only afterward
Compliance requirements, including data residency and sovereignty, should be mapped to specific regions and controls before workloads are placed, not discovered afterward. Where regulation constrains where data can live, that should directly shape both the target region and, sometimes, the choice between public, private, or hybrid cloud.
Cloud Migration Costs and Financial Planning
“The cloud is cheaper” is an oversimplification. Cloud economics depend on architecture, utilization, commitment models, licensing, transfer patterns, and governance — Flexera's 2026 State of the Cloud Report found organizations estimate 29% of public cloud spend goes to waste, the first increase in five years (Flexera 2026 State of the Cloud Report). Poor governance, not the cloud itself, usually drives spend higher than expected.
A realistic financial plan accounts for cost categories on both sides of the ledger:
Current-state baseline: hardware depreciation, facilities, licensing, and labor for the existing environment
Compute, storage, and database costs in the target cloud environment
Network traffic and data egress fees, which are often underestimated
Migration tooling and any parallel-running costs while both environments operate simultaneously
Licensing changes, including software that may need new agreements in the cloud
Labor, consulting, and training required to execute the migration and operate the new environment
Backup, disaster recovery, and observability tooling in the new environment
Support plans and ongoing vendor costs
After cutover, cost management does not stop. FinOps typically includes rightsizing over-provisioned resources, identifying idle resources, and reviewing commitment discounts against actual usage. Decommissioning legacy hardware is also necessary to realize the savings side of the business case; keeping old servers running “just in case” erases much of the expected benefit.
Choosing a Cloud Provider or Target Platform
There is no universally superior cloud provider; the right choice depends on workload fit and organizational context. AWS, Microsoft Azure, and Google Cloud each offer broad service catalogs, and the practical decision usually comes down to specifics rather than brand.
Workload fit — whether the required managed services (databases, AI/ML, analytics) exist and mature on that platform
Regions and data residency — whether the provider has data center presence where compliance requires it
Existing skills and tooling — which platform the team already knows, and which reduces training time
Existing enterprise agreements — licensing relationships that may make one provider meaningfully cheaper
Ecosystem and third-party support — availability of partners, integrations, and marketplace tools
Migration tooling maturity — how well the provider supports the specific migration types the workload needs
Portability and lock-in considerations — how much the target architecture depends on provider-specific services
Total cost of ownership — modeled for the specific workloads in question, not a generic price comparison
Some organizations deliberately use more than one provider for different workloads (multicloud), while others choose to consolidate on one platform to reduce operational complexity. Both are legitimate strategies; the right one depends on the organization's risk tolerance, skills, and the degree to which workloads genuinely benefit from provider-specific capabilities.
Cloud Migration Tools
Migration tooling generally falls into a small number of functional categories, regardless of which specific products an organization chooses.
Discovery and inventory tools — catalog existing servers, applications, and configurations
Dependency-mapping tools — trace communication between systems to inform sequencing
Assessment tools — evaluate technical readiness, sizing, and estimated cloud cost
Database migration tools — replicate and cut over database engines, often with minimal downtime
Data-transfer tools — move large volumes of files or backups, including offline transfer appliances for very large datasets
VM and server migration tools — replicate virtual or physical servers into cloud-hosted equivalents
Infrastructure-as-code tools — define landing zones and environments in version-controlled configuration
Observability and monitoring tools — provide visibility into performance and health during and after migration
Cost-management tools — track and forecast spend across the migrated environment
Each major provider offers services in most of these categories: for example, AWS provides Application Migration Service for server rehosting and Database Migration Service for database moves; Microsoft offers Azure Migrate as an integrated discovery-and-migration platform; and Google Cloud provides Migration Center for discovery and cost estimation alongside Migrate to Virtual Machines for server migration (Google Cloud Architecture Center, "Migrate to Google Cloud: Get started"). Confirm current product names and capabilities directly with the provider's documentation before committing to a specific toolchain, since this category of product evolves quickly.
Cloud Migration Best Practices
Start with business outcomes — tie every technical decision back to why the migration is happening.
Inventory before migrating — build a current, verified asset inventory rather than relying on outdated records.
Map dependencies — trace system connections before sequencing, to avoid breaking hidden integrations.
Apply the 7 Rs deliberately — do not default every workload to rehosting.
Establish landing-zone foundations early — identity, network, and security baselines before large-scale movement begins.
Start small — use a pilot migration to surface tooling and process issues while stakes are low.
Use migration waves — sequence by dependency, criticality, and complexity, not a single cutover.
Automate repeatable work — use infrastructure as code to cut manual, error-prone steps.
Build security in from the start — not as a retrofit after go-live.
Maintain rollback capability — keep a tested path back to the source environment until validation is complete.
Test comprehensively — validate performance and failure scenarios, not only feature parity.
Establish observability before cutover, not after an incident.
Train teams early, not during a crisis.
Monitor costs continuously rather than only at project kickoff.
Define clear ownership for each workload's operation and cost after cutover.
Optimize after cutover — treat go-live as the start of an improvement cycle, not the end of the project.
Document lessons learned after each wave and apply them to the next.
Cloud Migration Checklist
Phase | Checklist Items |
|---|---|
Strategy | Business objectives defined · Success criteria agreed · Executive sponsorship secured |
Discovery | Asset inventory complete · Dependency map built · Data classification done |
Assessment | Technical readiness scored per workload · 7 Rs strategy assigned · TCO model built |
Architecture | Target cloud and services selected · Landing zone designed · Portability trade-offs reviewed |
Security | Identity and access model defined · Encryption standards set · Compliance and residency mapped |
Planning | Migration waves sequenced · Rollback plan defined · Communication plan in place |
Pilot | Low-risk workload selected · Tooling validated · Lessons captured for later waves |
Migration | Data replicated and validated · Applications migrated per wave · Parallel environments monitored |
Validation | Functional testing complete · Performance testing complete · Security review passed |
Cutover | Cutover window scheduled · Rollback criteria confirmed · Stakeholders notified |
Post-migration | Legacy resources decommissioned · Costs rightsized · Continuous optimization scheduled |
Cloud Migration KPIs: How to Measure Success
Migration success should be measured against the original business case, not simply by counting how many servers moved. Useful KPI categories include:
Migration completion rate against the planned schedule
Application availability and error rate before versus after migration
Latency and performance benchmarks compared to the source environment
Incident rate during and after cutover
Recovery Time Objective (RTO) and Recovery Point Objective (RPO) achieved in practice, not only on paper
Infrastructure utilization and rightsizing progress
Cloud spend against budget, including cost per workload or business unit where relevant
Deployment frequency and time to provision new environments
User experience metrics, such as page load time or transaction completion rate
Security and compliance findings identified and remediated
Decommissioning completion for legacy infrastructure
Progress against the specific business outcomes defined at the start of the program
A migration that moves every server on schedule but misses its cost or resilience targets has not fully succeeded. Tie KPI reporting back to the objectives set in the business case, and revisit them at fixed intervals after cutover, not only at the moment of go-live.
Cloud Migration Example (Hypothetical)
The following scenario is a hypothetical illustration, not a real company, used to make the 7 Rs and the migration process concrete.
A mid-sized company needs to leave an aging, expensive on-premises data center within eighteen months. It begins by inventorying roughly 50 applications. The assessment finds that about 8 of them have not been used in over a year and are marked for retirement. Around 6 are tied to specialized, latency-sensitive equipment on the factory floor and are retained on-premises for now, pending a future review. The company replaces its on-premises HR system with a SaaS product (repurchase) and moves several legacy line-of-business applications to cloud virtual machines largely unchanged (rehost) to hit the deadline. Its primary transactional database is moved to a managed database service with modest application changes (replatform). One application — the company's core order-management system, which is central to competitive differentiation — is redesigned into cloud-native services over a longer timeline (refactor), running in parallel with the legacy version until validation is complete.
Before any of the larger waves begin, the company builds a landing zone: identity, network segmentation, logging, and security baselines. It pilots the migration with two low-risk, well-understood applications, capturing lessons about its chosen migration tooling. It then sequences the remaining applications into three waves based on dependency and business criticality, testing and validating each wave before cutover and keeping a rollback plan ready for the higher-risk workloads. After the final wave, it decommissions the data center hardware for the retired and rehosted applications and begins a rightsizing exercise, adjusting virtual machine sizes that were initially over-provisioned during the rushed rehost phase.
Cloud Migration vs. Cloud Modernization vs. Cloud Adoption
These three terms describe related but distinct activities, and mixing them up leads to unclear project scope.
Term | What It Primarily Means |
|---|---|
Cloud migration | Moving existing workloads, data, or environments from one location to another, typically into the cloud. |
Cloud modernization | Changing an application's architecture, platform, or operating method to better use modern cloud capabilities — with or without a migration event attached. |
Cloud adoption | The broader organizational integration of cloud capabilities: processes, governance, skills, and operating models across the business, of which migration is one part. |
A rehosted application has been migrated but not modernized. A new serverless app built directly in the cloud is modernized but was never migrated, since there was no prior system to move. Cloud adoption is the umbrella covering both, plus the governance, FinOps, and skills that make ongoing cloud use sustainable.
Cloud Migration vs. Data Migration
Data migration — moving datasets from one storage system or format to another — is frequently a component of cloud migration, but the two concepts are not identical. A data migration can happen entirely within an on-premises environment, such as consolidating two databases during a merger, with no cloud involvement at all. Conversely, a cloud migration can involve moving an application with very little data, or data that stays in place while only the compute layer moves. Treating data migration as a subset of the larger project, with its own validation and rollback plan, avoids conflating a database cutover with the broader application and infrastructure move happening around it.
When Cloud Migration May Not Be the Right Choice
Migration is not universally beneficial, and a credible migration strategy explicitly accounts for workloads that should stay put.
Extremely latency-sensitive workloads that require physical proximity to specific equipment or users
Systems tied to specialized hardware that has no practical cloud equivalent
Regulatory or contractual limitations that require certain data or processing to remain on specific premises
Unsupported legacy systems that cannot run reliably in a virtualized or cloud environment without a rebuild
Workloads where the cloud business case is unfavorable once transfer, egress, and licensing costs are modeled realistically
Applications nearing the end of their useful life, where investing in migration effort delivers little remaining value
Systems with large sunk investment in recently purchased on-premises infrastructure that has not yet been depreciated
Data gravity situations, where the cost and complexity of moving very large datasets outweighs the benefit
Workloads where no meaningful scalability, resilience, or managed-service benefit would be realized by moving
None of these conditions are permanent — a workload retained today may become a good candidate once constraints change. Migration should be justified case by case, not pursued as a goal in itself.
What Happens After Cloud Migration?
Cutover is not the end of the project; it is the start of an ongoing operating phase. Post-migration activity typically includes:
Cost optimization and rightsizing based on real usage patterns rather than initial estimates
Governance maturity — refining policies as more workloads and teams use the environment
Security hardening based on what monitoring reveals once the workload is live
Building or maturing observability across the new environment
Automating operational tasks that were done manually during the initial migration
Modernizing rehosted or replatformed workloads incrementally, now that they run in the cloud
Ongoing FinOps practices to keep spend aligned with business value
Skills development, so operating teams grow more fluent with the platform over time
Cloud placement is also not necessarily permanent. Some organizations later move specific workloads back to on-premises or private infrastructure — a pattern known as cloud repatriation — usually driven by cost economics for steady, predictable workloads, latency requirements, or a reassessment of which environment best fits a given system now that it is better understood. Repatriation is typically selective rather than a full retreat from the cloud, and often results in a more deliberate hybrid architecture rather than an all-or-nothing choice.
Is Cloud Migration Right for Your Organization?
Rather than repeating the guide, use four questions as a practical decision framework.
Business goals: Is there a clear driver — a lease expiration, a scalability need, a modernization goal — or is migration being pursued without a defined outcome?
Workload characteristics: Which applications are strong candidates for rehosting, replatforming, or refactoring, and which are better retained or retired?
Risk and compliance: What are the data residency, security, and continuity requirements, and can the target environment meet them?
Organizational readiness: Does the team have the skills, budget, and governance discipline to execute the migration and operate the result well?
Where the answers are clear and favorable, migration is likely to deliver real value. Where they are vague — no defined business driver, no workload assessment, no governance plan — that is a signal to invest in assessment and planning before committing to a timeline.
Frequently Asked Questions
What is cloud migration in simple terms?
Cloud migration means moving an application, database, or IT system from where it runs today — usually an on-premises server or another cloud — into a cloud computing environment. It can be a small, single-application move or a full data center exit.
What is an example of cloud migration?
A common example is moving a company's on-premises database to a managed cloud database service, or moving virtual machines from a private data center to cloud-hosted virtual machines with minimal changes (rehosting).
What are the 7 Rs of cloud migration?
The 7 Rs are rehost, relocate, replatform, repurchase, refactor (re-architect), retire, and retain. Each represents a different strategy for handling a specific workload, from moving it unchanged to redesigning it or leaving it where it is.
What are the main types of cloud migration?
The main types include data-center-to-cloud migration, application migration, data and database migration, workload-specific migration, cloud-to-cloud migration, hybrid migration, and selective or partial migration.
How long does cloud migration take?
Duration depends heavily on scope, the number of dependencies, data volume, compliance requirements, and the chosen migration strategy. A single rehosted application might take weeks, while a full data center exit with refactoring can take well over a year.
How much does cloud migration cost?
Cost varies by workload count, data volume, chosen migration strategies, and target architecture. A realistic estimate requires a total cost of ownership model covering compute, storage, data transfer, licensing, tooling, and labor rather than a single universal figure.
Is cloud migration secure?
Cloud migration can be secure when identity, encryption, network segmentation, and monitoring are properly configured, but security is not automatic. Under the shared responsibility model, the provider secures the underlying infrastructure while the customer remains responsible for configuration, data protection, and access control.
What are the biggest risks of cloud migration?
Common risks include hidden application dependencies, downtime during cutover, data loss without proper validation, skills gaps, cost overruns, security misconfiguration, and compliance or data residency gaps.
What is lift and shift?
Lift and shift is another name for the rehost strategy: moving an application to the cloud with little or no change to its code or architecture, typically onto cloud virtual machines.
What is the difference between rehosting and replatforming?
Rehosting moves a workload with no meaningful change to its architecture. Replatforming makes limited, targeted changes during the move — often adopting a managed service — without a full architectural redesign.
What is the difference between cloud migration and cloud modernization?
Cloud migration is about moving a workload to a new environment. Cloud modernization is about changing its architecture or platform to better use modern capabilities. A workload can be migrated without being modernized, or modernized without ever having been migrated.
What is cloud-to-cloud migration?
Cloud-to-cloud migration is the process of moving workloads or data from one public cloud provider to another, often driven by cost, feature differences, or contractual changes.
Can all applications be migrated to the cloud?
No. Some applications are better retained on-premises, at least for now, due to latency requirements, specialized hardware, regulatory constraints, or an unfavorable cost-benefit case. Retaining a workload is a legitimate decision, not a failure.
What should be migrated first?
Many organizations start with lower-risk, well-understood workloads to pilot their tooling and process, then sequence remaining applications into waves based on business criticality, technical complexity, and dependencies.
What happens after cloud migration?
After cutover, organizations typically focus on rightsizing resources, hardening security based on live monitoring, decommissioning legacy infrastructure, and continuing to optimize cost and performance on an ongoing basis.
What is cloud repatriation?
Cloud repatriation is the practice of moving specific workloads from public cloud back to on-premises or private infrastructure, usually for cost, latency, or control reasons. It is typically selective rather than a full exit from the cloud.
Key Takeaways
Cloud migration means moving existing workloads and data, whereas cloud-native development starts fresh in the cloud with nothing to migrate.
No single migration strategy fits an entire application portfolio; the 7 Rs exist because different workloads need different approaches.
A landing zone built before large-scale migration reduces security and operational risk far more cheaply than fixing it afterward.
Rehosting is often the fastest path to the cloud, but it typically leaves cloud-native cost and performance benefits unrealized until further optimization.
Refactoring unlocks the largest long-term benefit but carries the highest cost, time, and risk, and is not recommended for every workload.
Cost savings and improved security are possible outcomes of migration, not guaranteed ones — both depend on how the environment is configured and governed afterward.
Decommissioning legacy infrastructure is necessary to actually realize the savings a migration business case promised.
Migration success should be measured against the original business objectives, not simply by counting how many systems were moved.
Retaining or retiring a workload instead of migrating it can be the financially and technically correct decision.
Actionable Next Steps
Define the specific business outcomes the migration needs to achieve, and get executive sponsorship for them.
Build a verified inventory of workloads, data, and infrastructure across the current environment.
Map dependencies between applications, databases, and shared services before deciding on sequencing.
Classify each workload using the 7 Rs framework rather than defaulting everything to a single strategy.
Document security, compliance, and data residency requirements for each workload before selecting target regions.
Build a total cost of ownership model that includes data transfer, licensing, tooling, and labor, not just compute.
Design and deploy a landing zone — identity, network, security, and governance — before large-scale migration begins.
Choose a low-risk pilot workload to validate tooling and process before committing to a full schedule.
Define validation criteria and a tested rollback plan for each migration wave.
Sequence remaining workloads into migration waves based on dependency, criticality, and complexity.
Glossary
Application dependency: A relationship where one system relies on another, such as an app needing a specific database or login service.
Availability: The proportion of time a system is up and accessible.
Cloud adoption: The wider organizational integration of cloud capabilities, governance, and skills.
Cloud migration: Moving applications, data, or infrastructure into a cloud environment.
Cloud modernization: Changing an app's architecture or platform to use modern cloud capabilities.
Cloud-native: Software built from the outset to use cloud capabilities like containers or serverless functions.
Cutover: The point operations formally switch from the source to the new environment.
Data residency: A rule that data must be stored or processed within a specific jurisdiction.
Dependency mapping: Identifying and documenting how systems rely on one another.
Disaster recovery: Plans and systems used to restore operations after a disruption.
FinOps: A discipline for bringing financial accountability to variable cloud spend.
Hybrid cloud: Public and private (or on-premises) infrastructure connected so workloads can move between them.
IaaS: The provider manages physical infrastructure; the customer manages the OS and above.
Landing zone: A pre-built, secure, and governed foundation — identity, network, and security baseline — for hosting cloud workloads.
Migration wave: A sequenced batch of workloads migrated together based on dependency or criticality.
Multicloud: Use of more than one public cloud provider, by strategy or circumstance.
PaaS: The provider manages the OS and runtime; the customer focuses on application code.
Private cloud: Infrastructure provisioned for a single organization's exclusive use.
Public cloud: Infrastructure owned by a third-party provider and shared across customers.
Refactor: Redesigning an app's architecture to use cloud-native capabilities.
Rehost: Moving an app to the cloud with little or no code change; also called lift and shift.
Replatform: Making limited changes during migration, often to adopt a managed service.
Repurchase: Replacing an app with a commercial SaaS alternative rather than migrating it.
Retain: Deliberately keeping a workload where it is rather than migrating it now.
Retire: Decommissioning an app that no longer provides business value.
RPO: The maximum acceptable amount of data loss, measured in time.
RTO: The maximum acceptable time to restore a system after a disruption.
SaaS: The provider manages the entire stack; the customer consumes a finished product.
TCO: The fully loaded cost of a system, including infrastructure, licensing, and labor.
Workload: An application or system, with its data and infrastructure, treated as one planning unit.
Sources & References
Mell, P. and Grance, T., "The NIST Definition of Cloud Computing" (SP 800-145) — National Institute of Standards and Technology (NIST), September 2011. https://csrc.nist.gov/publications/detail/sp/800-145/final
"What Is a Cloud Migration Strategy?" — Amazon Web Services (AWS), Accessed 2026. https://aws.amazon.com/what-is/cloud-migration-strategy/
"About the Migration Strategies", AWS Prescriptive Guidance — Amazon Web Services (AWS), Updated 2026. https://docs.aws.amazon.com/prescriptive-guidance/latest/large-migration-guide/migration-strategies.html
"Shared Responsibility Model" — Amazon Web Services (AWS), Accessed 2026. https://aws.amazon.com/compliance/shared-responsibility-model/
"What Is an Azure Landing Zone?", Cloud Adoption Framework — Microsoft Learn, Updated 2026. https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/landing-zone/
"Cloud Adoption Framework for Microsoft" — Microsoft Learn, Accessed 2026. https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/
"Migrate to Google Cloud: Get Started", Cloud Architecture Center — Google Cloud, Accessed 2026. https://docs.cloud.google.com/architecture/migration-to-gcp-getting-started
"Migrate to Google Cloud: Plan and Build Your Foundation", Cloud Architecture Center — Google Cloud, Accessed 2026. https://docs.cloud.google.com/architecture/migration-to-google-cloud-building-your-foundation
Google Cloud Migration Center Documentation — Google Cloud, Accessed 2026. https://docs.cloud.google.com/migration-center/docs
Flexera 2026 State of the Cloud Report — Flexera, 2026. https://info.flexera.com/CM-REPORT-State-of-the-Cloud
"The 7 R's of Cloud Migration" — IBM Think, 2025. https://www.ibm.com/think/insights/7-rs-cloud-migration
