The pros and cons of moving your business to the cloud come down to a trade. You stop owning servers: a provider such as Microsoft Azure or Amazon Web Services (AWS) takes over the hardware and much of the routine upkeep. In return you take on a monthly bill that never ends and a set of security settings that are yours to get right, and your internet connection becomes something the business cannot work without. For most business systems still running on a server in the office the trade is a good one, but it is seldom as cheap or as effortless as the sales material suggests.
This article is about moving a system you already have: a business application and its database that today sit on a server in the office or in a rented rack in a data centre.
What moving to the cloud means for an existing system
“The cloud” covers three different moves, and the pros and cons are not the same for each.
- Replace it with a subscription product. The supplier runs everything and you log in through a browser. This is how most businesses already get email and office software.
- Rehost it. Your application and database move, largely unchanged, onto virtual servers rented from a cloud provider. A virtual server behaves like the machine you have now, except that the provider owns the hardware underneath.
- Re-platform it. The application moves onto managed services, where the provider also looks after the operating system and the database software, and you look after the application and its data.
Most bespoke business systems are rehosted first, because that needs the fewest changes.
The pros
No hardware to buy, house or replace. An office server needs replacing every few years, and in the meantime it needs a cool room, a battery backup and someone to notice when a disk fails. In the cloud those are the provider’s problems.
Backups that do not depend on a person. Backups can be scheduled, kept for as long as you choose and copied to a second location automatically. You still have to test that a restore works, but that becomes a routine task you can run on a spare copy without touching the live system.
Resilience a single office cannot match. Azure and AWS each have a London region split into three separate zones with their own power and network connections. A system can be spread across zones so that the loss of one building does not stop it, and a power cut or a break-in at your office no longer takes the system down.
Access that does not route through the office. Staff at home or in a second branch reach the system directly, without the office broadband line being the weak link for everyone.
Capacity that can change. A server that turns out to be too small can be resized in minutes, and one that is too large can be reduced. With owned hardware you guess the size once and live with it for years.
Staying in support gets easier. When the operating system or database version reaches the end of its support, the upgrade is a new virtual server built alongside the old one, not a hardware purchase. On managed services the provider applies much of the patching for you. With Windows Server 2016 reaching the end of its support on 12 January 2027, this is the benefit many businesses are weighing at the moment.
The cons
The bill never stops, and it is easy to inflate. You pay every month for as long as the system runs. Servers specified generously “to be safe” and test machines nobody switched off both add to it. Our article on reducing cloud hosting costs covers the usual causes.
It is not always cheaper. A steady workload on hardware you have already paid for can cost less to leave where it is. Windows Server and SQL Server licences are a large part of the cost on either side, and the rules for using licences you already own differ between providers. A fair comparison covers five years and includes the costs of the office server that never appear on an invoice, such as the time spent looking after it.
You depend on your internet connection. If the office line fails, the people in the office cannot work, even though the system itself is running. A second line from a different supplier, or a mobile data fallback, becomes part of the design.
Security is shared, not handed over. The provider secures its data centres and the hardware in them. Everything you set up on top stays yours to secure: who has an account, how the servers are configured and how the data is protected. A cloud management console can be reached from anywhere, so a stolen administrator password is a more serious matter than it was when the server sat behind the office firewall. We explain the split in software development in the cloud and its security obstacles.
Leaving takes work. The more of a provider’s own services you build on, the more there is to redo if you move again. Providers also charge for data sent out of their network, although AWS and Azure both say they will waive that charge, on request and subject to conditions, for a customer who is leaving altogether.
Some systems do not suit it. Software that controls equipment on site needs to stay next to it. A desktop application that talks constantly to a database on the local network will feel slow if the database moves to a data centre and the application stays on office PCs. It usually has to be run through remote desktop or rebuilt as a web application. Old software may have licence terms, or a hardware key plugged into the server, that rule out a move.
Data protection needs checking. Moving personal data to a cloud provider does not move your legal responsibility for it. Check which country the data will be stored in and what the provider’s terms say, and take advice if the system holds sensitive records.
Which systems tend to gain most
In our experience the balance depends more on the type of system than on the size of the business.
A web application with a SQL Server database usually moves well. Users already reach it through a browser, so nothing changes for them except the address.
A system with sharp peaks, such as a month-end run or a seasonal rush, benefits from capacity that can be raised for a few days and lowered again. One with flat, predictable demand gains little from that flexibility, and its case for moving rests on resilience, backups and support dates.
What usually forces the decision
Few businesses move a working system for its own sake. The prompt is normally a date or a failure: the server is out of warranty, the hosting company is retiring its platform, or the operating system or database no longer receives security fixes. Security fixes for SQL Server 2016 ended on 14 July 2026, and the paid extension for Windows Server 2012 and 2012 R2 runs out on 13 October 2026.
At that point the choice is between buying new hardware and moving. Self-hosted or cloud hosted sets out how to make that decision, and how the cloud can improve your business describes what changes day to day once a system has moved.
What to check before you commit
- List everything the system depends on: scheduled jobs, file shares, printers, scanners, links to other systems and anything plugged into the server.
- Measure how busy the current server really is over a normal month. That figure, not the size of the old machine, should set the size of the new one.
- Find out how each group of users connects, and whether any of them run a desktop program that expects the database to be nearby.
- Ask your licensing supplier which of your existing Microsoft licences can be used with each provider.
- Ask whoever proposes the move for a forecast of the monthly bill, a rehearsal of the switch-over using a copy of your real data, and a way back if it goes wrong. Our cloud migration service page describes how we approach those three things.