Cloud migration
« Back to Glossary Index
Cloud migration is the process of moving applications, data and infrastructure from on-premises environments — or from one cloud to another — onto cloud platforms such as AWS, Azure or Google Cloud. For data and analytics estates specifically, it usually means moving warehouses, pipelines and reporting onto cloud-native platforms.
The reason most programs disappoint is a mismatch of expectations: cloud migration is frequently funded as a cost-reduction exercise and delivered as a lift-and-shift, which is the one combination that reliably fails to reduce cost.
What Is Cloud Migration?
At its simplest, cloud migration changes where workloads run. In practice the scope varies enormously depending on how much is redesigned along the way, and that decision — not the move itself — determines the outcome.
The genuine benefits are elasticity, so capacity scales with demand instead of being provisioned for annual peak; removal of hardware refresh cycles and data centre overhead; access to managed services that would be impractical to run in-house; and faster provisioning, which shortens the time to start new work from months to minutes.
The benefit that is frequently assumed and often not delivered is lower cost. Cloud converts capital expenditure into operating expenditure and makes consumption visible; whether the total falls depends entirely on whether workloads were redesigned for consumption pricing.
The Migration Strategies
Six approaches are commonly used, and most programs apply several across a portfolio.
Rehost — lift and shift. Move as-is onto cloud infrastructure. Fastest, lowest risk, and delivers the least benefit. Sensible where speed matters, such as a data centre exit with a deadline.
Replatform. Move with targeted changes — swapping a self-managed database for a managed service — without rewriting the application. Often the best balance of effort and return.
Refactor. Rearchitect for cloud-native patterns. Highest cost and highest benefit, justified for workloads central to the business.
Repurchase. Replace with a SaaS product instead of migrating.
Retire. Switch off what is no longer needed. Every portfolio contains more of these than expected, and this is the cheapest saving available.
Retain. Leave in place, usually for latency, regulatory or dependency reasons. A deliberate decision to retain is legitimate; an undocumented one becomes technical debt.
Migrating Data and Analytics Workloads
Analytics migrations behave differently from application migrations, and treating them the same is a common planning error.
The data itself is rarely the hard part — bulk transfer is a solved problem. The difficulty is in the transformation logic, which has accumulated undocumented business rules over years, and in reconciliation, because the business will compare new figures against old and treat any variance as a defect regardless of which is correct.
There is also an architectural fork that application migrations do not face: whether to keep the existing warehouse model, or move to a lakehouse and push transformation into the target platform. Deciding this deliberately matters, because a like-for-like port carries forward design constraints that existed only because on-premises compute was fixed and scarce. Our cloud migration work treats that decision as the starting point rather than a detail.
The Migration Process
1. Discover and assess. Inventory workloads, dependencies, data volumes and current run costs. Dependency mapping is where the surprises are — systems nobody remembered feed something that matters.
2. Rationalize. Decide what retires before deciding what moves. Migrating unused workloads is pure waste and is entirely avoidable.
3. Choose a strategy per workload. A portfolio-wide approach is a planning shortcut that produces either excessive cost or minimal benefit.
4. Design the target. Architecture, security model, network, identity, and how cost will be monitored — before anything moves.
5. Migrate in waves. Start with lower-risk workloads to establish the pattern, keeping each wave independently reversible.
6. Validate and reconcile. For analytics, row-level comparison across a full business cycle including month-end. Aggregate checks hide offsetting errors.
7. Optimize and decommission. Right-size after observing real usage, then switch off the source. Running both indefinitely is how savings disappear — and data migration programs stall most often at this final step.
Cost: Why Cloud Bills Surprise People
The recurring pattern is a migration justified on savings that produces a higher bill. The causes are consistent and predictable.
Workloads are ported without redesign, so inefficiency that was free on owned hardware now carries a per-query price. Environments are provisioned for peak and never scaled down, reproducing on-premises sizing habits in a model that charges for idle capacity. Non-production environments run continuously when they are used during working hours. Data egress and cross-region transfer charges appear that had no on-premises equivalent. And with self-service provisioning, spend accrues from many small decisions rather than one procurement.
The controllable factor is designing for consumption from the start: autoscaling, scheduled shutdown of non-production, storage tiering, and cost attribution to teams so someone owns each line. Retrofitting this after go-live is possible but always harder than building it in.
Common Migration Risks
Undiscovered dependencies. A workload moves and something unrelated breaks, because the connection was never documented.
Reconciliation failure. New figures differ from old, trust collapses, and the program stalls while the difference is investigated. Row-level reconciliation prevents this.
Skills gap. Teams experienced in on-premises operations are asked to run cloud platforms without training, which shows up as both outages and overspend.
Security model carried over. Perimeter-based thinking maps poorly onto cloud identity and access models, producing either excessive exposure or controls so restrictive that people work around them.
Never decommissioning. The most common financial failure. Both estates run, and the business case never materializes.
Platform choice shapes everything that follows, and how Snowflake, Databricks and Fabric compare compares the main options. Decommissioning the source estate is covered in retiring legacy platforms safely.
Frequently Asked Questions
Cloud migration is the process of moving applications, data and infrastructure from on-premises environments or another cloud onto cloud platforms such as AWS, Azure or Google Cloud. For data estates it usually means moving warehouses, pipelines and reporting to cloud-native platforms.
Rehost (lift and shift), replatform (targeted changes such as adopting managed services), refactor (rearchitect for cloud-native patterns), repurchase (replace with SaaS), retire (switch off), and retain (deliberately leave in place). Most programs use several across a portfolio.
Lift and shift, or rehosting, moves workloads to cloud infrastructure largely unchanged. It is the fastest and lowest-risk approach and delivers the least benefit — and it is the main reason migrations justified on cost savings fail to deliver them.
Because workloads were ported without redesign, so inefficiency that was free on owned hardware now has a per-query price; environments are sized for peak and never scaled down; non-production runs continuously; and data egress charges appear that had no on-premises equivalent.
Bulk data transfer is straightforward. The difficulty lies in rebuilding transformation logic that carries years of undocumented business rules, and in reconciling new figures against old — because the business treats any variance as a defect regardless of which number is correct.
Discover and assess dependencies and costs, rationalize what should retire, choose a strategy per workload, design the target architecture and security model, migrate in reversible waves, validate with row-level reconciliation, then optimize and decommission the source.
Undiscovered dependencies breaking unrelated systems, reconciliation failures that collapse trust, teams lacking cloud operating skills, security models carried over from perimeter-based thinking, and never decommissioning the source estate.
It depends on portfolio size and how much is refactored rather than rehosted. A single analytics domain typically runs one to two quarters. Enterprise-wide programs run in waves across multiple years rather than as a single cutover.
