On-prem did not stop being real. It stopped getting attention.
The estate works, the person who built it has moved on, and the renewal notice has just arrived with a different number on it.
A virtualisation renewal that has changed shape, and a decision needed on a timeline nobody chose.
Forced decisionServers past their support window, firmware nobody wants to touch, and a spares story that is really a hope.
Past supportProvisioning by runbook and memory, no infrastructure code, and a rebuild that would take days nobody has rehearsed.
Not reproducibleJobs reporting success, a restore path nobody has walked, and no evidence for the auditor who is about to ask.
UnverifiedWe run on-prem. Deciding whether it should move is a separate job.
Where this sits relative to the work either side of it, so you can tell what you are and are not buying.
Hybrid
When part of the estate is cloud and the seam between them is the interesting part.
Go to the pageOn-prem, operated
Day-to-day operation of your own hardware: virtualisation, storage, network, patching, backup and on-call — automated rather than hand-tended.
App Modernisation
When the applications have to change before any of this gets simpler.
Go to the pagePlenty of clients buy one layer and run the rest themselves. That is a normal outcome, not a half-sale.
What running on-prem actually involves
Virtualisation and the licensing question
VMware, Proxmox, Hyper-V or KVM — operated, and assessed honestly when a renewal forces the question. Migration between them is real work with real risk, and we will cost it rather than wave at it.
Infrastructure as code, on metal
Terraform providers against your own platform, Ansible for configuration, PXE or image-based provisioning — so a host is rebuilt from a repository rather than from somebody's memory.
Storage and network
SAN, NAS or Ceph operated with capacity headroom you can see coming, switching and firewall configuration in version control, and a documented answer for a single-device failure.
Backup and disaster recovery
Veeam or equivalent with immutable copies, an offsite or cloud tier, and a restore rehearsed on a schedule — because a backup nobody has restored from is a belief, not a control.
Patching and lifecycle
Operating systems, hypervisors and firmware on a schedule with maintenance windows that hold, plus a hardware refresh plan that arrives before the support window closes rather than after.
Observability and on-call
Prometheus, Grafana and Loki against physical and virtual estate alike, alerts tied to runbooks, and a rota during UK and EU hours with someone who has seen this hardware before.
Investigate, implement, hand over
What is genuinely running: accounts, workloads, identity, network, backups, cost, and how a change reaches production today. You get a written picture of the current state and a scope in priority order — what is dangerous, what is expensive, and what can wait.
The priority items, in sequence, as code in your repositories. Rehearsed in the lower environments first, with the rollback run rather than described. Nothing goes in that your own engineers cannot read.
Runbooks, architecture decisions and the reasoning behind them, written down. A working session per area with your team. We stay on-call afterwards only if you want us to.
Nobody else is managing this layer. That is the point.
This is the honest version of a comparison most pages skip. The provider takes real work off you — and it takes one layer, not the stack.
Your vendors
Hardware warranty, firmware, and support contracts on the kit itself. Real, and narrow — a replacement part is not an operating model.
What is left
Everything else, which is most of it: hypervisor currency, provisioning, network and storage configuration, capacity planning, patching, backup and rehearsed restore, monitoring, and the on-call rota. This is the layer where an MSP either adds automation or just adds a ticket queue.
What you are actually choosing between
| Option | Left as code | Runs day to day | Actively cuts cost | Security you can evidence | No key-person risk | Best fit when… |
|---|---|---|---|---|---|---|
| Hire in-house | the work is genuinely continuous — then hiring is the right call. | |||||
| Generalist MSP | you only need the lights kept on. | |||||
| Leave it alone | nothing has broken, been audited, or been queried yet. | |||||
| OpsHero | the work comes in bursts and has to outlast us. |
On-prem is not right for everybody
If nothing in your estate needs to be in your own racks — no latency constraint, no licensing lock, no data-residency requirement, no physical device to talk to — then maintaining hardware is usually the expensive way to run software. We would rather tell you that than sell you a refresh cycle. We would rather say that on a page than halfway through an engagement.
None of it is true yet. Worth a conversation.
Your answers stay in your browser.
The ones people actually ask
Our virtualisation renewal has changed. What are the options?
Renew, migrate hypervisor, or move the workload. All three are legitimate and the right answer depends on your applications, licensing and appetite for a project. We will cost all three rather than steer you to the one that suits us — the migration case in particular is real work with real risk and should not be undersold.
Do you provide the hardware?
No. You own the hardware and the vendor relationships; we operate what is on it. Where a refresh is needed we will specify it and work with your supplier.
Do you come on site?
Most of the work is remote. Physical hands, whether yours or a facility provider's, are arranged with you — and we will say plainly which parts we do not cover rather than implying full coverage.
Is this just system administration?
It is system administration done with cloud-era practice: infrastructure as code, version control, monitoring as a first-class concern and rehearsed recovery. The difference shows up when something has to be rebuilt.
Will we be locked in?
Your hardware, your repositories, your documentation. Everything we automate is readable by your own engineers, and another team could pick it up.
Talk to an infrastructure engineer
Not a salesperson. You will get a read on your estate, the specific risks in it, and what the work would involve.
- A written picture of what is actually running, and what state it is in
- The risks in priority order — dangerous, expensive, and can wait
- What the work would involve, and in what sequence
- Everything delivered into your own repositories and cloud accounts