Patch & Pause: Coordinating System Updates in Live Buildings

Why updates in live buildings are different

In this episode of Built, Wired & Secured, Alex Morgan sits down with Michael Harrington to talk about a problem every commercial property team eventually faces: system updates that look routine on paper but create real disruption when they go wrong in a live building. The conversation centers on a simple truth: patches are necessary, but poorly coordinated change can affect tenant access, deliveries, comfort, and confidence faster than most teams expect.

The episode opens with a familiar scenario. A late-night firmware update is treated as low risk. By morning, tenants cannot badge in, deliveries are stalled, meetings are delayed, and the operations team is stuck trying to reverse a change that should have been controlled from the start. The point is not that updates are bad. The point is that in occupied buildings, even small changes can have operational consequences that ripple far beyond the system being patched.

What change management means in commercial buildings

Michael defines change management for buildings as the orchestration of updates across mechanical, electrical, security, and network systems so changes happen safely and with minimal tenant impact. That definition matters because it moves the discussion beyond IT in isolation. In a building environment, a patch does not live inside one technical silo. Access control, HVAC, gateways, controllers, and network dependencies all connect in ways that affect occupants and daily operations.

From an operations perspective, the failure modes are not mysterious. They are usually predictable:

• Missing dependencies that were never mapped
• Unclear ownership over who approves and coordinates change
• Silent vendor updates that arrive without enough visibility
• Single points of failure that were never documented

Michael frames the risk with one important question: what breaks if this goes down? If a team cannot answer that quickly, it has not scoped the risk well enough.

Why routine updates become tenant-facing problems

A major theme in the episode is that outages usually come from a mix of technical debt and process gaps. Technical debt certainly matters. Older controllers, unsupported firmware, and custom integrations all increase fragility. But process is often what turns fragility into disruption.

The discussion highlights several examples of how that happens:

• An undocumented handoff between security and facilities leaves nobody fully accountable
• A vendor pushes a patch assuming a network dependency is unused when it is actually critical
• A card reader is tied to a controller that has not been updated in years
• A backup exists, but nobody has tested whether it can restore the system to known good

In other words, the environment may appear stable right up until a normal maintenance event exposes everything that was never documented, tested, or owned.

Balancing patch urgency against operational risk

The episode does not argue for delaying updates indefinitely. Instead, it makes the case for controlled updates. Rapid patching can reduce exposure to known vulnerabilities, but frequent unscheduled changes increase the odds of an outage in an occupied building. The practical answer is not to stop patching. It is to categorize updates by impact and apply the right level of control.

Michael offers a clear rule of thumb:

• Low-impact, reversible changes can be grouped into regular weekly maintenance windows
• High-impact or non-reversible changes need staging, explicit signoff, and a rollback plan

That framework gives teams a way to move quickly where appropriate while slowing down when the building, tenant experience, or recovery path justifies it.

Who should own the change calendar?

One of the most actionable parts of the conversation is the discussion around ownership. Michael recommends designating a single change owner role. In many commercial properties, that role sits with building operations or facilities, with clear escalation to IT for networked systems. What matters most is not the department label. What matters is having one accountable owner for coordination.

That owner should be responsible for:

• Publishing and maintaining the change calendar
• Coordinating maintenance windows
• Collecting approvals from stakeholders
• Enforcing vendor requirements before live changes occur
• Sharing upcoming windows with tenants and vendors

The episode makes the case that this is a lightweight governance layer, not unnecessary bureaucracy. A visible calendar and a few mandatory requirements reduce surprises without slowing teams down more than necessary.

Lightweight testing that actually catches problems

Testing often gets dismissed as too expensive or too heavy for real-world building operations. Michael argues for a pragmatic middle ground. Teams do not always need a large lab or major capital investment to reduce risk. They need discipline around a short list of checks that catch common failures before production is affected.

Recommended pre-deployment controls include:

• Confirm backups are current
• Validate configuration snapshots
• Verify communication paths to controllers
• Test rollback during a controlled window
• Confirm the system can return to known good

For higher-risk devices, Michael suggests using a parallel controller or an off-hour staging zone that mirrors the live setup as closely as practical. He also recommends requiring vendors to explain likely failure modes and provide a recovery checklist in advance.

Two examples that led to better process

The episode includes two concise examples that show how small oversights create big problems. In the first, an overnight access control firmware update was pushed without verifying controller time zone settings. The result was failed badge authentication across several zones the next morning. Recovery required both a rollback and manual time correction on hundreds of readers. The process change afterward was simple and specific: timestamp checks became mandatory on every pre-deployment checklist, and staging windows became required for firmware updates.

