Cloud versus on-premise is not a contest between modern and old technology. It is a decision about who operates each layer, which constraints the workload must tolerate and what evidence the organisation needs when service, cost or supplier conditions change.
A useful comparison starts with the work: required availability, response time, data handling, integration, rate of change and recovery. It then maps responsibility and exit. The result may favour a cloud service, a managed private environment, self-operated infrastructure or a deliberate combination.
Define the workload before comparing deployment models
Write a one-page workload profile before discussing products. Describe who uses the system, the busiest periods, the consequences of delay, where source data originates, which systems must exchange data and how long the organisation can operate without it. Include regulatory or contractual boundaries as facts to verify, not as vague claims that data "must stay inside" a particular room or country.
NIST's definition of cloud computing distinguishes service and deployment models through characteristics such as on-demand access, resource pooling and measured service. Those characteristics create operating trade-offs. They do not by themselves decide whether a specific workload is suitable.
Compare six workload facts
| Decision fact | Questions that change the answer |
|---|---|
| Availability | Which business activity stops? What recovery time and recovery point are acceptable? Can a manual fallback work? |
| Connectivity and latency | Which locations have unstable links? Does the workflow require local device or machine response? What happens offline? |
| Data | Who controls access, encryption keys, retention, deletion, backup and restoration? Where can data and support access occur? |
| Change | How often must features, integrations and security fixes change? Can the business absorb supplier-controlled release timing? |
| Integration | Are dependencies API-based, file-based, database-level or tied to local hardware? Who diagnoses an end-to-end failure? |
| Operating capability | Which team can monitor, patch, restore, test and support the chosen stack at the required hours? |
Map responsibility instead of assuming it transfers
Cloud services transfer some operating work to a supplier, but not accountability for business outcomes, user access, data quality, configuration or supplier oversight. The UK NCSC's shared-responsibility guidance stresses that the split changes by service model and must be understood explicitly.
For each layer in the diagram, record four things: the responsible party, the control they perform, the evidence the buyer receives and the action when evidence is missing. "Supplier" is not a complete answer. Name the service or contract obligation and the internal owner who reviews it.
Use a workload decision matrix, not a generic pros-and-cons list
| Observed condition | Cloud service may be stronger when… | Self-operated or private may be stronger when… |
|---|---|---|
| Demand changes quickly | capacity must expand without procurement and installation cycles | demand is stable and owned capacity is already efficient |
| Release frequency is high | continuous supplier delivery fits governance and training | the organisation must control a tightly bounded change window |
| Local dependency is critical | reliable links and supported edge/offline behavior exist | operation must continue despite external connectivity loss |
| Specialist operations are scarce | the supplier demonstrably owns patching, resilience and platform support | the organisation already has capable teams and tooling |
| Deep customisation is required | configuration and supported extension points cover the need | the workload genuinely requires infrastructure or application control unavailable in the service |
This matrix does not award points. It identifies evidence to collect. A cloud product that claims offline work must demonstrate the relevant failure and recovery path. An on-premise option that claims control must show the people, process and cost needed to exercise it.
Model cost on the same operating boundary
Do not compare a cloud subscription with only an on-premise licence. Use the same horizon and include implementation, environments, integration, identity, monitoring, backup, recovery tests, upgrades, support, infrastructure refresh, specialist labour, usage growth and exit. Separate committed cost from uncertain consumption.
Cost also has timing and capacity risk. A self-operated environment can require early capital and spare capacity; a measured service can make growth easier but expose the buyer to usage and pricing changes. Run at least a baseline, growth and stress scenario. Document the volume assumptions that make each result true.
Test resilience as a chain
An availability percentage does not prove that the business process recovers. Trace a failure through identity, network, application, integration, data and user communication. Ask who detects the event, which recovery target applies, how backup restoration is tested and what the business does while recovery is underway.
For cloud, test loss of the service, an identity dependency and a supplier-region or connectivity problem. For on-premise, test facility, hardware, staffing and backup failure. For both, verify that restored data reconciles with upstream and downstream systems. The weakest dependency defines practical resilience.
Make exit a design input
Record export formats, API limits, metadata, attachments, audit history, encryption-key handling, deletion evidence, transition assistance and the time needed to obtain a complete dataset. A file named "export" is not proof of portability. Load a representative sample into a neutral tool and reconcile record counts, relationships and dates.
Also identify replacements for supplier-owned functions such as identity, workflow, reporting or integration. Exit cost often sits in those dependencies rather than in the raw data. The GOV.UK Service Manual's technology-choice guidance recommends avoiding unnecessary dependence and keeping decisions reviewable as needs change.
Run a decision workshop with explicit outcomes
Bring together the process owner, users, technology operations, security, data, finance and procurement. Review the workload profile, responsibility map, evidence gaps, cost scenarios and exit test. Finish with one of four outcomes: choose the operating model; run a bounded proof; obtain missing evidence; or retain a hybrid boundary for named workloads.
The final record should state why the model fits this workload, which responsibilities remain internal, which assumptions would change the answer and when the decision will be reviewed. That is more durable than declaring a permanent winner between cloud and on-premise software.
Make a hybrid boundary deliberate
Hybrid is useful when different workloads have genuinely different constraints, not when unresolved decisions accumulate. Name the system of record, direction of each data flow, identity dependency, failure owner and reconciliation process. Test what happens when either side is unavailable and how queued changes are recovered.
Set an expiry or review trigger for temporary bridges. Otherwise a migration interface can become a permanent critical service without an owner, service target or exit plan. A clear mixed model is a valid architecture; an undocumented collection of exceptions is not.