Cloud or on-premise: picking a deployment model you won't fight
The same product can arrive as a cloud subscription, a private installation in your data centre, or a hybrid of both. The choice is rarely about technology preference - it is about who operates the system, where the data must live, and how you want the cost to appear in the budget.
A SaaS subscription buys speed. Provisioning takes hours, updates and backups are the vendor's problem, and the cost is operating expenditure that scales with headcount. The trade-offs are real: you accept the vendor's release schedule, their uptime guarantees, and the fact that your data sits in their infrastructure under their availability zone.
An on-premise licence buys control. The database is inside your perimeter, you decide when to upgrade, you can meet data residency and industry compliance requirements that a public cloud cannot satisfy. In exchange you own the servers, the patching, the monitoring and the administrator's salary - a capital expenditure with a longer payback and a real operational burden.
Four questions that decide it
- 01Regulation. Do personal, financial or medical records have to stay in a specific jurisdiction or on your own hardware?
- 02Operations. Do you have an administrator who can own updates, backups and access rights - this year and in three years?
- 03Connectivity. Do production sites keep working when the internet does not? Warehouses and workshops often answer no.
- 04Budget shape. Is a predictable monthly subscription easier to approve than a one-off licence and hardware purchase?
Hybrid deployment is often the honest answer: the core database on your servers, analytics and mobile access in the cloud, synchronised through an API. It costs more to set up and less to regret. Whatever you choose, check the migration path in the contract - a model you cannot leave is a decision you only get to make once.
Our catalog labels every product by deployment model, so you can filter before you fall in love with something you cannot host. And when a vendor offers both, we quote both - with the three-year cost of each, including the administration you would take on.
What the answer really depends on
Deployment is an operational decision disguised as a technical one. Five things decide it: where regulation says the data may live, how long the business can work without connectivity, how far the users are from the servers, how deeply the product must reach into systems you already run on-premise, and whether you have anyone to patch a server at eleven at night.
Offline tolerance is the sharpest test. A warehouse, a production line or a checkout that stops when the link drops is not a cloud candidate for its operational core, whatever the licence costs. An office team that already works in browser tools all day is the opposite case.
The costs each model hides
- 01Cloud. Seat growth, storage tiers, per-integration fees, data egress on exit, and the price of the plan that contains the one feature you need.
- 02On-premise. Hardware refresh every four to five years, a high-availability pair rather than one box, a disaster-recovery site, patch windows, and the administrator's salary.
- 03Both. Identity management, backup verification and monitoring do not come free in either model - they are just billed differently.
Write the numbers over five years with the refresh cycle included. Cloud usually wins on the first year and on flexibility; on-premise often wins on the fifth year and always wins on control. Capital versus operating expenditure is a finance preference, not an architecture argument, and it is worth asking finance which one they actually want.
Hybrid without creating a mess
Hybrid works when the boundary is deliberate: operational data and latency-sensitive workloads stay local, analytics and collaboration go to the cloud, one identity provider covers both, and one backup policy is written down with a recovery time and recovery point objective per component. Hybrid fails when it is simply the result of two projects that never spoke to each other.
Test the restore, not the backup. Whichever model you pick, the only proof that the deployment is safe is a restore you have actually performed, with the date written on it.