In the second example, an HVAC controller update changed Modbus polling intervals and overloaded a gateway. That caused heat scheduling to fail for a floor. Again, the fix was process, not new technology. The team added explicit dependency mapping and limited concurrent vendor changes during occupancy hours.

Rules of thumb listeners can use immediately

Near the end of the episode, Michael distills the discussion into three rules of thumb:

• Own the calendar with one change owner and published windows
• Categorize risk instead of treating every update the same
• Require rollback and never make a live change without a tested fallback

He also outlines a simple post-change checklist that teams can adopt right away:

• Verify the primary function works
• Confirm dependent systems are operating normally
• Validate tenant access or occupant safety systems
• Record exact versions and results
• Send a quick update to stakeholders

Why this matters

The bigger takeaway from this episode is that change management in buildings is really about trust. When updates are coordinated well, tenants barely notice them. When they are not, the effects show up quickly in access, comfort, schedules, and confidence in the building team. Clear ownership, practical testing, documented rollback, and simple communication can prevent a routine patch from becoming a building-wide issue.

If you manage live environments, this episode offers straightforward guidance you can apply without adding unnecessary process: know who owns the change, understand what depends on what, test the fallback before you need it, and communicate early when windows are planned. In commercial buildings, that discipline protects both operations and tenant experience.

Patch management in live buildings is not just an IT task

System updates are unavoidable in commercial buildings. Access control firmware needs attention. HVAC controllers need updates. Fire panel-related systems may require patches. Network appliances cannot be ignored forever. The issue is not whether updates should happen. The issue is whether they are coordinated well enough to protect the building, the tenant experience, and the people responsible for daily operations.

In this episode of Built, Wired & Secured, Alex Morgan speaks with Michael Harrington about the operational side of change management in live buildings. The conversation is direct and practical. Rather than treating updates as a narrow technical event, it frames them as a business and building operations issue. A poorly managed change can delay meetings, block deliveries, disrupt comfort, and erode trust in the teams and vendors responsible for the environment.

The episode opens with a simple but costly example: a firmware update runs overnight, appears to complete successfully, and then creates badge access failures the next morning. Tenants cannot get where they need to go. Building operations is stuck with the vendor. Everyone is scrambling to roll back a change that should have been planned with more discipline.

That scenario is the core lesson of the episode. In occupied buildings, low-visibility technical work can create high-visibility operational problems.

What change management means in a building environment

Michael defines change management in buildings as the orchestration of updates across mechanical, electrical, security, and network systems so changes happen safely and with minimal tenant impact. That definition is useful because it recognizes how connected building systems really are. A patch may target one controller or one appliance, but the effects can spread across access, scheduling, environmental controls, and vendor workflows.

That is why the common failure modes sound less like advanced engineering failures and more like gaps in coordination:

• Dependencies were never documented
• Ownership was unclear
• Vendors pushed changes without enough warning or review
• Single points of failure existed but were not visible to the team

One of the sharpest questions raised in the episode is also one of the simplest: what breaks if this goes down? If the answer is slow, uncertain, or incomplete, the environment is carrying more risk than it appears to be.

Why updates fail even when the hardware is not the real problem

It is tempting to blame failures on outdated equipment alone. Technical debt does matter. Unsupported firmware, old controllers, and bespoke integrations all increase fragility. But the episode makes clear that process often determines whether that fragility becomes a real incident.

A building may have decent hardware and still experience a disruptive change because of an undocumented handoff between teams, a vendor assumption about a network dependency, or an untested backup that only exists on paper. In many cases, the problem is not the update itself. It is the lack of visibility around how systems interact in the real environment.

This is especially important in commercial real estate, where building technology often sits at the intersection of multiple groups. Facilities may own operations. Security may own access systems. IT may own the network. Vendors may control specialized platforms. If nobody has end-to-end accountability for the change window, gaps appear fast.

Control matters more than speed alone

The conversation also avoids an unhelpful extreme. It does not suggest delaying updates forever in the name of stability. Security and reliability updates still matter. Known vulnerabilities still carry risk. But the episode argues that the right goal is controlled change, not just fast change.

Michael offers a practical framework: categorize updates by impact. Low-impact, reversible changes can be bundled into regular maintenance windows. Higher-impact or non-reversible changes require staging, explicit signoff, and a tested rollback plan.

