"Managed applications" sounds like a marketing category, but it's a real economic decision: who runs the operational layer of an internal tool — your team or a specialist provider. Most companies eventually face this choice for at least one application (CRM, ERP, ITSM, monitoring, identity). This article is the honest assessment of when the managed model works, when it doesn't, and what specialists actually deliver. Managed GLPI is used as the worked example.
What "managed" actually covers
The term gets used loosely. A useful split:
- Hosted — the provider runs the infrastructure (VM, OS, database). You manage the application layer.
- Managed — the provider runs infrastructure and the application: configuration, upgrades, plugin maintenance, backups, monitoring. You just use the UI.
- Fully outsourced — the provider also handles end-user support, training, change requests. Your team essentially has a vendor relationship, not an operational one.
The benefits scale with how much is delegated; so do the costs and the risks of vendor lock-in.
Where managed actually pays
Honest list, not marketing list:
- Cost predictability over staffing volatility — a managed contract is a fixed monthly fee. An in-house ops engineer is salary + benefits + training + the risk they leave next quarter. For small teams the swap is often cheaper, especially when you account for hiring difficulty.
- Operational coverage at scale you can't justify — 24/7 monitoring needs at least 4 – 5 people. That's only economical if your operation is large. Managed providers amortise that across multiple clients.
- Specialist depth — a provider with 50 GLPI deployments has seen edge cases yours hasn't. When something rare breaks (specific plugin + specific MariaDB version + specific PHP), they've already solved it.
- Security and patching cadence — keeping a tool current with security updates is consistent work that gets deprioritised in busy in-house teams. Providers can't deprioritise it; it's their product.
- Backup discipline — providers test backups regularly because their contract requires it. In-house teams often realise their backups don't work only when they need them.
Where managed breaks down
The places where "managed" stops being the right answer:
- Highly customised configurations — if your application setup needs constant adjustment (custom workflows that change weekly), the contract negotiation around "what's a change request vs. business as usual" becomes painful.
- Tight integration with internal systems — if the application talks to systems the provider can't reach (your internal LDAP, custom databases, on-prem ERPs), the integration layer stays your responsibility anyway.
- Data sensitivity — for some regulated workloads, having a third party handle the data is a compliance complication. Sometimes the answer is on-prem managed (provider operates infrastructure on your hardware), but the cost premium is real.
- Small teams that already have skill — if you have one strong sysadmin who already knows the application well, paying a provider to do work they could do is wasteful. The managed value comes from not having the skill, not from delegating skill you already have.
What specialists actually do
The marketing version says "monitor, optimise, secure". The operational version is more concrete:
- Daily: watch monitoring dashboards, respond to alerts, investigate anomalies, log into the application to verify after notifications.
- Weekly: review patch backlogs, plan upcoming maintenance windows, test backup restores from random samples.
- Monthly: roll out application minor versions to staging, validate, schedule production rollout.
- Quarterly: capacity reviews, security audits, plugin compatibility checks ahead of major version upgrades.
- On-demand: change requests, troubleshooting, emerging integrations.
The cadence is the value. Most in-house teams do these tasks ad hoc; managed providers do them on schedule.
Managed GLPI as the worked example
Managed GLPI covers: hosted infrastructure (VM + MariaDB + reverse proxy), application configuration and upgrades, plugin lifecycle management, backup with quarterly tested restores, monitoring with on-call response, and a defined SLA on response time. The customer keeps full data ownership (the database can be exported anytime) and can take the deployment back in-house with a documented handover. For deployment-tuning details specifically see the Linux server tuning guide.
The decision framework
Before signing a managed contract:
- List the operational tasks the application requires monthly (patching, backups, plugin updates, monitoring, support tickets, capacity adjustments).
- Estimate hours per task. Total monthly hours.
- Multiply by your loaded labour cost. That's your in-house cost.
- Compare to the managed quote. If managed is within 30% of in-house, the case is mostly about consistency and risk, not raw cost.
- If managed is 50%+ cheaper, you're either understaffed today (hidden cost) or the provider is bidding aggressively to land you (long-term price will rise).
Managed applications aren't a universally better choice — they're a trade between control and operational consistency. For applications that aren't your competitive differentiator, that trade usually favours managed; for the ones that are, it usually doesn't.