Managed Cloud or On-Premise? Where Your Operational System Should Run
When a training provider, a fleet operator, or an HR team decides to replace manual processes with a system, the operational questions come first: does it fit our workflow, can it handle our volume. Then IT or the compliance officer joins the meeting and asks the question that decides whether the project proceeds at all: where does this run, and who can reach the data?
We offer both answers. Our systems run on managed cloud hosting by default, and can be installed on your own infrastructure when company or regulatory policy requires it. The honest version of this article is that neither option is free of trade-offs, so here is how to pick.
Managed cloud: you buy an outcome
With managed hosting, we run the servers, apply updates, and respond when something fails. Your team logs in and works. This is the right default for most organisations, because the alternative is asking your own IT staff to learn and maintain one more system they did not build.
What you give up is physical control. Your data lives on infrastructure we operate. For most commercial organisations that is acceptable once access control, backup practice, and the legal relationship are written down. We publish how we handle these on our Security & Trust page, so your IT team can review before a call, not after.
On-premise: you keep control, and the responsibility
Some organisations cannot place operational data outside their own network: public sector bodies with data residency obligations, hospitals with patient-adjacent records, or groups whose internal audit policy simply says so. For them, we install the system on servers they control, inside their network, under their access policy.
The commitment that comes with it is operational. Someone on your side owns the server: patching the operating system, monitoring disk and memory, running the backup schedule we configure together, and giving us a path to deploy updates. If nobody owns that, on-premise does not make the data safer. It makes it less maintained.
Three questions that settle it
First: is there a written policy, law, or client contract that forbids data leaving your infrastructure? If yes, on-premise, and the conversation is about how, not whether. If the answer is "we would prefer not to," keep reading.
Second: do you have a person, not a department, who will own the server next year? Ownership that is shared is ownership that lapses. If you cannot name the person, managed cloud.
Third: how fast do you need fixes? On managed hosting, we deploy a fix the moment it is ready. On-premise, every update goes through your change window and your staff. That is a feature for some organisations and a cost for others. Decide which you are before the first invoice, not after the first incident.
Either way, the system is the same
The decision changes where the software runs, not what it does. Role-based access control and the workflows your team was trained on are identical in both deployments. Which is why we recommend settling the hosting question early and separately, so it never holds the operational rollout hostage.