That distinction matters because not all updates carry the same operational consequences. Treating every change as urgent creates unnecessary churn. Treating every change as routine creates blind spots. The better path is to match the governance to the risk.

That is a strong lesson for building decision makers. Good change management is not about adding layers of process for the sake of process. It is about applying the right amount of control before a live environment feels the impact.

Why one owner should control the calendar

One of the most actionable recommendations in the episode is to designate a single change owner role. In many properties, that role sits in building operations or facilities, with clear escalation to IT for networked systems. The exact org chart matters less than the accountability.

Someone has to own the calendar.

That owner should publish maintenance windows, collect approvals, coordinate with stakeholders, enforce vendor requirements, and make sure both tenants and vendors know what is scheduled. Without that single owner, change becomes a series of disconnected events instead of a controlled operational function.

This is where many organizations can improve quickly. They do not necessarily need a heavy enterprise governance model. They need one visible calendar, one accountable coordinator, and clear expectations for what must be provided before a live update proceeds.

Michael specifically calls out two vendor requirements that should become standard: a pre-deployment checklist and minimum rollback capability. Those are not excessive asks. They are practical safeguards for any building that depends on connected systems.

Testing does not need to be expensive to be useful

Another important takeaway is that testing can remain lightweight while still catching meaningful problems. Teams often avoid testing because they assume it requires a large duplicate environment or a long project cycle. The episode pushes back on that assumption.

A pragmatic pre-deployment checklist can prevent many common failures. Michael recommends confirming backups, validating configuration snapshots, verifying communication paths to controllers, and testing rollback during a controlled window. The key question is simple: can the system return to known good if the change does not behave as expected?

For higher-risk devices, the recommendation is to use a parallel controller or an off-hour staging zone that mirrors the live setup as closely as possible. Just as important, vendors should be able to explain failure modes ahead of time and provide a recovery checklist that building teams can use under pressure.

That combination of modest preparation and explicit recovery planning is often enough to reduce risk materially without creating major overhead.

Real examples show why process fixes matter

The episode includes two practical examples that make the case clearly. In the first, an access control firmware update was pushed overnight without verifying controller time zone settings. Badge authentication then failed across several zones. The recovery effort required a rollback plus manual time correction on hundreds of readers. The long-term improvement was not a major technology replacement. It was a process change: mandatory timestamp checks and a required staging window for firmware.

In the second example, an HVAC controller update changed Modbus polling intervals and overloaded a gateway. That caused heat scheduling to fail for a floor. The fix again was process. The team added explicit dependency mapping and limited concurrent vendor changes during occupancy hours.

These examples matter because they show how often resilient operations come from better coordination, clearer requirements, and more disciplined windows rather than from buying entirely new systems.

Three rules of thumb for building teams

For listeners who want immediate action, the episode offers three rules worth adopting now:

• Own the calendar with one change owner and published windows
• Categorize risk so low-impact and high-impact changes are not treated the same
• Require rollback and never proceed without a tested fallback

Those three points form a practical operating model. They create enough structure to lower risk without burying teams in bureaucracy.

A simple post-change checklist that improves visibility

Michael also outlines a post-change checklist that is intentionally simple:

• Verify the primary function
• Confirm dependent systems
• Validate tenant access or occupant safety systems
• Record exact versions and results
• Send a quick stakeholder update

This step is easy to overlook, but it matters. A change is not complete just because the installer says the patch succeeded. The environment still has to work for the people using it. That means confirming operational outcomes, not just installation status.

The business lesson behind the technical discussion

The deeper message of the episode is that change management protects trust as much as technology. Tenants may never know when a well-run update happens, and that is usually the point. But they notice immediately when access fails, temperatures drift, deliveries are delayed, or teams cannot explain what happened.

For property teams, ownership and communication are operational strengths. For vendors, rollback readiness and dependency awareness are minimum requirements. For building leadership, lightweight governance is not bureaucracy when it reduces disruption and protects the tenant experience.

That is exactly where GDS Technology’s Technology Partner approach becomes relevant. Commercial buildings do not need vendors who only complete isolated tasks. They need partners who understand how infrastructure, security, and operations affect each other in the real world. Coordinating change windows, validating dependencies, reducing single points of failure, and protecting occupant-facing systems are all part of owning the environment long term.

If your building team is still handling updates ad hoc, this episode is a strong reminder to tighten the process before the next routine patch turns into an avoidable disruption. Listen to the full conversation for the examples, the rules of thumb, and the checklist you can start using right away at https://builtwiredsecured.com/episodes/patch-pause-coordinating-system-updates-live-buildings.