Show Notes
Plan for the Sunset Before a Building System Forces the Issue
Building technology rarely fails at a convenient time. An access control controller reaches end of life during a weekday morning. A legacy HVAC gateway develops a firmware issue. A spare part is on a shelf, but it is incompatible with the equipment it is supposed to replace. What looked like a minor technical issue becomes a tenant disruption, an emergency capital request, and a preventable hit to operational trust.
In this episode of Built, Wired & Secured, Alex Morgan and Michael Harrington discuss practical lifecycle planning for building technology. The conversation focuses on the systems that keep commercial properties operating: access control, HVAC controls, networks, gateways, and other low-voltage infrastructure that can quietly become a risk when support windows, firmware baselines, and replacement plans are not tracked.
The central message is straightforward: lifecycle planning is not about predicting every possible failure. It is about creating repeatable habits that make failures less disruptive, replacements less expensive, and decisions more deliberate.
Why Building Technology Reaches End of Life Unexpectedly
End-of-life events often appear sudden because the underlying risks were allowed to remain invisible. Teams may focus on immediate project pressures such as a move-in date, an installation schedule, or the lowest available purchase price. Equipment gets installed, begins a multi-year lifecycle, and no one creates a process to monitor its support status.
Several recurring causes can combine to create an avoidable outage:
- Short-term procurement decisions: Equipment is selected based on availability, price, or a deadline without considering its long-term support horizon.
- Incomplete handovers: Contractors may turn over systems without clear end-of-life dates, firmware records, support commitments, or operational runbooks.
- Unreliable spare parts: Spare closets can contain mismatched components that have not been tested against the active environment.
- Quiet vendor announcements: Manufacturers may announce end of support without the property team having a process to turn that notice into a planned refresh.
- Dependencies that were never cataloged: Teams may not know what systems, tenants, or building functions are affected when a specific device fails.
When these issues remain unaddressed, the lifecycle ends silently until a production outage exposes the gap.
The Cost of Waiting for a Failure
The episode opens with a scenario familiar to many building operators: an access control controller hits end of life during a peak weekday morning. Locks stop responding, tenants cannot access core areas, operations staff scramble for replacement equipment, and contractors rush to find parts. The immediate outage may last only a few hours, but the consequences extend well beyond that window.
Tenant trust can suffer. Property teams are pulled into crisis communication. Emergency labor and expedited parts increase costs. Most importantly, an unplanned capital request has to compete with every other business priority after the risk has already become an incident.
A legacy HVAC controller example demonstrates the same pattern. A campus continued using an older controller family because the system was still heating and cooling effectively. When a gateway firmware issue affected several rooftop units, the available vendor patch applied only to supported models. Older controllers required physical replacement, emergency crane time, unbudgeted capital, and a week of tenant disruption caused by temperature swings. A staged refresh would have cost less and created fewer operational problems.
Choosing Between Phased Refreshes and Big-Bang Replacements
Property leaders must decide whether to refresh systems in stages or replace an entire environment at once. Neither approach is automatically right. The decision should be based on the building’s mission-critical functions, tenant impact, compatibility requirements, and capital planning realities.
A phased refresh can spread capital spending over time and reduce disruption by scheduling work around vacancies, lower-occupancy periods, or lower-risk operational windows. It also allows teams to pilot new equipment, validate integrations, and learn from a limited deployment before expanding the project.
The tradeoff is that phased projects create mixed fleets. Older and newer equipment may increase management complexity, require more spare-part types, and introduce compatibility considerations.
A big-bang replacement produces a more uniform environment with fewer compatibility surprises and simpler long-term management. However, it requires a larger capital commitment and a tightly coordinated cutover. Without careful planning, that concentrated work can create greater tenant disruption.
The practical question is not simply which approach costs less. It is which approach creates an acceptable level of operational risk for the parts of the building that cannot tolerate disruption.
Make Cybersecurity Part of the Lifecycle Calendar
Lifecycle planning is also a security issue. Aging devices may no longer receive patches, lack modern security features, or remain connected to systems that contain sensitive operational information. As equipment approaches end of support, it should become an elevated risk item rather than a passive inventory record.
Where immediate replacement is not possible, teams can reduce exposure by segmenting, isolating, and hardening legacy devices until retirement. Procurement decisions should also account for a vendor’s long-term patching commitments, not just current product capabilities.
Prioritization starts with a simple operational question: what breaks if this device goes down or is compromised? Systems with greater operational or security impact should move earlier in the refresh plan.
A Practical Lifecycle Planning Playbook
The episode outlines five actions facilities and IT leaders can begin using in their next planning cycle:
- Build an asset inventory: Record every operationally significant device, including model, serial number, firmware, purchase date, warranty information, and end-of-life status.
- Create an end-of-life calendar: Tie support and replacement dates directly to the asset inventory so upcoming risks are visible before they become outages.
- Standardize and test spare kits: Maintain tested replacement equipment for mission-critical systems, rather than assuming stored parts will work when needed.
- Require complete vendor handovers: Make end-of-life support windows, firmware baselines, and runbooks part of system acceptance.
- Fund a lifecycle reserve: Treat technology refreshes as planned capital spending spread across years, not emergency expenses.
- Run tabletop exercises: Practice likely failure scenarios and document the steps teams need to take before an outage occurs.
What Good Lifecycle Practices Look Like
A multi-tenant lab building provides a practical example of planning working as intended. The building maintained a documented end-of-life calendar and a small spare warehouse. When a lab access controller began to fail intermittently, the team used a tested spare during a scheduled low-occupancy period and pushed a firmware rollback across the fleet.
Tenants experienced no interruption. The full capital expense could be addressed in the next fiscal quarter. A potential emergency became routine maintenance because the organization had visibility, tested equipment, and a repeatable response process.
Key Lesson
Reliable buildings are not created by hoping equipment lasts indefinitely. They are created by tracking the technology that supports operations, planning for its sunset, and giving teams the documentation, budget, parts, and procedures needed to act before a small issue becomes a major disruption.
Lifecycle Planning Is How Building Teams Avoid Technology Emergencies
Technology failures in commercial buildings are often described as unexpected. In many cases, they are not truly unexpected at all. The equipment may have been approaching end of support for years. A firmware baseline may not have been documented. A contractor handover may have omitted critical lifecycle information. A spare part may have been available but never tested. The failure feels sudden only because the organization did not have a system for seeing the risk before it became an outage.
For owners, facilities leaders, and IT and operations teams, lifecycle planning is the discipline of making building technology visible over time. It means knowing what equipment is installed, what it supports, when vendor support ends, what replacement will cost, and how a failure should be handled if it occurs before the planned refresh.
That approach applies across access control, HVAC controls, gateways, network equipment, and other low-voltage systems. It turns technology refreshes from reactive emergencies into planned operating decisions.
Why End-of-Life Events Become Operational Crises
Consider an access control controller that reaches end of life during a busy weekday morning. Locks stop responding, tenants cannot enter core areas, the property team starts fielding calls, and contractors are asked to locate a replacement immediately. The direct outage may last two hours, but the consequences can include emergency labor, rushed procurement, leadership escalation, tenant frustration, and an unplanned request for capital.
The operational cost is larger than the outage duration. Tenants evaluate building reliability based on their experience when things go wrong. A preventable access issue can affect confidence in the property team even after the equipment has been restored.
These events tend to result from the same set of lifecycle gaps:
- Equipment was selected to meet a deadline or immediate budget target without considering long-term support.
- Installation and handover documentation did not include end-of-life dates, firmware records, or support windows.
- Vendor lifecycle announcements were not converted into an internal refresh calendar.
- Critical dependencies were not identified, so teams did not understand the operational consequences of a device failure.
- Stored spare parts were mismatched, outdated, or untested.
Each issue on its own may appear manageable. Together, they create the conditions for a production failure to become a property-wide problem.
When “It Still Works” Is Not a Lifecycle Strategy
One of the most common reasons organizations defer refreshes is that a legacy system still appears to work. The equipment heats and cools the building. Doors still unlock. The gateway is still online. From a short-term perspective, delaying replacement can feel financially responsible.
The risk is that operational functionality is only one part of the lifecycle equation. A device may still work while no longer receiving patches, no longer being eligible for vendor support, or no longer having replacement parts readily available. When an issue occurs, the organization may discover that the vendor can provide a patch only for supported models, leaving older equipment to be replaced under emergency conditions.
That occurred with a legacy HVAC controller family discussed in the episode. The system continued operating until a firmware issue on a gateway left several rooftop units uncontrolled. The vendor patch was available for supported models, but older controllers required physical replacement. The result included emergency crane time, unbudgeted capital, repair costs above what a staged refresh would have required, and a week of tenant disruption caused by temperature swings.
The lesson is not that every aging device must be replaced immediately. It is that a building team needs a deliberate decision about the risk it is accepting by keeping that device in service.
Phased Refreshes Versus Big-Bang Replacements
Once a building team identifies aging technology, it usually faces a choice between a staged refresh and a full replacement project. Both approaches can be appropriate, depending on the environment.
A phased refresh distributes capital spending over multiple periods. It can be scheduled around vacancies, low-occupancy windows, or lower-risk areas of the building. Teams can test interoperability, validate integrations, and refine their implementation process before rolling out the new technology more broadly.
Phasing is especially valuable when interruption is difficult to tolerate. A controlled pilot can reveal compatibility issues before they affect every tenant or operational system.
However, phased refreshes also create mixed technology fleets. Older and newer equipment can require different firmware, different management practices, and a wider range of spare parts. That complexity must be managed intentionally.
A big-bang replacement offers a different benefit: standardization. A uniform environment is often easier to manage, support, secure, and stock for. Compatibility surprises can be reduced because the equipment is replaced within one coordinated design.
The downside is concentration of risk. A major cutover requires significant capital, detailed scheduling, and strong coordination. If the work is not planned carefully, the disruption can be greater because more systems are changing at once.
The right decision starts with a practical question: which parts of the building are mission-critical, and how much disruption can they tolerate? That answer should guide the refresh strategy rather than an assumption that one approach is always less expensive or easier.
Security Belongs in the Lifecycle Conversation
Building technology lifecycle planning cannot be separated from cybersecurity. Aging hardware may lack current security capabilities and may no longer receive vendor patches. That makes end-of-support equipment an operational concern and an elevated security risk.
When a system is nearing end of support, decision makers should determine whether it needs an accelerated replacement based on its role and exposure. Devices connected to sensitive systems or operationally critical workflows may need earlier attention. If replacement cannot happen immediately, teams can reduce risk by segmenting, isolating, and hardening legacy devices until they can be retired.
Lifecycle planning should also influence procurement. When evaluating equipment, teams should consider not just the features available today but the manufacturer’s long-term patching and support commitments. The purchase decision establishes a future lifecycle obligation. A lower initial cost can become far more expensive if support ends before the organization is prepared to replace the system.
Build a Lifecycle Management Practice
The most effective lifecycle programs are not complicated. They are consistent. They give facilities and IT teams the information needed to prioritize work before an outage creates pressure.
Start with an asset inventory for every device that affects building operations. Include the model, serial number, firmware version, purchase date, warranty status, and relevant vendor support dates. This inventory should not be a static list that is reviewed only after a failure. It should support ongoing decisions about maintenance, spares, refresh timing, and capital planning.
Next, connect that inventory to an end-of-life calendar. The calendar should make it easy to see which devices are nearing end of sale, end of support, or a practical replacement point. This creates a planning horizon that lets leadership budget for refreshes before vendor support disappears.
Critical systems also need standardized spare-part kits. A spare only helps if it is compatible, current, and tested. Teams should confirm that replacement equipment works with the active environment and review the kit periodically as the technology fleet changes.
Vendor handovers are another essential control. At project acceptance, require documentation that identifies support windows, firmware baselines, operational procedures, and runbooks. The handover should provide enough information for the operating team to understand what the system needs after the installer leaves.
Finally, establish a lifecycle reserve. Technology refreshes are predictable capital needs even when the exact date of a component failure is not. Reserving funds over time gives the organization more options and reduces the likelihood that a necessary replacement is delayed until it becomes an emergency.
Practice the Response Before the Outage
Tabletop exercises make lifecycle planning operational. A team can walk through scenarios such as a failing access controller, an unsupported HVAC gateway, or a network device that can no longer be patched. The purpose is not to create a perfect prediction. It is to validate ownership, escalation paths, documentation, available spares, and recovery steps.
Runbooks should document the steps teams need to execute when a likely failure occurs. That reduces the scramble that often follows an outage and makes it easier for facilities, IT, vendors, and property operations to coordinate effectively.
A multi-tenant lab building provides a clear example of this approach. The building had a documented end-of-life calendar and a small spare warehouse. When a lab access controller began failing intermittently, the team installed a tested spare during a scheduled low-occupancy window and performed a firmware rollback across the fleet. Tenants did not experience an interruption, and the broader capital spend was addressed in the next fiscal quarter.
The technical event still occurred. The difference was that the organization had already built the habits needed to keep it from becoming a tenant-facing crisis.
Plan for the Sunset
Technology does not remain supportable forever, and reliable building operations require more than reacting when something stops working. Asset inventories, end-of-life calendars, tested spares, vendor handover requirements, lifecycle reserves, and tabletop exercises give teams a repeatable way to manage technology through multiple replacement cycles.
The goal is not bureaucracy. It is continuity: fewer surprise costs, less downtime, stronger tenant confidence, and better decisions about the systems that keep a building operating.
Listen to this episode of Built, Wired & Secured for the full discussion on turning lifecycle planning into an operational practice that protects both building performance and long-term capital planning.