Becoming the Linux team a distributor could not hire

The situation

An industrial products distributor ran a Linux server estate underneath applications that mattered to daily operations, supported by an internal IT team whose depth was entirely in Windows. Patching happened when someone remembered. Configuration drifted. Nobody had a current inventory, and the single person who understood the estate was a well-understood continuity risk.

This is the most common Linux situation we encounter, and it rarely presents as a crisis. It presents as a slow accumulation of things nobody wants to touch.

What we did

Inventory before anything else. Establishing what actually existed — distributions, versions, roles, dependencies, and which systems were genuinely still in use — produced the first accurate picture of the estate the client had ever had. Several systems turned out to be running unsupported releases nobody had flagged.

Patching turned into a process. Scheduled maintenance windows, tested rollback paths, and a defined cadence replaced ad-hoc updates. The point of a patch schedule is not the patching; it is that a schedule makes deferrals visible instead of silent.

Baseline configuration and hardening. CIS Benchmark-aligned baselines were applied with documented exceptions, because a benchmark applied blindly will break production. The client received the applied configuration, the list of deviations, and the business justification for each.

Monitoring and escalation. Proactive monitoring with alert triage, and an escalation path into senior Linux engineering that did not depend on one internal person being reachable.

The outcome

The distributor gained a Linux capability without hiring a Linux engineer — a role that would have been difficult to justify at their scale, harder to recruit, and hardest to retain. Their internal team kept ownership of the relationships and the business context; we took the specialist layer.

The engagement has run as an ongoing retainer across multiple years, which is the useful signal. Project work proves you can do the job once. Retained work proves the client kept wanting it done.