What does moving to the cloud cost?
A cloud migration usually costs between SEK 300,000 and 5 million depending on strategy. Lift-and-shift, where servers move as-is, sits at the bottom of the range; replatform in the middle; a refactor to cloud-native architecture at the top. Budget for double operating costs during the transition too, when the old and new environments run in parallel.
What does it cost to move to the cloud? The question concerns the move itself – the project – and it should be kept separate from what operations cost afterward. The migration project has its own budget, its own risks, and a price range that’s almost entirely driven by which strategy you choose.
Three strategies, three price tiers
| Strategy | Typical cost | What it means |
|---|---|---|
| Lift-and-shift | SEK 300,000–1,000,000 | Servers and systems moved as-is into cloud infrastructure |
| Replatform | SEK 800,000–2,500,000 | Selected parts swapped for managed services during the move, for example database and file handling |
| Refactor | SEK 2,000,000–5,000,000+ | Applications rebuilt into cloud-native architecture with containers or serverless |
Lift-and-shift is fastest and cheapest for the project but gives the least gain afterward – the environment is the same, just on rented infrastructure. Refactor costs the most now but delivers the lowest operating cost and the greatest flexibility later. Many wisely choose a mix: lift-and-shift for systems due to be retired within a few years, replatform for the workhorses, refactor for the systems at the core of the business.
The budget line that gets forgotten: double operating costs
During the transition period, you’re paying for two environments at once: the old one stays in place until everything is verified in the new one. For a migration spanning six months, running both in parallel can become a six-figure line item – and it’s conspicuously often missing from the first estimate.
Also account for related costs during the same period: data synchronization between environments, extra testing work, and staff keeping both environments in check. A rule of thumb is to plan for at least a quarter of parallel running, longer if critical systems move last.
Common traps that drive up cost
- Hard-coded dependencies. IP addresses, file paths, and latency assumptions baked into old code only surface once the system moves. Map dependencies before the move, not during.
- Licenses that don’t transfer. Some software is licensed per physical server or processor and can’t run in the cloud without a new license – a negotiation that can cost both time and money.
- Hidden integration points. Nightly file transfers, printers, scanners, and local special-purpose systems nobody documented but the business depends on.
- Knowledge stuck in people’s heads. The server that “only Bengt knows how to restart” is a risk to handle before the move, not after.
A scenario
A company with eight servers in a rented rack needs to exit the contract within a year. The mapping shows that five standard systems can move as-is, that the ERP database should become a managed service, and that an in-house customer portal is worth a real rebuild. The budget lands at around SEK 1.5 million for the project plus three months of parallel running – and the portal’s refactor is scheduled as a separate phase the following year, once the move is complete. That’s what a typical, risk-aware migration plan looks like: a strategy per system, not one strategy for everything.
After the move: optimize
The first invoice after migration is rarely the prettiest. Servers moved as-is are often oversized, and the payoff comes from optimizing afterward: right-sizing, autoscaling, and reserved capacity. Plan that phase in from the start – it’s what makes the move pay for itself.
Getting out of the server room or an expiring hosting contract? At Weapp we work with cloud architecture and migrations as part of our services – get in touch and we’ll help you choose a strategy per system.
Frequently asked questions
What's the difference between lift-and-shift, replatform, and refactor?
Lift-and-shift moves the servers as-is into the cloud. Replatform swaps out selected parts for managed cloud services along the way, for example the database. Refactor rebuilds the application into cloud-native architecture with containers or serverless. Cost, time, and long-term gain all increase in that same order.
How long does a cloud migration take?
A lift-and-shift of a handful of systems often takes two to four months including testing. Replatform of the same environment is more like four to eight months, and a refactor can stretch over a year or more. The initial mapping determines how accurate the timeline turns out to be.
Does operating in the cloud become cheaper after migration?
Not automatically. An environment moved straight across often costs about the same as before, sometimes more, since the servers are sized for old hardware. The savings come when the environment is adapted after the move: right-sizing, autoscaling, and managed services instead of your own servers.
Does the business have to stop during the move?
No, a well-planned migration moves systems in groups with test periods and a rollback plan, and the actual cutover per system often happens over a weekend or night. Critical systems can run in parallel in both environments until the new one is verified – that's what the parallel-running line in the budget is for.
Which systems shouldn't move to the cloud?
Systems with licenses tied to specific hardware, very old applications that require an operating system the cloud doesn't support, and systems with extreme latency requirements against local equipment. These are often handled as exceptions in an otherwise cloud-based strategy, or replaced rather than moved.