What should actually be in the cloud? A practical guide for UK business leaders

Not everything belongs in the cloud. A practical guide to deciding which workloads to migrate, which to keep on-premises, and how to make the call.

If your IT provider tells you to move everything to the cloud, they are either oversimplifying or selling something.

Cloud computing has matured into a genuine business tool. But 'cloud first' as a blanket policy still leads organisations into migrations they later regret, costs that outrun their on-premises alternative, and architectures held together by complexity no one fully understands.

This guide is for IT directors, CFOs, and business leaders who want to make deliberate decisions about what to move, what to keep, and what to think carefully about before committing.


Are you asking the right question?

Most organisations frame this as: 'Should we move to the cloud?'. The better question is which workloads benefit from being there and which do not.

Cloud infrastructure suits certain types of work well. It is a poor fit for others. For most UK businesses of any meaningful size, the outcome is a hybrid model: some workloads in public cloud, some on-premises, and some in co-located or private cloud environments. Whether that hybrid is deliberate or accidental is what separates well-run IT from expensive complexity.


Which workloads move well?

Collaboration and productivity tools. Microsoft 365, including Teams, SharePoint, and Exchange Online, was designed for the cloud. For the overwhelming majority of UK businesses, running Exchange on-premises or hosting SharePoint locally adds cost and complexity with no meaningful benefit. This is one of the cleanest migrations available.

Applications with unpredictable or seasonal demand. If your system needs to handle ten times normal load for two weeks in December, paying for on-premises hardware that sits idle for eleven months is poor economics. Cloud gives you the ability to scale up when you need it and back down when you do not.

Development and test environments. Spinning up an environment for a project and decommissioning it when the work is done is a near-perfect cloud use case. You pay for what you use, and you are not maintaining hardware that exists purely for intermittent work.

Disaster recovery and backup. Using cloud storage as a secondary copy of your data, or as the foundation of a recovery plan, removes the need for a secondary physical site. Modern backup-as-a-service platforms make recovery testing straightforward and affordable. This is a core component of how we structure business resilience programmes.

Customer-facing web applications. If traffic to your website or customer portal fluctuates, cloud hosting with auto-scaling gives you resilience and performance without over-provisioning for peaks you only see occasionally.


Which workloads need more thought?

Legacy applications with complex dependencies. Many businesses run applications built ten or fifteen years ago that were never designed for cloud architecture. They may depend on specific operating system versions, tightly coupled databases, or local network calls that do not translate cleanly. You can lift and shift these workloads, but you often inherit the same problems at higher cost. A proper migration requires either re-platforming the application, or accepting that it stays on-premises until a replacement is ready.

High-throughput, latency-sensitive workloads. Applications that process large volumes of data and need very low response times can perform worse in the cloud than on well-specified on-premises hardware, depending on your connectivity and the distance between your users and the cloud data centre. This is less of a constraint than it was five years ago, but it still applies to specific use cases.

The three-year cost question. Cloud is almost always more cost-efficient than on-premises for variable workloads. It is not always cheaper for stable, predictable ones. If a workload runs at consistent capacity, the economics deserve honest modelling over a three-to-five year horizon, including licences, compute, storage, and egress charges. Our guide to Microsoft cloud cost optimisation covers this in detail.


What does UK compliance mean for your cloud decisions?

UK GDPR imposes obligations on where personal data is processed and stored. For most workloads hosted in Azure’s UK regions or AWS’s London availability zone, this is manageable – but it requires deliberate configuration rather than accepting default settings.

Certain sectors carry additional obligations. FCA-regulated firms need to ensure that outsourcing arrangements, including cloud services, meet the FCA’s operational resilience requirements. This does not preclude cloud, but it does mean your architecture needs to be documented, your exit provisions considered, and your concentration risk assessed. Professional services firms and anyone handling client data under sector-specific agreements face similar considerations.

The answer is almost always 'cloud is viable, with the right configuration' rather than 'you cannot use cloud'. But that configuration work needs to happen before migration, not after.


Why do most UK businesses end up with a hybrid environment?

Walk through the infrastructure of most UK businesses with 100 to 2,000 employees and you will find a mix: some workloads in Microsoft Azure or AWS, a file server or two still on-premises, email on Microsoft 365, and a line-of-business application that nobody wants to touch because it last caused an outage and everyone remembers it.

That is not a failing. Hybrid is the right answer for most organisations at this size. The question is whether yours is designed or accidental. A well-designed hybrid architecture has clear policies about what lives where and why, consistent security controls across both environments, and a managed services layer that can support users regardless of which infrastructure their tools run on. A poorly designed one creates monitoring blind spots, inconsistent patching, and support complexity that falls on your internal team.


What should you ask before migrating any workload?

What does it cost to run today, and what will it cost in the cloud over three years?
Include licences, compute, storage, egress charges, and management overhead on both sides. Cloud bills climb when nobody is actively watching them.

Are there data residency, regulatory, or contractual obligations that affect where this data can sit?
If yes, make sure your provider and configuration address them before you migrate.

Can this workload genuinely benefit from cloud flexibility, geographic distribution, or managed services that would be expensive to replicate on-premises?
If yes, cloud is likely the right home. If the workload is stable and predictable, run the numbers first.

What are the dependencies?
Does this application call other systems? Do those systems also need to move, or will you create a latency problem by putting them on opposite sides of a network boundary?

The answers will not always point in the same direction. That is the point.

Where do you start?

The businesses that get cloud right are rarely the ones who moved fastest. They are the ones who mapped their workloads carefully first, identified the handful of applications that genuinely benefit from cloud flexibility, and built a plan around that subset. Treating 'the cloud' as a destination in its own right is where migrations go wrong.

A cloud readiness assessment gives you a structured view: which workloads are good candidates, which should stay on-premises, which need further work before they move, and what the migration will cost at each stage. It is the starting point we use for every cloud & infrastructure engagement.

Visit our Improve efficiency hub to see how cloud decisions fit within a broader programme, or call us on 0300 140 0000 to arrange an initial conversation.