Plan for the Sunset: Lifecycle Strategies to Prevent Building Tech Surprises

Why lifecycle planning matters before failure happens

This episode of Built, Wired & Secured focuses on a problem many building teams know too well: technology refreshes are often treated as an afterthought until a failure forces action. Alex Morgan opens with a realistic scenario in which an access control controller reaches end of life during a busy workday, causing locks to fail, tenant access problems, emergency replacement work, and a costly scramble no one budgeted for. From there, the conversation turns to a practical question: how can owners, facilities leaders, and IT and operations teams make those surprises rare instead of routine?

Michael Harrington frames the issue in operational terms. He says the first question should always be, “What breaks if this goes down?” That question often exposes missing dependency tracking, unverified spare parts, and systems that quietly age past support windows until an outage makes the risk impossible to ignore. The core theme of the episode is simple: lifecycle planning is not bureaucracy. It is a repeatable operating discipline that protects uptime, budgets, and tenant trust.

Common root causes behind surprise end-of-life events

Michael outlines several repeat patterns that cause building systems to become hidden liabilities.

• Procurement and installation decisions are often driven by short-term price and schedule rather than lifecycle value.
• Teams buy equipment to hit a move-in deadline, but no one tracks the five-year or similar support clock after installation.
• Documentation gaps during contractor handover leave owners without end-of-life dates, firmware baselines, or support details.
• Spare parts are frequently stored without standardization, creating closets full of mismatched components that do not actually work together.
• Manufacturers may announce end of support quietly, so teams without an end-of-life calendar only discover the issue during an outage.

The episode makes clear that these are rarely isolated mistakes. They stack over time. A rushed install, weak documentation, incompatible spares, and poor visibility into vendor policy can combine into a failure at exactly the wrong moment.

A real-world example of deferred lifecycle action

To show how these issues play out, Michael shares an example involving a campus with a legacy HVAC controller family that had already been phased out by the vendor. Because the system still appeared to be heating and cooling normally, facilities deprioritized upgrades. The problem surfaced when a firmware issue on a gateway disrupted control for several rooftop units.

The vendor had a patch, but only for supported models. Since some controllers were already too old, those units required physical replacement. What might have been handled through a staged refresh became an emergency involving crane time, unbudgeted capital, tenant complaints about temperature swings, and a week of disruption. The lesson is direct: “It’s fine until it fails” is not a strategy. Delaying action can raise both operational pain and total cost.

Phased refresh versus big-bang replacement

Alex and Michael then compare two common replacement strategies: phased refreshes and full replacement programs.

A phased refresh offers several advantages:

• Capital spending is spread over time.
• Tenant disruption can be reduced by planning work around vacancies or lower-risk periods.
• Teams can test compatibility and integrations before rolling changes across the full environment.

But phased work also introduces tradeoffs:

• Mixed fleets can complicate management.
• Old and new devices may require broader spare part inventories.
• Operational complexity can increase while two generations of technology coexist.

A big-bang replacement has different strengths:

• It creates a more uniform environment.
• Management can become simpler after cutover.
• Compatibility surprises may be reduced once legacy gear is fully retired.

Its challenges are equally clear:

• It requires significant capital all at once.
• It depends on a tight project schedule.
• Tenant disruption risk can be higher during the cutover window.

Michael’s decision framework is operational, not theoretical: determine which building systems are mission critical and whether they can tolerate the risks that come with either phased transitions or single-event cutovers.

Why cybersecurity belongs in the lifecycle calendar

The episode also highlights that lifecycle planning is not just an uptime or budgeting issue. Aging hardware can become a cybersecurity problem when devices no longer receive patches or lack current security features. Michael advises decision makers to treat hardware approaching end of support as an elevated risk item.

That can lead to different responses depending on the system:

• Accelerate replacement in areas tied to sensitive systems.
• Segment, isolate, and harden legacy devices until they can be retired.
• Evaluate vendor commitments to patching and long-term support during procurement, not after deployment.

Again, the prioritization question is consistent: what breaks if this goes down or is compromised?

The practical playbook listeners can use next week

One of the strongest parts of the conversation is the operational playbook Michael lays out for facilities and IT leaders.

• Start with a complete asset inventory for every device that affects operations.
• Record the model, serial number, firmware, purchase date, and warranty status.
• Create an end-of-life calendar tied directly to those asset records.
• Build and regularly test spare part kits for critical systems.
• Formalize vendor handovers so accepted projects include support windows, firmware baselines, and runbooks.
• Establish a lifecycle reserve budget to smooth large replacement costs over multiple years.
• Run tabletop exercises around likely failure scenarios so teams know what to do before a real outage happens.

