The £4.2B Break-Up That Never Happened: What HMRC and Capgemini Teach IT Teams About Monitoring Lock-In

Another Week, Another Monumental IT Lock-In Story

The Register reported that HMRC — the UK's tax authority — publicly vowed to reduce its dependence on Capgemini, then handed the French IT giant another £4.2 billion in contracts. The supplier that was supposed to be phased out could now remain embedded inside the tax collector's infrastructure until 2036.

If you work in IT operations, you don't need the National Audit Office to explain why. You live this dynamic at smaller scale every single day. Once a vendor — or a stack of vendors — becomes woven deeply enough into how your infrastructure runs, "leaving" stops being a decision and becomes a multi-year programme with its own budget line, steering committee, and risk register.

The £4.2B headline is government-scale. The pattern is not. It's the MSP tech with twelve browser tabs across five tools to support one client. It's the internal IT team that finds out about a downed file server from an angry user ticket instead of their monitoring platform. It's the IT manager who can't produce a trustworthy SLA report because the alert data and the ticket data live in systems that don't speak to each other.

The Problem in Depth: Your Monitoring Stack Is Its Own Aspire Contract

Look at how most mid-size IT environments — and plenty of MSP stacks — are actually monitored today:

• Server metrics come from one agent, often a legacy Nagios or Zabbix box someone configured in 2016 that nobody dares touch.
• Uptime and website checks live in a separate SaaS tool like Pingdom or UptimeRobot.
• Application monitoring for the two business-critical apps sits in yet another product.
• Windows endpoints and patching run through an RMM — ConnectWise, NinjaOne, Datto, or similar.
• Tickets land in a helpdesk — ServiceNow, ConnectWise Manage, Freshservice — that has no idea what the monitoring tools are saying.

Each tool was bought at a different time, by a different person, under different budget pressure. Integrations between them, if they exist at all, are webhooks, PowerShell glue scripts, and monthly CSV exports maintained by whoever originally wrote them. Sound familiar? That glue is your own private systems-integration contract — except the integrator is a sysadmin who already has a day job.

What This Costs You in Real Terms

Detection time measured in user complaints. The file server's D: drive starts filling at 1am because a log directory isn't rotating. The Nagios check runs every 15 minutes, the threshold is 95%, and alerts route to a shared mailbox nobody watches overnight. The first notification is a 9:12am ticket: "file shares are slow." By then you have 23 duplicate tickets, two failed backup jobs because VSS ran out of room, and a senior sysadmin pulled off a migration project to firefight.

MTTR stretched by context-switching. The tech triaging the ticket opens the RMM to inspect the machine, the monitoring portal to check history, the helpdesk to update the ticket, and remote desktop to actually fix it. Nothing shares state, so every step re-establishes context from scratch. Remediation time balloons not because fixes are hard, but because diagnosis data is scattered across five systems.

SLA reporting nobody trusts. When the helpdesk clock starts at the user's ticket and the monitoring platform's alert history lives somewhere else, every SLA number is a negotiation. You end up reconciling exports in Excel — a report that takes half a day and convinces no one, least of all the CFO.

Alert fatigue and burnout. Five tools, five thresholds, five escalation paths, no deduplication. Your on-call rotation learns to ignore anything marked "warning" — which is exactly how real incidents get missed. And the 2am false page from a flapping switch port is how good engineers burn out and leave.

The lock-in itself. This is the HMRC lesson. Every year the sprawl persists, the glue scripts multiply, the knowledge of "which tool watches what" lives in fewer heads, and the switching cost grows. Nobody decides to stay locked in. They just defer the migration one quarter at a time until, like HMRC, the exit date quietly becomes 2036.

How AlertMonitor Solves This

AlertMonitor is built on the premise the HMRC story proves from the other direction: complexity compounds, so the unification has to be native, not bolted on.

One platform, one agent, one alert stream. Servers, Windows services, scheduled tasks, disks, applications, network devices, printers, and workstations all report into a single platform. A disk hitting 90% on SQL01 and a crashed print spooler on a branch workstation generate alerts in the same stream, with the same deduplication, flapping suppression, and escalation logic. There is no "which tool saw this first" argument, because there is one tool.

Alerts become tickets automatically. Because the helpdesk is integrated — not loosely connected — an alert can open a ticket pre-linked to the device record. The tech who picks it up sees the server's full monitoring history, recent patch state, and related alerts in one view. No tab-hopping, no asking around about what else was happening on that box.

