After a series of failures with upgrades and deployments in production, the leadership team starts to ask questions about what went wrong, and they hear back from the engineers in various teams, "Well, our code worked perfectly, but the other team's automation failed, or got overwritten." With some deeper diving, you find out there is hardening being applied to all systems using Chef, the middleware team handles upgrades using Bash, and the deployment is an Ansible playbook triggered by a Jenkins pipeline.
Looking at this at a high level, it might seem like migrating to a single tool will solve the issues that are occurring, but the trouble is that a one-tool mandate mostly changes authoring syntax. It does not automatically change where production runs originate, how access is approved, how targets are assembled or how evidence survives after a run. Teams can migrate content and still keep the same brittle bastions, the same copied credentials and the same weak audit trail. In practice, most migrations never fully finish, so you often end up adding another tool instead of replacing the old, exactly the pattern captured in XKCD 927.
A tool consolidation program is not the wrong answer. It is just rarely the right priority.
Previously: The Cost and Pattern of Uncontrolled Execution
In the first three posts, I made one argument from three angles: multi-tool reality is not the core risk, uncontrolled execution creates measurable operating cost and recurring incidents usually trace back to the same execution breakpoints.
This week, I focus on the next question: Does tool sprawl contribute to the risk of uncontrolled execution?
Why "just pick one tool" sounds so reasonable
I understand why "just pick one tool" wins the room. It promises fewer procurement fights, fewer training tracks and a cleaner story for an executive who is tired of hearing that every team runs its own way. Standardization worked for operating systems, for observability agents, for the ticketing stack. So why not automation?
Because automation is more than just the tool. It is the decades of habits, inherited platforms and the decisions the evolving team made under pressure. It is the comfortable chair you sit in every day, supporting everything you do. You can consolidate, and it’s not wrong to do so in the right circumstances, but what looks like a routine software choice in the project presentation is full of complex, slow, political changes.
I have worked with organizations that insist on a single standard, but the production risks have not changed eighteen months later. The logo count on the architecture slide went down, although the old tools likely always persist. The shared bastions, the local schedulers and the patchwork approvals remain just the same.
Consolidation does solve some real problems
To be fair, a smaller tool catalog does buy you things. It is easier to support. Hiring gets simpler when you are not chasing five skill sets. Packaging and internal enablement get lighter. And if two tools genuinely do the same job in the same place, keeping both forever is hard to defend.
So the issue is not that consolidation is useless. It is that we expect it to fix the thing that started the fire, when most of the time it does not go near it.
What are you actually trying to achieve?
When organizations decide they need to standardize on a single automation tool, they do so with intentions that seem to make sense. Multiple tools create complexity, and lead to a fragmented skill set. Keeping your staff trained on all the tools they will encounter is costly, and support costs will be higher as a result.
But step back for a moment and ask a different question. What problem are you actually trying to solve?
If you have experienced failed upgrades, inconsistent deployments, unexpected outages or difficult audits, the outcome you are looking for probably is not one automation tool. The outcome is safer, more predictable operations.
That is where many consolidation programs go wrong. They focus on changing the tool and assume the operational outcomes will follow. Sometimes they do. Often they do not.
The reason is simple: most operational failures are not caused by the automation engine itself. They happen because of how automation is executed, controlled and governed around the tool.
When you look at the changes organizations usually want, a different set of priorities starts to emerge.
Consistent execution regardless of who runs it
A common goal is ensuring that production changes happen the same way every time, regardless of which team initiates them.
Replacing multiple automation tools with one does not automatically achieve that. Jobs can still be launched from unmanaged bastions, local schedulers or individual workstations. The automation syntax may be standardized, but the execution path remains inconsistent.
Better control over privileged access
Many organizations want fewer security exceptions and tighter control over who can make production changes.
A tool migration does not necessarily address that. Shared service accounts, copied credentials and broad administrative permissions often survive long after the consolidation project is complete. The interface changes, but the access model remains largely the same.
Reliable and repeatable targeting
Another common objective is reducing mistakes caused by changes being applied to the wrong systems.
That depends less on the automation language being used and more on how targets are selected and validated. Teams frequently continue to rely on spreadsheets, exports and locally maintained lists even after standardizing on a single platform.
Clear operational evidence
When incidents occur, teams need to understand what happened, who approved it and what actually ran.
A one-tool strategy can help, but only if execution records, approvals and runtime context are captured in a consistent way. If that information remains scattered across different systems, investigations are no easier than before.
This is the distinction many organizations miss. They standardize how automation is written before they standardize how automation runs. One affects how jobs are authored. The other affects how safely and consistently they behave in production.
The execution risks do not disappear with the second tool
In a team I was on once, a deployment and configuration system was built from a couple of different tools. It had always been a little flaky but mostly worked, however the decision was made to consolidate to a single tool. For a little while, this looked like a great success until the resulting outage, in which the new tool ran scripts that locked everyone out of the machine, proved that the problems were not caused by the tool suite but by surrounding failures in the deployment processes.
The new jobs were still firing from an admin’s laptop, still using the single service account and still pointed at a target list someone built outside the non-existent workflow.
The tool wasn’t at fault; it correctly executed what it was given. When you treat content standardization and execution standardization as the same job, that is what you get.
Blur those two together, and you spend on the expensive part first. You rewrite content, retrain people and eat the political friction, but the incident pattern that started all of this barely changes. As a result, tooling migration and standardization programs feel like busy work and never feel safe.
What to standardize first if the goal is safer automation
If you want production risk down this quarter, start with the run path, not the tool. Drive production execution through a single controlled entry point. Agree on how targets get defined. Keep the evidence of a run in a shape an incident responder or auditor can actually use. Get that in place, and better tool decisions follow, because now something real is holding the environment together instead of tribal memory.
I will be honest about the cost: this adds process, and teams that enjoyed local autonomy will feel it. Runs that used to be informal will need clearer approval, tighter target definitions, and someone actually owning the runtime. Say that out loud. Credibility comes from naming the tradeoff, not pretending governance is free.
The upside is that you fix the part that hurts most first. You do not have to wait out a two-year consolidation plan to get better attribution, traceability and consistency in how things run.
Standardize the run path, then modernize on purpose
Sequencing it this way also makes the eventual modernization sharper. Once execution is governed, you can finally see it: which content is genuinely risky, which runtimes are fragile, which teams are dragging the most operational weight. At that point, consolidation is a targeted engineering call, not a banner you hang over the next steering committee.
Here is an exercise for whoever is planning next quarter. Draw two columns. On the left, the run-path controls you can tighten now: launch point, access model, targeting rules, retained evidence. On the right, the content migrations that can wait until those controls exist. The split tends to settle the argument on its own, because the left column changes your next maintenance window and the right column mostly moves the roadmap.
For a practical next step you can use now, read the Automation Governance Readiness guide. If you want to see this operating model in practice, request a Chef 360 trial.