This is the heart of the episode: planning works best when it becomes a habit. Inventory, documentation, reserve funding, tested spares, and rehearsed response steps turn reactive chaos into controlled operations.

An example of planning that prevented disruption

Michael closes the tactical section with a positive example from a multi-tenant lab building. Because the team had a documented end-of-life calendar and a small spare warehouse, they were ready when a lab access controller began failing intermittently. Staff pulled a tested spare, performed the swap during a scheduled low-occupancy window, and pushed a firmware rollback across the fleet. Tenants noticed no interruption, and the broader capital work was handled in the next fiscal quarter as planned. What could have become a disruptive emergency instead became routine maintenance.

Five takeaways for the next planning cycle

• Build and maintain an asset inventory that includes end-of-life dates.
• Create a lifecycle reserve budget so refreshes are planned capital events rather than emergency requests.
• Standardize and test spare kits for mission-critical systems.
• Require vendor handover documentation with support windows and firmware baselines.
• Run tabletop scenarios and document runbooks so teams can respond without scrambling.

The episode ends with a strong reminder: lifecycle planning is less about predicting every failure and more about creating repeatable habits. Those habits save time, reduce surprise costs, and protect tenant trust over the long term.

Plan for the Sunset: How Lifecycle Strategy Prevents Building Tech Surprises

Many building teams do not think seriously about lifecycle planning until a system failure forces the issue. By then, the conversation is no longer about strategy. It is about scrambling for parts, calming down tenants, finding emergency budget, and explaining why a preventable outage turned into a business disruption.

That is the central issue explored in this episode of Built, Wired & Secured. Alex Morgan and Michael Harrington break down why building technology surprises happen, where lifecycle planning usually fails, and what owners, facilities leaders, and IT or operations teams can do to stay ahead of risk. The discussion stays grounded in practical operations rather than theory, which is exactly what makes it useful.

The opening scenario sets the tone. An access control controller reaches end of life in the middle of a weekday morning. Locks stop responding. Tenants cannot access core areas. Operations teams spend two hours scrambling for a replacement while frustration spreads across the building. The cost is not limited to downtime. It also shows up in damaged tenant trust and an emergency capital request that no one had planned for.

The episode’s message is clear: those moments usually feel sudden, but they are rarely random.

The problem starts long before the outage

Michael explains that the first operational question should always be simple: what breaks if this goes down? That question often reveals how little visibility teams really have into dependencies, support status, and spare readiness. In many cases, the lifecycle ends silently. A device still appears to be working, so it gets ignored. Documentation is incomplete. Vendor notices get missed. Spare parts are assumed to be available until someone discovers the “backup” is incompatible.

Several root causes come up repeatedly in the episode.

• Procurement and installation decisions are driven by short-term price or schedule pressure.
• Move-in deadlines encourage buying whatever is available now rather than what is easiest to support over time.
• Contractor handovers leave out key lifecycle information like firmware records, support windows, or end-of-life dates.
• Spare closets fill up with parts that are not standardized and may not work together.
• Manufacturers announce end of support quietly, and teams without a tracking process only learn about it after something fails.

None of those gaps may seem catastrophic on their own. Together, they create the conditions for an avoidable emergency.

Why “it still works” is not a lifecycle strategy

One of the most useful examples in the conversation involves a campus running a legacy HVAC controller family that had already been phased out by the vendor. Because the system still heated and cooled the building, facilities deprioritized the upgrade. On paper, that may have looked reasonable. In practice, it deferred risk instead of reducing it.

The issue surfaced when a firmware problem on a gateway left several rooftop units uncontrolled. The vendor had a patch, but only for supported models. Some of the older controllers were no longer eligible, which meant the team had to move into emergency physical replacement. That drove unplanned crane time, unexpected capital spend, tenant complaints about temperature swings, and a full week of disruption.

The important lesson is not just that old systems eventually fail. It is that once a platform falls outside support, even a manageable issue can become expensive because your options shrink fast. Planning early gives teams more flexibility. Waiting narrows the path to the most disruptive and costly one.

Choosing between phased refreshes and full replacements

Most property leaders eventually face the same question: should they replace systems in stages, or wait and perform a larger full replacement? The episode does not present one answer as universally right. Instead, it focuses on the tradeoffs.

Phased refreshes can smooth capital spending and reduce operational disruption when they are aligned with lower-risk windows, vacancies, or maintenance periods. They also allow teams to pilot compatibility and integration outcomes before deploying changes across the entire property. That is valuable in buildings where one system touches many others.

