Cloud Migration Strategy: What to Move, What to Keep, and How to Decide
Cloud migration is sold as a destination. It is really a series of decisions, one per workload, and getting them wrong is how organisations end up paying more for something that works worse. Not everything belongs in the cloud, and the parts that do belong there for different reasons. Here is the honest framework we use to decide what moves, what stays, and how, from people with no cloud to sell you.
Most cloud migrations start from the wrong question. Not "should this workload be in the cloud, and why", but "how fast can we get everything across". The result is predictable: a lift of the whole estate onto rented infrastructure, a bill that lands higher than the business case promised, and a set of applications that run no better than they did, just somewhere more expensive. Cloud can be transformative when the decision is deliberate. It is a costly mistake when it is a migration for its own sake. This guide is the vendor neutral framework for telling the two apart.
We do not resell AWS, Azure or Google Cloud, and we do not take a margin on your migration. We advise, independently. That matters here more than almost anywhere, because most people telling you to move to the cloud make money when you do. We do not, so when we say a workload should stay where it is, that is analysis, not a lost sale.
The decision is per workload, not per estate
There is no single answer to "should we go to the cloud", because an estate is not one thing. It is dozens or hundreds of workloads, each with its own economics and constraints. The honest work is assessing them individually against a short list of factors that actually decide fit:
- Cost at real utilisation. Cloud rewards variable, spiky demand and punishes steady, predictable load. A workload that runs flat out around the clock is often cheaper to own than to rent.
- Data gravity. Large datasets are expensive and slow to move, and expensive to get back out. Where the data lives tends to decide where the compute should sit.
- Latency and proximity. Some workloads need to be close to users, a factory, or other systems, and the round trip to a region breaks them.
- Compliance and sovereignty. Where data is legally allowed to sit can rule a public region in or out before cost is even discussed. Our sovereign cloud guide works through that.
- Dependencies. Applications are rarely islands. Move one and you inherit the latency and cost of everything it talks to that did not move with it.
The most common and painful surprise is the bill. Cloud pricing is not just compute, it is storage tiers, data egress every time information leaves, inter region traffic, and managed service premiums. A lift and shift that looks cheaper on the compute line alone routinely costs more once the full running shape is counted. Model the genuine total cost of ownership over three to five years, at your real utilisation, before you commit, not when the first quarterly bill lands.
The migration options, in plain English
The industry has a jargon for this, the several Rs. Stripped of the buzzwords, you have five honest choices per workload:
- Rehost, or lift and shift. Move it as is onto cloud infrastructure. Fast and low effort, but you carry the inefficiencies with you and often the cost, because nothing was redesigned to suit how cloud charges.
- Replatform. Make targeted changes on the way, such as moving to a managed database, to gain real benefit without a full rebuild. Often the pragmatic middle.
- Refactor. Redesign the application to be genuinely cloud native. The most benefit and the most cost and risk, justified only where the workload matters enough.
- Retain. Leave it where it is, on premises or in a colocation. A legitimate answer, not a failure, for workloads that have no case to move.
- Retire. Migration is the best time to find what nobody uses any more and switch it off. You do not pay to move what you turn off.
A good strategy uses all five across the estate. A weak one applies a single approach, usually lift and shift, to everything, because it is the quickest to plan and the slowest to pay for.
Set the foundations before you scale
The migrations that go wrong at scale are usually the ones that skipped the groundwork. Before you move workloads in volume, the landing zone needs to exist: the account structure, identity and access model, network design, security baseline, guardrails and cost controls that everything else lands into. Retrofitting governance onto a sprawl of workloads already running is far harder than building it first. The same is true of security. Cloud is secure by shared responsibility, which means a real share of it is yours, and it has to be designed in, not assumed.
Every managed service you adopt makes the cloud more useful and harder to leave. That is not automatically wrong, deep native services can be exactly the point, but it should be a choice you made with eyes open, not a position you drifted into. Know for each significant workload how you would move it if you had to, and what that would cost. Optionality is worth keeping deliberately, because the commercial terms and your own needs both change.
Cloud is not a one way door
Sometimes the right migration decision, later, is to come back. Workloads whose demand turned out to be steady rather than spiky, or whose costs ballooned, are often cheaper repatriated to owned infrastructure, frequently in a hybrid pattern that keeps the variable in the cloud and the predictable at home. That is not an admission of failure, it is the same per workload logic applied with real data instead of a forecast. Our guide to repatriation and hybrid covers when moving back saves money, and our cloud cost guide covers getting the bill under control without moving anything.
How C4C helps
We come at this from the side that has to make the numbers real. We help you assess the estate workload by workload on fit, cost and constraint, model the true total cost of ownership before you commit rather than after, choose the right approach for each system rather than one blanket answer, and design the landing zone, governance and security so the move holds up at scale. Independent, with no cloud to resell and no margin on the migration, so the recommendation to move, to stay, or to come back is driven by your economics, not our commission. We spent years on the vendor side of infrastructure, so we know where the running costs and the lock in really hide, and that experience now sits on your side of the table. If the pressure is the bill on cloud you already run, the honest first step is often optimisation, not migration, which is where our cloud cost guide starts.
Prefer to start with a free, no obligation diagnostic? Book our Cloud Migration Assessment, an independent expert read of where you stand.
Planning a move, or rethinking one?
Tell us what you are considering, a first migration, a stalled one, a bill that grew, or a workload you are not sure belongs in the cloud at all. We will give you an independent, vendor neutral view of what should move, what should stay, and the real cost of each, with no cloud to sell you. We advise, we do not resell, so the advice follows your economics.
Prefer email? Reach us directly at hello@c4cgroup.co.uk.
Frequently asked questions
Should we move everything to the cloud?
Almost never. An estate is dozens or hundreds of workloads, each with its own economics, and a blanket move ignores that. Cloud rewards variable, spiky demand and workloads that benefit from its native services, while steady round the clock load, large fixed datasets and latency sensitive systems are often better and cheaper kept on owned infrastructure. The right strategy decides per workload on fit, cost and constraint, and is comfortable leaving some things exactly where they are.
How do you decide what to migrate to the cloud?
You assess each workload against the factors that actually decide fit: cost at its real utilisation, data gravity or how much data would have to move, latency and how close it needs to be to users or other systems, compliance and where the data is allowed to sit, and its dependencies on other systems. A workload that is variable, reasonably self contained and free of residency constraints is a strong candidate. One that runs flat out on a large fixed dataset with tight latency often is not. The decision is per workload, not per estate.
What is lift and shift?
Lift and shift, also called rehosting, means moving a workload onto cloud infrastructure largely as it is, without redesigning it. It is the fastest and lowest effort option, which is why it is popular, but it carries the existing inefficiencies across and often costs more than expected, because nothing was changed to suit how cloud charges for compute, storage and data movement. It has its place for speed, but applying it to an entire estate is the most common way migrations overspend.
Why do cloud migrations cost more than expected?
Because the compute line is only part of the bill. Cloud also charges for storage tiers, data egress every time information leaves, traffic between regions, and premiums on managed services, and these are easy to miss in a business case built on server costs alone. A lift and shift that looked cheaper on compute routinely costs more once the full running shape is counted. The fix is to model the genuine total cost of ownership at your real utilisation, over three to five years, before you commit rather than after the first bills arrive.
What is a cloud landing zone?
A landing zone is the foundation you build before migrating workloads in volume: the account structure, identity and access model, network design, security baseline, guardrails and cost controls that everything else lands into. Setting it up first means workloads arrive into a governed, secure and cost controlled environment. Skipping it and retrofitting governance onto a sprawl of workloads already running is far harder and riskier, which is why the migrations that go wrong at scale are usually the ones that skipped this step.
How do you avoid cloud lock in?
By treating it as a deliberate choice rather than an accident. Every managed service you adopt makes the cloud more useful and harder to leave, which can be exactly the point, but you should know for each significant workload how you would move it and what that would cost. Keep that optionality on purpose where it matters, use portable approaches where the native service adds little, and go deep on proprietary services only where the benefit clearly justifies the reduced flexibility. The goal is not to avoid all lock in, it is to never be locked in by surprise.