Every established company eventually gets the memo that it should be in the cloud. Sometimes it comes from a board that read a headline, sometimes from a hardware refresh nobody wants to fund again, sometimes from an engineer tired of babysitting a server rack. All of those are reasons to look. None of them is a reason to move everything by default. The cloud is a genuinely better place for a lot of workloads and a genuinely worse place for a few — and the difference between a migration that pays off and one that quietly triples the infrastructure bill is almost entirely in how the decision is made, not in which provider you pick.
The honest reasons to move — and the ones that are not
There are good reasons to migrate, and they are rarely the ones that appear in the vendor deck. You stop buying and racking hardware you have to guess the size of years in advance. You can scale a workload up for a launch and back down afterwards without owning the peak capacity forever. You get managed services — databases, queues, identity — that a small team would otherwise spend a year building and forever maintaining. You get geographic reach and disaster recovery that would be genuinely expensive to replicate in your own room. These are real, and for many companies they are decisive.
What is usually not a good reason is cost alone. The cloud is not automatically cheaper. It is cheaper for spiky, variable, or growing workloads, and it is often more expensive for a steady, predictable, always-on system that you have already paid for. If your server sits at forty percent load twenty-four hours a day, year in year out, renting that same capacity by the hour will cost more than owning it — you are paying a premium for an elasticity you never use. Migrate that workload for the operational reasons if they hold, but do not sell it internally on a saving that will not appear.
There is one more reason worth naming honestly, because it is real and rarely admitted: the cloud can be a way to stop competing for scarce operations talent. Racking servers, patching operating systems, and being on call for a failed disk at 3am is work fewer engineers want to do and fewer companies can staff well. Handing that undifferentiated heavy lifting to a provider frees a small team to spend its time on the software that actually distinguishes you. That is a legitimate reason to move — as long as you go in knowing you are trading a hardware bill for a software-and-egress bill, not eliminating cost.
The strategies in plain terms
The industry describes six ways to treat a workload, and stripped of the jargon they are simple choices. Rehost, also called lift-and-shift, means moving the thing as-is onto cloud servers — same software, new address. Replatform means small changes on the way — swapping your self-managed database for the provider's managed one, for instance, without rewriting the app. Refactor means reshaping the software to actually use the cloud — breaking it up, making it scale horizontally, going serverless where it fits. Repurchase means dropping the thing you run and buying a SaaS product that does the job instead. Retire means switching it off, because a surprising amount of what runs in a data centre is used by no one. And retain means deliberately leaving it where it is, because the case to move it does not hold yet.
Most real migrations use several of these at once. The skill is not knowing the six words. It is looking at each system honestly and picking the right one — and being willing to put a well-loved internal tool in the retire column.
Two of these six are the ones teams skip, and they are often the most valuable. Retire is pure profit — every workload you switch off is one you no longer migrate, secure, or pay for, and the inventory you do before a migration almost always turns up a few. Repurchase is the quiet win: a capability you have maintained for years because you built it once may now be a mature SaaS product you can rent for less than it costs to move. Look hard at both before you assume everything has to come with you.
Why lift-and-shift so often disappoints
Lift-and-shift is the tempting first move because it is the fastest and looks the least risky: no rewrite, just relocate. And for buying yourself time off failing hardware, it is a legitimate tactic. The disappointment comes when a company stops there and expects the benefits of the cloud to arrive on their own. They do not. A workload that was shaped for a fixed server does not suddenly become elastic because it now runs on rented infrastructure. You have simply moved an un-cloud-shaped system into a place that charges cloud prices, and the two worst traits of that system — it cannot scale down, and it was never designed to tolerate a machine vanishing — are now things you pay a premium for.
Lift-and-shift is a reasonable first step. It is a poor destination. If a workload is worth being in the cloud at all, it is usually worth a second phase where it is reshaped to earn its place there. Plan that phase from the start, or the migration becomes a lateral move that costs more than what it replaced.
The cost surprises nobody budgets for
The line item people plan for is compute, and compute is rarely where the shock lives. Two others do the damage. The first is egress — the charge to move data out of the cloud. Getting data in is free; getting it out, to your users, to another region, to a system you kept on-premise, is metered, and a chatty architecture that shuttles data back and forth can run up a bill that dwarfs the servers. The second is always-on waste. In your own data centre a forgotten server costs nothing extra once it is bought. In the cloud, every resource left running is billing by the second, and the default state of a hastily migrated estate is dozens of oversized instances nobody remembers to turn off.
The cloud rewards workloads that scale down and punishes ones that never do. If you migrate without changing how a system is sized and shut down, you inherit all the waste you had before, now with a meter attached to it. Budget for egress explicitly, and build the discipline to switch things off, before the first bill teaches you the same lesson more expensively.
There is an upside to the meter, and it is worth using. Every major provider will sell you the same capacity far cheaper if you commit to it in advance — a one or three year reservation, or a spending commitment. For the steady, always-on part of your estate, the part that looked expensive on demand, those commitments claw much of the premium back. The mistake is to run everything at the on-demand rate for a year out of caution and only later discover you were paying list price for capacity you were never going to turn off.
Data residency, GDPR, and where your data actually lives
For a company operating in the EU, where the data physically sits stops being a footnote. GDPR does not forbid the cloud, but it does mean you must know which region holds personal data, who the provider's sub-processors are, and what happens if data crosses a border. The major providers all offer EU regions and the contractual terms to use them properly — but only if you choose them deliberately. The default region on an account is often not in Europe, and a resource created without thinking can quietly place customer data on another continent.
Treat data residency as a design input, not a compliance clean-up at the end. Decide up front which data is personal, which regions are acceptable, and which workloads can never leave the EU — and make those choices before anything is provisioned. It is far cheaper to place data correctly than to discover after go-live that it has been sitting in the wrong jurisdiction.
It helps to remember that residency is not only about where data sits at rest but about where it is processed and who can reach it. A backup replicated to a second region for resilience, a managed service that runs its control plane elsewhere, a support engineer accessing a system from outside the EU — each is a data flow that a serious residency review has to account for. The providers give you the controls to constrain all of it; the responsibility to switch those controls on is yours.
Do it incrementally, and start with an assessment
The instinct to move everything in one coordinated cutover is the same instinct that ruins rewrites, and it fails for the same reason: it couples the whole business to a single risky date. A migration that works moves in waves. You start with something low-risk and self-contained to learn the provider, the tooling, and your own operational gaps on a workload that will not take the business down if it wobbles. You carry the lessons into the next wave. The systems that are hardest and most entangled go last, when your team actually knows what it is doing.
All of that depends on knowing what you have and what each piece is worth moving — which is why the first real deliverable is not a migration, it is an assessment. Inventory the workloads, classify each into the six strategies, map the data and its residency constraints, and estimate the run cost after the move rather than assuming it drops. That turns the cloud question from a leap of faith into a sequenced plan with a number attached, and it is the difference between a migration that pays for itself and one you quietly regret.