Show Notes
Why Elevator Systems Now Belong in the Technology Conversation
Modern elevators are no longer just mechanical conveyance systems tucked behind a maintenance contract. In this episode of Built, Wired, and Secured, Alex Morgan talks with Michael Harrington and James Rogers about what changes when elevator controls, remote diagnostics, and predictive maintenance tools become part of the building network. Their message is straightforward: the benefits are real, but so are the new dependencies, and property teams need to understand both.
The discussion opens with a vivid scenario: a midsized office tower, morning traffic, a packed event on the ninth floor, and a vendor-pushed update that trips a control module. Suddenly, elevators stop responding. Deliveries stack up. Tenant complaints escalate. The property team spends hours managing fallout instead of normal operations. That framing sets the tone for the episode: elevator outages are not just maintenance problems. They are operational, reputational, and business continuity events.
What Actually Breaks When Elevators Go Down
One of the strongest themes in the conversation is that elevator disruption ripples across the building faster than many teams realize. Michael points out that elevators touch tenant access, fire recall, deliveries, and general circulation. Once remote controls and cloud telemetry are introduced, the system also inherits network-related failure modes that older isolated systems did not have.
- Tenant movement slows or stops
- Deliveries and service access are delayed
- Meetings and daily schedules are disrupted
- Fire recall and connected building functions become part of the risk picture
- Property teams absorb complaints immediately
That distinction matters because a connected elevator platform can fail in ways that are not obvious to traditional facilities teams. A control issue may no longer be limited to a local component. It could involve switches, uplinks, VLANs, firewalls, vendor gateways, or cloud dependencies. As the guests explain, one failed uplink can reduce visibility across multiple cabs within minutes.
Visibility Is Not the Same as Readiness
James makes an important operational point early in the episode: getting more data does not automatically make a building more resilient. Fault codes, health alerts, and trend data are useful only when there is a disciplined maintenance process behind them. Without scheduling, ownership, and follow-through, alerts simply become noise.
That practical distinction separates technology-enabled maintenance from technology clutter. The upside of connectivity is earlier detection and potentially faster intervention. The downside is that teams can mistake dashboard visibility for preparedness. In reality, connected systems demand more process maturity, not less.
The conversation draws a clear contrast between older and newer operating models. Historically, elevator environments relied more on local relays, direct technician access, and mechanical safeties. Today, controllers may communicate over Ethernet, telemetry may feed cloud portals, and analytics may recommend predictive maintenance work. Those features can improve service outcomes, but only when the building team has the cadence and discipline to act on them.
The Operational Shift: From Periodic Checks to Continuous Change
Another insight from the episode is that connectivity changes the maintenance calendar. Instead of relying mostly on annual checks and reactive service calls, teams now face a continuous flow of firmware advisories and health alerts. That means the job is no longer just maintenance. It is also lifecycle management.
- Firmware versions need to be tracked
- Update windows need to be scheduled intentionally
- Alerts need named owners during business hours
- Facilities, IT, and vendors need shared change control expectations
James warns that without a real change control cadence, teams end up patching reactively, often during business hours, when the business impact is highest. Michael reinforces this by asking the core design question several times in different ways: what breaks if this goes down?
Real-World Examples of Risk and Resilience
The episode stays grounded by using practical examples rather than abstract theory. Michael shares a case where a controller firmware mismatch after a vendor push disabled elevator dispatch for three elevators across two buildings. Downtime lasted about six hours while the team waited for a vendor-only reboot. The result was immediate and measurable: roughly 40 tenant complaints, missed client meetings, and lost billable time. The takeaway is that elevator failure becomes a business issue the moment tenants feel it.
James offers the counterexample that shows why connectivity is still valuable. In his case, remote telemetry identified bearing wear on a service car early enough for the team to schedule replacement work during off-peak hours. That avoided a harder failure that could have taken 12 to 24 hours to resolve. The message is balanced: integration can absolutely improve resilience, but only when the organization has the process maturity to respond correctly.
Isolation Versus Integration Is the Wrong Starting Point
Rather than treating isolation and integration as ideological choices, the guests recommend a design approach rooted in business impact. Start by mapping the functions that depend on elevator controls, including fire recall, card access, interlocks, and tenant circulation. Then rank those functions by impact. Only after that should teams make architecture decisions.
From there, the conversation gets more tactical. The guests recommend segmented network design, management VLANs, strict access control lists, redundant uplinks, and hardened gateways that preserve telemetry while limiting exposure of critical commands. In other words, do not default to full exposure for convenience or to total isolation out of fear. Design specifically for the highest-impact failure modes.
Who Gets the Keys During an Outage?
The discussion around vendor remote access is especially useful for property and operations leaders. Michael argues that buildings should not be dependent on a vendor as the only path to recovery during critical hours. If a vendor support queue is backed up at 9:00 a.m., the building pays the price. He wants local teams to be able to initiate safe modes such as recall to lobby or controlled manual operation to reduce tenant impact while vendor technicians diagnose remotely.
James agrees with the concern but adds a realistic constraint: manufacturers often restrict certain control actions for certification reasons. His recommendation is not unrestricted access. It is a negotiated split of responsibilities. Define what the on-site team can do locally, define what remains vendor-only, and practice the handoff in tabletop drills.
The episode provides a helpful example of what a good handoff looks like. In the successful scenario, the on-site team initiated local safe mode and posted status to the operations portal, while the vendor provided remote diagnostics and coordinated a limited maintenance window within two hours. In the failed scenario, a vendor pushed updates across 15 controllers on a Monday morning without staging. One variant failed, a vendor-only reboot was required, and support delay stretched the outage to five hours. The lesson was blunt: stage updates on a test bank, and do not assume one global change window works for every site.
Procurement Questions Worth Asking Out Loud
The episode closes with direct language property owners can use in procurement and design reviews. Those questions are valuable because they force vendors to reveal whether they support disciplined operations or expect the building to adapt to their process.
- Provide a network diagram showing control plane separation, redundant uplinks, and proposed ACLs
- If the system fails, what exact local actions can our staff take without a vendor login?
- Describe your firmware change control and rollback process, including a test staging plan
- Deliver telemetry and fault exports to our CMMS and define alert ownership during business hours
These are not abstract technical asks. They are ownership questions. They clarify architecture, local authority, rollback readiness, and day-to-day accountability.
Final Takeaway
The central lesson from this conversation is not to reject connectivity. It is to make connectivity resilient. Elevators now sit at the intersection of building operations, tenant experience, maintenance strategy, and network risk. The right answer is disciplined design, clear role definition, controlled change, and practiced response.
If you are evaluating an elevator modernization project, reviewing vendor access, or planning a connected building environment, download the one-page Elevator Systems Operational Checklist at gds-technology.com/bws-elevators and use it in your next procurement or design review. This episode is a strong reminder that in a networked building, reliability is not accidental. It is designed, maintained, and practiced.
Elevators in the Networked Building: What Property Teams Need to Own Before an Outage Forces the Issue
Modern building conversations often focus on visible technology investments: access control, tenant experience platforms, smart sensors, and cloud-connected building systems. Elevators do not always get included in that discussion until something goes wrong. In this episode of Built, Wired, and Secured, Alex Morgan speaks with Michael Harrington and James Rogers about why that needs to change.
Their discussion centers on a reality that many property teams are now facing: elevator systems are no longer isolated mechanical assets. They are increasingly connected, software-driven platforms that intersect with network design, maintenance planning, vendor access, and tenant expectations. That connectivity can deliver better visibility and better service outcomes, but it also introduces new operational dependencies that many buildings are not fully prepared to manage.
Why Elevator Outages Hit Harder Than Teams Expect
The episode opens with a practical scenario that feels uncomfortably realistic: a midsized office tower, three elevators, a heavy morning traffic period, and a vendor-pushed update that trips a control module. The elevators stop responding. Deliveries back up. Tenant complaints start immediately. The property team spends the next four hours in reactive mode.
That story illustrates the core point of the episode. Elevator downtime is not just a facilities inconvenience. It is an operational disruption that directly affects tenant experience, building reputation, and in some cases business productivity. Michael frames it clearly by asking what breaks when the elevators go down. The answer is broader than many people assume.
- Tenant movement and access are disrupted
- Deliveries and service activity slow down or stop
- Meetings are missed and schedules slide
- Connected functions such as fire recall become part of the risk picture
- Property staff are pulled into complaint management and escalation response
In a connected building, that disruption can begin with something other than the elevator hardware itself. It may start with firmware, network segmentation, a failed uplink, a vendor gateway, or a change pushed without proper staging. That is why elevator modernization should not be treated as a closed maintenance matter. It is a cross-functional operational issue.
Connected Does Not Automatically Mean Resilient
One of the most useful points James makes in the episode is that visibility is not the same as readiness. This is an important distinction for any property team evaluating connected systems. Cloud telemetry, fault codes, and trend data can create the impression that a building has greater control. In practice, those tools only improve outcomes when someone is responsible for reviewing them, acting on them, and integrating them into a disciplined maintenance process.
Without that discipline, alerts simply become background noise. Dashboards fill with data, but the organization does not become more reliable. In fact, it may become more complacent because the presence of monitoring is mistaken for actual preparedness.
That is why the guests repeatedly connect technical capability back to operational ownership. Connected systems can absolutely create value. But they do not reduce the need for process. They increase it.
The Real Shift: Maintenance Becomes Lifecycle Management
Older elevator models were more isolated and more local in nature. As discussed in the episode, teams historically worked with local relays, direct technician access, and mechanical safeties. When issues happened, the response path was more contained.
Today, many elevator environments include Ethernet-connected controllers, cloud telemetry portals, analytics-driven recommendations, and vendor-managed software updates. That changes the maintenance model entirely. Instead of relying mainly on periodic inspections and reactive service calls, building teams may now face a continuous stream of health alerts, firmware advisories, and update considerations.
That means the operational calendar changes too. Maintenance is no longer just about lubrication, inspections, and replacement schedules. It also includes version control, planned maintenance windows, alert triage, and rollback readiness. If that governance is missing, building teams often end up patching reactively during business hours, which is exactly when outage impact is most visible.
For commercial real estate operators, that is the deeper lesson. The move to connected building systems is also a move toward software governance. If you integrate the technology but not the process, you inherit the risk without capturing the full benefit.
The Business Case for Connectivity Is Real
Importantly, this episode does not argue against integration. In fact, James gives a practical example of why connectivity can be valuable. Remote telemetry identified bearing wear on a service car early enough for the team to schedule a replacement during off-peak hours. That intervention prevented a much more disruptive failure that could have taken 12 to 24 hours to fix.
That example matters because it shows where smart building technology earns its keep. When the data is reliable, the ownership is clear, and the response process is mature, connected systems help teams avoid larger failures and preserve tenant uptime.
In other words, connectivity is not the problem. Unmanaged connectivity is the problem.
How Single Points of Failure Sneak In
Michael gives the counterexample: a controller firmware mismatch after a vendor push disabled elevator dispatch for three elevators across two buildings. Downtime lasted about six hours while the team waited for a vendor-only reboot. The outcome was tangible: dozens of tenant complaints, missed meetings, and lost billable time.
This story highlights a common issue in connected building environments. Teams often introduce digital capabilities without fully tracing the new single points of failure that come with them. A building may have modernized elevator controls and better remote insight, but if recovery depends entirely on a vendor queue, the building may still be fragile at the exact moment reliability matters most.
That is why the guests do not frame the decision as a simple choice between integration and isolation. Instead, they recommend starting with impact mapping.
A Better Decision Framework: Start With Impact, Then Design
Rather than asking whether elevator systems should be connected or isolated, the episode suggests a more useful question: what are the highest-impact functions tied to this system, and how do we reduce failure around them?
The recommended process is practical:
- Identify the functions that depend on elevator controls
- Include fire recall, card access, interlocks, tenant circulation, and other related workflows
- Rank those functions by business impact
- Design the network and management approach around the highest-impact failure scenarios
From there, the technical recommendations become more specific and more actionable. The guests call for management VLANs, strict ACLs, redundant uplinks, and hardened gateways that separate control traffic from the broader building network. The goal is not to deny visibility. It is to preserve visibility while reducing unnecessary exposure of critical commands.
This is the kind of tradeoff property teams should want from technology partners and vendors. Not a generic promise of smart building capability, but a design that reflects how the building actually operates when something goes wrong.
Vendor Remote Access Needs a Defined Operating Model
The conversation around vendor access is one of the strongest parts of the episode because it focuses on ownership rather than convenience. Michael makes the case that building teams should not be completely dependent on a vendor as the only path to recovery during critical hours. If support is delayed, the tenant experience suffers immediately.
He argues for local safe-mode capability so on-site staff can reduce the impact of an outage while vendor teams diagnose remotely. James adds an important reality check: manufacturers often restrict certain actions for certified reasons, so the answer is not unrestricted local control. The answer is a negotiated split of responsibilities.
That means documenting which local actions building staff can take, which actions remain vendor-only, and how the handoff works under time pressure. Just as importantly, it means practicing that sequence before the first real outage.
The worked example in the episode is simple and effective: on-site staff initiate local safe mode, post status into the operations portal, the vendor begins remote diagnostics, and both parties coordinate a limited maintenance window with a two-hour initial response expectation during business hours. That is not just a technical model. It is an operational agreement.
What to Ask in Procurement Meetings
The episode closes with language property owners can use directly with vendors. These questions are useful because they expose whether the vendor supports resilient operations or expects the property team to live on the vendor's schedule.
- Provide a network diagram that shows control plane separation, redundant uplinks, and proposed ACLs
- If the system fails, what exact local actions can our staff take without a vendor login?
- Describe your firmware change control and rollback process, including a test staging plan
- Deliver telemetry and fault exports to our CMMS and define alert ownership during business hours
Those questions bring accountability into the room. They force clarity on architecture, local authority, rollback readiness, and operating responsibility.
The Strategic Takeaway for Building Owners and Operators
The most important message from this conversation is not that connected elevator systems are inherently risky. It is that connected systems need operational ownership equal to their business importance. Elevators now affect tenant experience, maintenance planning, network design, and outage management in ways that can no longer be handled in separate silos.
For commercial real estate teams, the opportunity is clear. Treat elevator modernization as part of a broader operational resilience strategy. Design connectivity intentionally. Stage updates. Practice vendor handoffs. Build maintenance discipline around the data you are collecting. And keep asking the simplest question in the room: what breaks if this goes down?
If your team is preparing for an upgrade, reviewing a maintenance relationship, or evaluating how building systems are being integrated into your broader technology environment, this episode is worth a listen. You can also download the one-page Elevator Systems Operational Checklist at gds-technology.com/bws-elevators and bring it into your next procurement or design review. It is a practical next step for teams that want smarter buildings without giving up operational control.