But phased work carries its own complexity. Mixed fleets are harder to manage. Teams may need to support both newer and older generations of equipment at the same time. Spare part strategies become broader. Uniformity takes longer to achieve.

Big-bang replacements deliver a different benefit set. They can simplify management by creating a more consistent environment and may reduce compatibility surprises once the cutover is complete. At the same time, they demand larger capital approval, tight scheduling, and careful coordination to avoid major tenant disruption.

Michael’s framing is especially practical: start with mission criticality. Which systems can tolerate phased risk? Which ones cannot? That operational reality should drive the lifecycle strategy more than a generic preference for either model.

Security risk rises as support falls away

The episode also makes an important point that many facilities teams cannot afford to treat as separate from lifecycle planning: cybersecurity. Aging hardware is not just a maintenance problem. If a device no longer receives patches or lacks current security capabilities, it becomes an elevated risk item.

Michael recommends making security part of the lifecycle calendar itself. If hardware is approaching end of support, it should trigger a different level of review. In environments with sensitive systems, replacement may need to be accelerated. Where immediate replacement is not practical, teams should segment, isolate, and harden the legacy devices until retirement is possible.

That same mindset should influence procurement. Long-term support commitments and patching policies matter. The wrong buying decision can create a hidden security exposure years after installation, especially if lifecycle planning stops at day-one functionality.

The operational playbook that actually works

Where this episode becomes especially actionable is in the playbook Michael lays out for teams to begin using immediately.

First, build a true asset inventory. Not a partial spreadsheet with a few labels, but a working record of every device that impacts operations. That means capturing model, serial number, firmware, purchase date, and warranty details. Once those records exist, tie them to an end-of-life calendar.

Second, create spare part kits for critical systems and test them regularly. A spare that has not been verified is not really a spare. In an outage, assumptions fail fast.

Third, formalize vendor and contractor handovers. Support windows, firmware baselines, and runbooks should be acceptance requirements, not optional extras. If teams do not receive that information up front, they usually end up paying for the gap later.

Fourth, establish a lifecycle reserve budget. This is a business discipline as much as a technical one. Refreshes should show up as planned capital over time, not emergency requests triggered by failure.

Fifth, run tabletop exercises for likely failure scenarios. The goal is not to predict every event. It is to make sure the team knows the runbook steps before the pressure is real.

That combination of inventory, calendar, spares, documentation, reserve funding, and rehearsal is what transforms lifecycle planning from a reactive task into an operating model.

What success looks like in practice

The episode closes the loop with an example from a multi-tenant lab building that had already implemented these habits. When a lab access controller began failing intermittently, the team did not have to improvise. They had a documented end-of-life calendar. They had a small spare warehouse. They had tested equipment ready.

The response was controlled: pull the verified spare, replace the failing controller during a scheduled low-occupancy window, and push a firmware rollback across the rest of the fleet. Tenants experienced no interruption, and the larger capital planning happened in the next fiscal quarter instead of during a crisis.

That example captures the real value of lifecycle planning. It is not just about replacing equipment before a date on a spreadsheet. It is about preserving reliability, avoiding avoidable disruptions, and giving teams room to make better business decisions under normal conditions instead of emergency pressure.

Five actions building teams should take now

If there is one part of the episode to carry into the next planning cycle, it is this five-part checklist:

• Build and maintain an asset inventory that includes end-of-life dates.
• Create a lifecycle reserve budget.
• Standardize and test spare kits for mission-critical systems.
• Require handover documentation that includes support windows and firmware baselines.
• Run tabletop scenarios and document runbooks.

These are not abstract best practices. They are practical controls that reduce surprise costs, tenant disruption, and operational stress.

The bigger business takeaway

The final thought in the episode is one of the strongest: planning is less about predicting every failure and more about creating repeatable habits. That matters because buildings do not suffer only when systems go down. They suffer when teams lack the structure to respond well.

For owners and operators, lifecycle planning is really about protecting continuity. For facilities and IT leaders, it is about making supportable decisions before risk compounds. For tenants, it shows up as reliability, trust, and fewer unpleasant surprises.

If this episode hits close to home, it is worth listening in full and using it as a prompt for your next planning cycle. The more intentional your lifecycle strategy becomes, the less likely your building technology portfolio is to dictate the agenda through failure.

And that is the real goal: fewer emergencies, better timing, stronger coordination, and systems that stay built to last, wired with intention, and secured for the real world.