By Most patch-day incidents aren’t caused by bad patches. They’re caused by inconsistent execution — different team members following different procedures, with no shared baseline for what success looks like. The fix is operational, not architectural, and it costs nothing to implement.
The Guest: Dave Bermingham, Senior Technical Evangelist at SIOS Technology
The Bottom Line: • Documenting and rehearsing a repeatable patching procedure — and running a planned switchover test before any patching begins — is the single highest-ROI improvement an IT team can make; it eliminates the coordination failures that cause patch-day mistakes and transforms maintenance windows from high-stakes gambles into predictable, low-stress operations
👇 Click to Read Technical Deep Dive
Speaking with TFiR, Dave Bermingham of SIOS Technology defined the current state of patch management execution in enterprise IT — and identified the one operational change that delivers more confidence and fewer incidents than any tooling upgrade.
WHAT IS THE SINGLE MOST IMPACTFUL STEP FOR SAFER HA PATCHING?
When asked for the one thing IT teams can do to make patching safer, more secure, and faster, Bermingham’s answer was not a new platform or a new architecture. It was a documented, rehearsed patching playbook — and the discipline to run a switchover test before the maintenance window begins.
“One of the easiest things is to document and rehearse the patching procedure. It sounds pretty basic, but many organizations handle patching differently every time. One person does it one way, another person does it differently, and that’s where mistakes can happen.”
The problem Bermingham describes is not a skills gap — it is a coordination gap. When there is no shared procedure, each patch cycle introduces variability. That variability is where mistakes originate. A documented, repeatable process eliminates that variability and gives the entire team a common reference point before the maintenance window opens.
“If you define a repeatable process and practice it to make it easy during the maintenance window, the whole team becomes much more confident. If you’re all working off the same playbook, even something as simple as running a planned switchover test before patching can make a huge difference.”
The Pre-Patch Switchover Test
The pre-patch switchover test is the most actionable single practice Bermingham recommends. Before any patching begins, the team runs a planned failover to confirm the application can move between nodes successfully. If it can, the team enters the maintenance window with confidence. If it can’t, they’ve discovered the problem before it becomes a production incident.
“If you know the application can move between nodes successfully, patching becomes much less stressful.”
This test costs minutes and eliminates one of the most common sources of patch-day anxiety: the uncertainty about whether the cluster will behave correctly when it matters most.
Broader Context: The Playbook Within the Larger HA Patching Strategy
In the full TFiR interview, Bermingham frames the patching playbook as the operational layer that sits on top of the right architectural foundation. The standby-node-first patching workflow — patch the standby node, validate, fail the workload over, patch the original — provides the structural mechanism for near-zero downtime patching. The playbook ensures every team member executes that mechanism the same way, every time.
Bermingham also connects the playbook discipline to the configuration drift problem. Nodes that are regularly patched using a consistent, documented procedure are less likely to diverge over time — which means fewer silent discrepancies between nodes and fewer failover surprises in production.
The broader message across the full interview is consistent: patch anxiety is a solvable problem. It requires the right HA architecture, a repeatable operational process, and the discipline to rehearse — not just document — the procedure before it is needed under pressure.
Watch the full TFiR interview with Dave Bermingham here
