Cloud platforms are convenient, well engineered and appropriate for a great many organisations. This page is not an argument that they are bad. It is an argument that for an institution answerable to a regulator, a board, or a customer who asked where their data is held, convenience is not the deciding variable — control is.
Everything IPTREK deploys runs inside your perimeter, on infrastructure you own or control. Below is the comparison, criterion by criterion, of what that changes.
The comparison
| Criterion | On-premises, on your infrastructure | Public cloud / SaaS |
|---|---|---|
| Security | You control the firewall, the encryption keys, the access policy and the audit trail. The security boundary is one you designed. | Shared infrastructure behind a security boundary the provider defines and can change. |
| Privacy | Customer, transaction and infrastructure data never crosses your network perimeter. | Data is stored and processed on third-party systems, under their terms and their jurisdiction. |
| Autonomy | Full customisation, your upgrade schedule, and no licence that can be withdrawn or repriced. | Provider-driven roadmap, forced upgrade windows, and pricing you do not control. |
| Integrity | You define retention, backup and recovery — and you test them yourself. | You inherit the provider’s backup policy and their definition of acceptable data loss. |
| Continuity | The system runs on your intranet. Loss of internet connectivity does not stop your service desk. | An outage, an account dispute or a change of terms at the provider becomes your outage. |
| Jurisdiction | Data remains under the legal jurisdiction you chose, which is usually the one you operate in. | Data may be subject to foreign legal process regardless of where your organisation sits. |
| Cost profile | Capital cost plus a support agreement. Adding staff does not change what you pay for software. | Per-user subscription that grows with headcount, indefinitely. |
| Client trust | You can tell your customers, truthfully, that their data never left your building. | Your assurance to your customers depends on somebody else’s assurance to you. |
What this means in practice
You can answer the jurisdiction question
For institutions operating under data-residency expectations, the question of which legal system can compel disclosure of your data is not academic. When the systems run in your building, on your hardware, the answer is short and it is the same answer every time.
Your service desk survives your internet connection
An intranet-deployed service desk, monitoring platform and asset register keep working during an external connectivity failure. Given that connectivity failure is precisely the sort of incident you would want to raise a ticket about, this is less of an edge case than it sounds.
There is no licence to be withdrawn
The platforms we deploy are open source. That is not primarily a cost argument — though the cost argument is real once you count per-seat subscriptions across a large institution. It is a continuity argument. Nobody can end-of-life your service desk, change its pricing model, or make a feature you depend on part of a higher tier.
You own the evidence
When an auditor asks how a change was approved, who had access to a system, or whether a backup was restorable, the entire chain of evidence is inside systems you control. You are not requesting records from a supplier and hoping their retention policy matched your obligation.
The honest counter-arguments
It would be poor advice to present this as a decision without trade-offs. Three are worth stating plainly.
- You carry the operational burden. Patching, capacity and availability become your responsibility. This is exactly what a support agreement is for, but it is a real cost and we will not pretend otherwise.
- Elastic scale is harder. If your workload genuinely spikes by an order of magnitude on unpredictable schedules, on-premises capacity planning is less comfortable than elastic provisioning.
- Capital versus operating expenditure. On-premises shifts spend towards capital. For some finance functions that is preferable, for others it is a hurdle. It is worth checking which you are before the business case is written.
For most of the institutions we work with — banks, insurers, public bodies and healthcare providers with steady, predictable workloads and strict obligations — these trade-offs land clearly on the on-premises side. If yours does not, we would rather say so at scoping than six months in.
Hybrid, where it genuinely fits
Some organisations want core systems on-premises and non-sensitive workloads elsewhere — a test environment, a public-facing status page, a documentation site. That is a reasonable position and we will design for it. The line we help you draw is which data classes must never leave, and we then build so that boundary is enforced by architecture rather than by policy alone.