Replacing a six-figure platform nobody used

What was needed

The organization was carrying a six-figure annual license on a commercial infrastructure automation platform. The product was not bad. It did much of what we needed and arguably more.

Nobody used it.

It had been implemented poorly and never adopted, and once that happens to a platform the cost keeps arriving every year while the value never does. Meanwhile the actual automation in the organization lived where it always lives: on individual laptops and shared tool servers, in scripts that worked and that no one else could safely change.

I was in that second category myself. My infrastructure health checks had replaced a manual offshore process and were running successfully — on Windows Task Scheduler, on a tools server, with no version history, no artifacts, and no record of what had run. They worked, and they were exactly the thing I would have told someone else not to depend on. A script on a tools server is not a system.

Underneath both problems is the larger one: moving systems administrators toward a DevOps practice at a Fortune 500 company is a genuinely large undertaking. Several attempts had been made. As far as I know, this is the first one in this organization that reached production and stayed there.

What I built

The design started from a diagnosis rather than a feature list. The commercial platform did not fail on capability. It failed on adoption. So the replacement had to be built around the reasons engineers don't adopt platforms, and those reasons are fairly consistent: it takes work away from them, it takes ownership away from them, and it demands they rewrite things that already work.

Two things, held deliberately apart.

The standard defines the minimum controls for automation that touches production infrastructure: versioned source, a repeatable execution path, controlled credentials, usable output or evidence, and named ownership. It is tool-agnostic on purpose. Any tool meeting those five points is fine.

The platform is one reference implementation of that standard. GitLab holds source, history, and runbooks. Jenkins provides orchestration, scheduling, parameters, approval gates, logs, and artifact retention. Purpose-built Docker agents supply isolated Windows and Linux runtimes so no two workflows contaminate each other. Service accounts execute; people don't. Credentials come from a store, scoped per folder and job, and are purged after the run.

Separating those two is the single most important decision in the whole thing. The moment adoption sounds like everything must move onto my tool, it stops — and that is roughly what had happened before.

The division of responsibility follows the same logic. Domain engineers keep ownership of their logic, its correctness, and its failure handling. The platform owns only the execution environment, credential injection, evidence capture, version tracking, access control, and audit logging. Nobody hands over their scripts. The ask is not give me your work, it is run your work somewhere it can be replayed.

And the migration path is promote, don't rewrite. Where a script already works: put it in source control, run it through the orchestrator by hand, add parameters, add pre-checks, add evidence collection, add an approval gate where the risk warrants one, document the owner. Eight steps, each independently useful, none requiring anyone to rebuild anything that already runs.

A workflow doesn't count as adopted because it exists. It counts when the team can run and own it without routine dependence on whoever wrote it.

What it does in production today

Three of my own workflows run on a schedule against production infrastructure:

2,415 production runs, 209 of 213 succeeding in the retained window. Every pipeline on the platform — 13 of 13 — pulls every secret from the credential store, with zero inline secrets in any pipeline file. Agent images pin their own contents explicitly. Terraform-based build workflows sit behind approval prompts. The directory sync takes a full database backup before every run and aborts the entire run if that backup fails.

Across the whole controller, 3,902 builds have executed, and 1,285 of them belong to four other groups' folders — one of those groups accounting for 893 across thirteen jobs, two of them on their own schedules. That is a workload figure, not a headcount: today the platform is used directly by me and roughly five other systems administrators, engineers, and architects.

Which is the honest current state. It is in production, it is load-bearing, and it is early. I am now running the effort to change that — regular communication about what the platform is for, working with engineers to find the repeatable work worth promoting, and helping them promote it. The target is fifteen to twenty people building and operating workflows, plus another twenty who log in and execute something someone else built. The organization it sits in is around two hundred people.

What it replaced

A six-figure annual license renewal, replaced at no license cost.

The comparison deserves the honest version, though, because the flattering version is wrong. The commercial platform could do more than mine can. It was a mature product with capabilities I have not built and may never build.

It was also not being used, and that is the entire argument. The measure of an automation platform is not what it is capable of. It is what is actually running on it on a Tuesday morning, and whether the person who owns that workflow can change it safely next quarter. By that measure a hand-built platform with 3,900 real executions beats a comprehensive one with none, and it does it for the price of the infrastructure it runs on.

Where it falls short of its own standard

The standard has five points. My own platform does not currently meet two of them, and a page omitting that would be exactly the kind of document this platform exists to replace.

No pipeline has a post-change verification stage. Zero of thirteen. Several have thorough pre-checks — credential validation, syntax parsing, module availability — and all of them archive artifacts. Not one independently confirms system state after it acts. On read-only health checks that gap is narrow. On the build pipelines it is not.

No repository documents rollback. Zero of ten. One documents backup-before-change, which is adjacent and not the same thing.

One health check runs entirely outside the platform. The SAN check has produced 1,269 hourly runs of evidence on disk and has exactly one build in its Jenkins job's whole history. Something executes it faithfully every hour, and whatever that something is has no build record, no artifact retention, and no failure alerting. The most reliably-running check I own is the one least governed by the thing I built to govern it.

Two build pipelines have never run. Two more last executed nine months ago. Real code, real approval gates, not delivered capability.

One repository's documentation contradicted its own code in six places, including a stated safety default the shipped script overrides. The code was right and the document was wrong — which is the more dangerous ordering, because nothing ever failed and so nothing ever corrected the document.