Monitoring context and patch state side by side. When a disk alert fires, the same screen shows whether the server is compliant on patches. "The disk is fine, but this box is missing 14 updates including the one that fixes the log-bloat bug" is a conclusion a unified platform surfaces — and a stitched-together stack never will.

Intelligent alerting that respects the on-call rotation. Route by severity, tag, or client. Suppress flapping. Escalate on no-acknowledgement. The right person is paged within seconds — not discovered by a user ticket 40 minutes later.

The Workflow, Before and After

Before (fragmented stack): Nagios email fires at 1:03am → nobody sees it → first user ticket at 9:12am → triage in the helpdesk → RMM session to inspect → monitoring portal to check history → fix over RDP → close ticket → Excel reconciliation for the monthly SLA report. Total: roughly 8 hours of degraded service, 23 tickets, one project derailed.

After (AlertMonitor): Disk hits 90% at 1:02am → intelligent alert fires → ticket auto-created and on-call tech paged → remote session launched straight from the alert → logs cleaned, alert clears, ticket auto-updated with the full timeline. Total: under 15 minutes, one ticket, zero user impact.

That difference — detection in seconds instead of at the first coffee — is the entire point.

Practical Steps You Can Take This Week

1. Count your alert sources. List every tool that can currently generate an alert about your infrastructure. If the answer is more than two, you have the HMRC problem at department scale.

2. Audit the checks that actually matter. Most environments have critical-service gaps nobody has verified in years. Run this across your Windows servers to find services configured to auto-start that are silently stopped:

# Find services set to auto-start that are not running — these are silent incidents
$servers = Get-Content "C:\Audit\servers.txt"
foreach ($s in $servers) {
    Get-CimInstance -ComputerName $s -ClassName Win32_Service |
        Where-Object { $_.StartMode -eq 'Auto' -and $_.State -ne 'Running' } |
        Select-Object @{n='Server';e={$s}}, Name, DisplayName, State, StartMode
}

3. Baseline disk pressure across the estate. Disk-full is still the number-one preventable outage in most shops. Get the real numbers before someone else finds them for you:

# Free space percentage on all fixed disks across the server estate
foreach ($s in (Get-Content "C:\Audit\servers.txt")) {
    Get-CimInstance -ComputerName $s -ClassName Win32_LogicalDisk -Filter "DriveType=3" |
        Select-Object @{n='Server';e={$s}}, DeviceID,
            @{n='SizeGB';e={[math]::Round($_.Size/1GB,1)}},
            @{n='FreeGB';e={[math]::Round($_.FreeSpace/1GB,1)}},
            @{n='FreePercent';e={[math]::Round(($_.FreeSpace/$_.Size)*100,1)}}
}

4. Check patch exposure next to health. Unified platforms make this a dashboard; if you're not there yet, at least snapshot pending updates per server:

# Count and list pending Windows updates on the local server
$session  = New-Object -ComObject Microsoft.Update.Session
$searcher = $session.CreateUpdateSearcher()
$pending  = $searcher.Search("IsInstalled=0")
Write-Output "$(hostname): $($pending.Count) update(s) pending"
$pending.Updates | Select-Object Title

And apply the same discipline on the Linux side of the estate:

# One-line Linux triage: full disks, failed units, load
df -h | awk 'NR>1 && sub(/%,"",$5)+0 >= 85 {print "DISK WARNING: "$6" at "$5" used"}'
systemctl list-units --state=failed --no-pager
uptime

5. Consolidate the alert stream. Every check above belongs in one platform with one escalation policy. That is exactly what AlertMonitor's infrastructure monitoring does: point your servers at a single agent, set thresholds once, and let the platform page, ticket, and track the resolution end to end.

6. Break up early, on your terms. HMRC's mistake wasn't choosing Capgemini — it was deferring the exit until the exit cost more than the contract. Every quarter you keep a fragmented stack, the glue gets thicker. Migrating monitoring while things are calm is a two-week project. Migrating after the next major incident is a six-month one.

The Bottom Line

Nobody sets out to build a £4.2B dependency. It accretes — one tool purchase, one integration script, one "we'll consolidate next year" at a time. The IT teams that avoid the HMRC outcome are the ones who treat unified visibility as infrastructure in its own right: one agent, one alert stream, one place where monitoring, helpdesk, RMM, and patching already agree with each other.

Detect in seconds. Fix in minutes. Report from one system. That's the exit plan.

Related Resources

AlertMonitor Infrastructure & Server Monitoring AlertMonitor Platform Overview Book a Demo Infrastructure & Server Monitoring Resources