"Let's move to the cloud" is not a single decision
It usually starts with a specific event: the server reaches the end of its warranty, the ERP vendor offers the online version, the owner receives a quote for new hardware and asks why they should buy any more. That is when the talk turns to "let's move to the cloud", as if it were a single choice.
In fact, there are many choices, one for each system. The ERP, email, file server and production software have different needs. A company that ends up with an environment partly in the cloud and partly on premises (hybrid) has not failed its migration: it has often made the right choice.
Six strategies, chosen system by system
These names turn up in every technical proposal, so they are worth knowing.
| Strategy | When it makes sense | Watch out for |
|---|---|---|
| Rehost ("lift and shift"): you move the machine as it is | End-of-life servers, tight deadlines | You take your inefficiencies to the cloud too, and you pay for an oversized machine every month |
| Replatform: minor adjustments, such as a managed database | Components the cloud provider can manage without the application being rewritten | Version compatibility, to be confirmed with the software vendor |
| Refactor: you rewrite the application for the cloud | Software developed in-house, central to the business | The time and cost of a genuine development project |
| Replace: you switch to subscription software (SaaS) | Email, CRM, ERP systems the vendor already offers online | Historical data, lost customisations, staff training |
| Retain: it stays where it is, for now | Software tied to machinery, recent investments | "For now" must not turn into "for ever" through inertia |
| Retire: it is switched off | Applications nobody uses any more, duplicates | First preserve any data you must keep by law or under contract |
The costs that quotes leave out
The cloud turns an investment (capex: you buy the server and depreciate it) into an operating expense (opex: you pay each month for what you use), and it will not necessarily cost less. The items most often missing from the comparison:
- Outbound traffic. Uploading data to the cloud is often free; getting it out again, to your own premises or to another provider, is charged by volume.
- Machines running day and night. On premises, a server left on overnight was already paid for; in the cloud every hour shows up on the bill.
- Software licences. Some vendors apply different rules when the software runs on third-party infrastructure: the licence for your on-premises server does not always transfer.
- Backup and disaster recovery. The provider guarantees its infrastructure, not your data: copies and restore tests are still up to you. The same applies to email: we explain why in the guide on Microsoft 365 backup.
- Connectivity. With the ERP in the cloud, if the line goes down the whole office stops working: you need a second connection from a different carrier as a backup.
- People's time. Inventory, testing, training: real work, even if it does not appear in the quote.
How to plan a cloud migration without bringing the business to a halt
- Inventory and dependencies: not just the list of servers, but what talks to what. The ERP queries the licence server and sends labels to the warehouse printer. A dependency discovered on migration day means an outage.
- A strategy for each system, chosen partly on the basis of the RTO and RPO that system has to meet.
- A pilot project on a less critical system, to test the method on something that can afford a mistake.
- Migration in waves, from the least critical systems to the most important, checking the backups before each wave.
- A rollback plan agreed in advance: at what time and after which check you roll back, with no debate.
- The cutover window, the moment of the switchover, kept well away from month-end closes and stocktakes.
- Checking and switching off the old environment, only after people have actually worked in the new one.
A migration has a clear scope from the outset and lends itself to predictive planning; the reasons these projects go off the rails are covered in the guide on why IT projects fail. In the story The migration nobody noticed the move was between two on-premises infrastructures, but the method is the same.
Where the data lives, and how to bring it home
The cloud is always someone's data centre, in a specific place: ask where the data and the copies will be stored. If personal data is involved, the provider processes it on your behalf: you need the contract required by Article 28 of the GDPR, and any transfer outside the European Economic Area must comply with Chapter V of the Regulation.
Then there is the exit. The risk of being tied to one provider (lock-in) grows with every proprietary service. Before you start, find out in what format you can export the data, how long it takes and what it costs. The European Data Act (Regulation (EU) 2023/2854) contains rules to make it easier to switch cloud provider, but the exit plan is still your responsibility.
The most common mistakes
- Moving everything in one go, including the systems that should be switched off.
- Comparing the monthly fee with the price of the server alone, rather than with the total on-premises cost.
- Nobody looks at the bill afterwards. In the cloud the cost changes every month: someone has to switch off unused resources, resize machines and set spending alerts, with a dedicated line in the IT budget.
In short
Migrating to the cloud means deciding system by system whether to move, adapt, replace, keep or switch off. Moving from capital investment to a monthly fee does not guarantee savings: traffic, licences, backup and connectivity all have to be factored in. The migration proceeds in waves, with a rollback plan agreed in advance, and costs are checked every month.