Cloud BMS and Building Management as a Service

Ask a controls vendor what cloud BMS means and you will get an answer about dashboards, portfolio views, mobile access and analytics. Ask a facilities manager what they heard, and quite often the answer is that the building management system now lives in the cloud, which would mean the chillers stop sequencing when the fibre is cut. Those two understandings are very far apart, and the gap between them is where bad procurement decisions get made. The useful conversation about cloud BMS is not whether cloud is good or bad. It is a conversation about which layer of a building control system is a candidate for the cloud at all, and what you are accepting in return when you move that layer off site.

The message up front: real-time control loops stay in the field controllers on site, always, and they must keep running with no internet connection at all. Supervision, trending, analytics, reporting, alarm distribution and remote access are the layers that genuinely move to the cloud, and for multi-site portfolios that move is usually worth making. The two hard parts are not technical delivery, they are security exposure of an operational technology network and the slow loss of in-house understanding when operation is outsourced.

1. The layer split: the only framing that makes this clear

Before any discussion of vendors or service models, the architecture has to be separated into layers, because the cloud question has a completely different answer at each one. A building control system, whatever the badge on the front end, is three broad tiers stacked on top of each other.

The field layer is the sensors, actuators, valves, dampers, variable speed drives and the wiring between them. Physical, on site, not a candidate for anything remote.

The control layer is the programmable controllers running the actual sequences: the air handling unit control loop, the chiller sequencing logic, the terminal unit control, the interlocks and the safeties. This layer executes in real time, in milliseconds to seconds, and it holds the logic that keeps the building safe and comfortable. It must be autonomous. A controller that stops controlling because a wide area network link dropped is a design defect, not a trade-off.

The supervisory layer is everything above the controllers: graphics, schedules at the campus level, trend historians, alarm management and distribution, reporting, energy analytics, fault detection, user management and integration with other enterprise systems. This layer is not time critical in the control sense. If it is unavailable for an hour, the building still runs. That single property is what makes it a legitimate cloud candidate.

So when a vendor says cloud BMS, what is almost always meant is a cloud-hosted supervisory layer talking to on-premise controllers over a network connection. That is a reasonable and often good architecture. What is not on offer, from anybody credible, is cloud-executed control logic. For the foundation of how these tiers fit together, see the complete guide to building management systems and the building automation systems explainer.

2. What stays local and what moves to the cloud

This table is the one I put in front of a client early, because it settles most of the argument before it starts. The left column is non-negotiable on site. The right column is where the cloud case is genuinely strong.

Read the pattern: everything in the top half is deterministic, time critical or safety related. Everything in the bottom half is about aggregation, storage, analysis and human access. That boundary is stable across vendors and I have not yet seen a credible reason to move it.

3. The three service models, and what you are actually buying

Cloud BMS is sold in at least three quite different shapes, and they are frequently discussed as if they were the same purchase. They are not. They differ in who owns the head-end, whether your existing BMS survives, and whether you are buying software or buying an operations team.

Hosted head-end. The supervisory software you would otherwise have installed on a server in the basement runs instead in a data centre or a vendor cloud. Same product, same graphics, same database schema in many cases, different hosting. You still operate the building yourself. This is a hosting decision rather than an operating model change, and it is the smallest step.

Cloud analytics overlay. Your existing BMS stays exactly as it is and keeps operating the building. A gateway reads point data out of it and pushes it to a cloud analytics platform that does trending, fault detection, energy analysis and reporting on top. Crucially, the overlay is usually read-only or read-mostly, which makes it the lowest-risk option and the easiest to remove. This is where most sites with a serviceable existing BMS should start. The analytics side of this is covered properly in the BMS energy optimisation and FDD pillar and the smart buildings and building analytics pillar.

Fully managed BMaaS. The vendor provides the cloud supervisory platform and also operates it, typically from a remote operations centre staffed to watch alarms, triage them, adjust setpoints and schedules within an agreed envelope, and dispatch site attendance through your maintenance provider. You are buying an outcome and a team, not a licence. This is the largest step and the one with the most consequences, both good and bad.

The recommendation I make most often is the middle column, and not because it is fashionable. It is the option that delivers the majority of the visible benefit, portfolio visibility, trending, fault detection and alarm distribution, while keeping control authority and exit optionality entirely in the client's hands. If it proves its value over a year, the case for going further is evidence-based rather than aspirational. For how to evaluate the platforms themselves, the BMS software and platform evaluation pillar is the companion piece.

4. What a remote monitoring service actually does day to day

The brochure for a remote operations centre describes continuous expert oversight. The reality, which is still valuable, is narrower and worth stating plainly so expectations are set correctly. A competent remote monitoring service does roughly the following:

• Alarm triage and suppression. Watching the incoming alarm stream, discarding the noise, identifying the handful that matter, and stopping the nuisance alarms that trained your own team to ignore the system. On most sites this alone is worth the fee, because alarm hygiene is almost universally poor.
• Setpoint and schedule adjustment. Correcting drift, aligning schedules to actual occupancy, tightening deadbands, fixing the override somebody left in place after a complaint eighteen months ago.
• Fault detection review. Reading the FDD output, separating genuine faults from modelling artefacts, and converting real faults into work requests with enough detail for a technician to act.
• Trend and energy review. Periodic review of consumption against baseline and against comparable sites, flagging regressions. This is the reporting most in-house teams intend to do and never find time for.
• Escalation and dispatch. Routing what needs a body on site to the maintenance provider, with the diagnostic context attached instead of a bare alarm code.
• Change log and audit. Recording who changed what and why, which is the artefact almost no self-operated site maintains reliably.

And here is the equally important half of the honest picture: what it cannot do without somebody on site.

There is a further subtlety worth raising during negotiation. A remote service is only as good as the point data it receives, and the data quality of a typical existing BMS is not what the tender assumes: mislabelled points, sensors that were never commissioned properly, virtual points nobody can explain, and trends sampled too coarsely to show anything useful. Budget for a point survey and a data quality remediation phase, or the first six months of the service will be spent discovering that the inputs are unreliable. This overlaps with the servicing discipline set out in the BMS maintenance and lifecycle pillar.

5. Multi-site portfolios: the strongest case for cloud

If there is one scenario where I would argue positively for cloud supervision rather than merely tolerate it, it is the multi-site portfolio. The economics and the operating pain both point the same way.

Consider the on-premise alternative at scale. Forty sites means forty supervisory servers or workstations, forty operating systems to patch, forty licence renewals on different dates, forty sets of local user accounts, forty historians that nobody can query together, and forty graphics packages built by whichever contractor happened to win that site. Getting a single consistent answer to a simple question, which of my sites has the worst out-of-hours consumption, becomes a manual data-gathering exercise that takes a week and is out of date when it finishes.

Cloud supervision collapses that. One platform, one identity model, one historian, one set of graphics conventions, one patch cycle handled by somebody else, and cross-site comparison available by default rather than as a project. The benefits that are genuinely hard to get any other way:

• Like-for-like benchmarking. Normalised comparison across sites surfaces the outliers immediately. The worst-performing site in a portfolio is usually a surprise to the people running it.
• Standardised alarm and escalation policy. One rule set applied everywhere, instead of per-site conventions that depend on who commissioned it.
• Consistent reporting. Board and sustainability reporting from one source rather than reconciled spreadsheets.
• Scarce skill leverage. One good controls engineer can cover a portfolio from a desk. They cannot cover it by driving between sites.
• Small-site coverage. Sites too small to justify their own head-end get real supervision for the first time, which is often where the easiest savings sit.

The structural pattern here is the same one that governs multi-site maintenance systems, and it is worth borrowing the thinking wholesale: see the multi-site CAFM architecture pillar for how central standardisation and local autonomy get balanced. The deployment argument for maintenance software specifically, which rhymes with this one but is not the same decision, is in cloud-based CMMS versus on-premise.

For a single building, by contrast, the arithmetic is much weaker. One server, one licence, one site, and a local workstation that a technician can use when the network is out. The portfolio effect is the value driver, and without a portfolio most of the value is not there.

6. Connectivity requirements and behaviour during an outage

The bandwidth requirement for cloud supervision is modest and this is a point worth making early, because clients often assume it is heavy. Supervisory traffic is small samples of numeric data at intervals measured in minutes, not video. A typical site's steady-state trend and alarm traffic is comfortably within a modest business broadband connection. What matters far more than raw bandwidth is reliability, predictability and graceful behaviour when the link fails.

The connectivity design questions I would insist on answering in writing before signing:

• Is the data path outbound-initiated? A gateway that opens an outbound connection to the cloud is meaningfully safer than a cloud platform reaching inbound through a hole in the firewall. Insist on outbound.
• How long does the gateway buffer during an outage? Hours, days, or nothing. Ask for the figure in the number of points and the sample interval you actually have, not a generic claim.
• Does it backfill on reconnection? A gap in the historian during the exact period something went wrong is worse than useless, because it is invisible in reports.
• What happens to alarms during the outage? If the cloud distributes alarms and the link is down, nobody is being notified. Local annunciation and a secondary path matter.
• Is there a local operator interface? When the link is down, a technician on site still needs to see and act. A local workstation or panel touchscreen is a resilience requirement, not a luxury.
• Is a secondary link justified? For critical sites, a cellular failover for the gateway is inexpensive relative to the value of continuous supervision. For a small office it is over-engineering.

The behaviour to specify and then test, at handover, is simple: pull the cable, confirm the building continues to operate normally and locally, confirm alarms still annunciate somewhere a human will see them, restore the cable, and confirm the historian backfills with no gap. I have seen that test fail on delivered systems often enough to insist it is written into the acceptance criteria rather than assumed.

7. OT security: the serious part

This is the section that deserves the most attention and usually gets the least. Connecting a building controls network to the internet changes its risk profile fundamentally, and a controls network is not an IT network. It runs unpatched embedded devices with ten to twenty year lifecycles, protocols designed in an era when network access implied physical access, default credentials that were never changed, and firmware that in many cases can no longer be updated because the manufacturer has moved on. That estate was tolerable when it was isolated. It is a genuine liability once it is reachable.

What actually goes wrong, in the order I see it:

• Flat networks. The controls VLAN turns out to share a broadcast domain with the guest wifi, the CCTV, or the corporate network, because it was expedient during construction. Segmentation is the single highest-value control and the most frequently absent.
• Inbound port forwarding. Somebody exposed the supervisory server to the internet on a forwarded port so a contractor could get in. These are discoverable by anybody scanning, and internet-exposed building controllers are a well-documented category of finding.
• Shared and default credentials. One engineering account used by every contractor who has ever touched the site, with a password that has not changed since commissioning and is written inside the panel door.
• Unmanaged vendor remote access. Permanent, unmonitored tunnels for maintenance convenience, with no session recording and no idea who is actually on the other end.
• No asset inventory. Nobody can say how many controllers exist, what firmware they run, or what is reachable from where. You cannot secure an estate you cannot enumerate.
• No monitoring of the OT segment. The corporate network has logging and detection. The controls network typically has none, so an intrusion there is invisible.

The controls I would treat as minimum conditions for any cloud connection: proper network segmentation with a controlled boundary between the controls network and everything else; outbound-only data flow from a hardened gateway with no inbound port forwarding at all; individual named accounts with multi-factor authentication for every human, contractors included; brokered, time-limited, recorded vendor remote access rather than standing tunnels; a maintained inventory of controllers and firmware versions; and logging from the OT segment landing somewhere that is actually reviewed. None of that is exotic. The reference frameworks worth reading are the operational technology security guidance from NIST and the industrial automation security standards work at the International Society of Automation , whose zone and conduit model maps neatly onto building controls even though it came from process industry.

8. Data ownership and export when the contract ends

Ask the exit question at the start of the procurement, not at the end of the term, because the answer is much easier to negotiate before you have signed. Cloud supervision means your operational history lives in somebody else's database, and the contractual position on that history is frequently vague in a way that favours the vendor.

The terms I would want explicit, in the contract rather than the brochure:

• Ownership stated plainly. The point data, trends, alarm history and configuration are the client's data, and the vendor is a processor of it. Say so in a clause.
• Export format and completeness. Full historical trend data in an open, documented format with point metadata attached, not a set of PDF reports and not a proprietary archive that only the vendor's product can open. Specify the format.
• Export on demand during the term. Not only at termination. A client who can only get their data on the way out has no leverage and no ability to run their own analysis.
• Configuration and logic. Graphics, point lists, alarm rules, schedules, analytics rule definitions and any controller logic modified during the term, handed over in editable form. This is the part most often withheld.
• Post-termination window. A defined period of continued access for migration, and a defined deletion commitment afterwards.
• Test the export once, early. Exercise the export clause in the first year while the relationship is good. An untested export clause is a promise, not a capability.

There is a related lock-in that is easy to miss. If the cloud platform holds analytics rules and derived logic that the on-site controllers now depend on for correct operation, then leaving the platform is not a data migration, it is a re-engineering project. Keep the dependency asymmetric: the cloud may read everything and write within a narrow, documented envelope, but the building must remain fully operable on controller logic alone.

9. Capex to subscription: what the commercial shift really changes

No figures here, because they vary too much by market and scope to be worth anything. But the shape of the change is consistent and it has consequences beyond accounting treatment.

The traditional model is capital: a head-end server, perpetual licences, a graphics build, all funded once at project time and then carried with a modest annual support line. The failure mode of that model is well known, the head-end quietly ages out, the operating system falls out of support, the graphics never get updated, and a decade later there is a replacement project nobody budgeted for.

The subscription model removes the large upfront outlay and converts it to an operating line that includes hosting, updates and support. What genuinely improves: the platform stays current instead of decaying, small sites become affordable to supervise, and the true ongoing cost of running the system becomes visible rather than hidden in deferred maintenance. What genuinely gets worse or riskier:

• The cost never stops. Over a long holding period, an operating subscription can exceed what a capital purchase plus support would have cost, and the comparison is rarely modelled honestly in the business case. Model it over the asset life, not the first term.
• Price escalation sits with the vendor. Negotiate the uplift mechanism and a cap at the outset. A subscription you cannot leave is a subscription that can be repriced.
• Budget politics change. Capital is often easier to get approved than a permanent operating commitment. That is an internal constraint that will shape what is actually achievable.
• Per-point or per-site metering. Understand exactly what the unit of charge is. Growth in points or sites can move the cost non-linearly in ways the initial quote does not show.
• Bundled labour is hard to unbundle. In a managed service, software and operations labour arrive as one number. Ask for them separated so you can see what you would be paying if you brought operation back in house.

The energy and consumption reporting side of the business case is often where the justification lives, and it should be built on measured baselines rather than vendor savings claims. The energy management systems pillar covers how to establish those baselines.

10. The loss-of-capability risk nobody prices

This is the consequence of fully managed BMaaS that I raise most insistently, because it is slow, invisible in year one, and very expensive to reverse. When an organisation outsources the operation of its building controls, it also, without deciding to, outsources its understanding of its own buildings.

The sequence is predictable. In year one the in-house engineer works alongside the service and everything is fine. In year two that engineer leaves and is not replaced, because the service is covering the work. In year three nobody in the organisation can read the control sequences, nobody knows why the east wing air handling unit has a permanent override, and nobody can challenge a vendor recommendation on technical grounds. By year four the organisation is a pure price-taker: unable to evaluate the service's performance, unable to specify a replacement, and unable to bring operation back in house without a substantial rebuild of knowledge. The switching cost that was low at signature has become high, and not because of any contract clause.

This is not an argument against managed services. For an organisation that never had controls capability and never will, a good managed service is strictly better than the alternative, which is an unsupervised BMS slowly drifting into a state where every room is fought over manually. It is an argument for deliberately retaining a defined minimum of client-side capability. What I would insist on keeping:

• One named technical owner inside the organisation who can read a sequence of operation, interrogate the trends directly, and hold the service to account. One person, but a real one, with time allocated.
• Independent read access to the platform and to the raw data, not only to the vendor's reports. You cannot verify performance through the reporting of the party being measured.
• Current documentation held by you. Sequences of operation, point schedules, as-built drawings, network diagrams and controller inventories, maintained as a contractual deliverable and stored on your side.
• A change log you can see. Every setpoint, schedule and logic change made remotely, visible and reviewable. Changes you cannot see are changes you cannot learn from.
• An annual independent review. Someone with no stake in the service looking at the data and the performance once a year. Inexpensive, and the only reliable check.
• A written reversibility plan. What it would take, concretely, to operate this portfolio without the service. If nobody can answer that, the dependency is deeper than the contract suggests.

11. When on-premise supervision is still the right answer

The cloud case is strong in specific circumstances and weak in others, and a consultant who recommends it universally is not thinking. The situations where I would keep supervision on site:

• A single building with a competent in-house team. The portfolio effect is the main value driver. With one site and people who know it, a local head-end plus a modest analytics add-on is cheaper, simpler and fully within your control.
• High-security and sovereign environments. Defence, certain government estates, secure research facilities, and sites where any external connectivity is a policy breach rather than a risk to be managed. The answer here is a hard no, and it is the correct answer.
• Critical facilities where the controls network must stay air-gapped. Hospital critical areas, data centre mechanical plant, pharmaceutical manufacturing under validation. Where a validated or life-critical configuration cannot tolerate an external change path, keep it closed.
• Poor or expensive connectivity. Remote sites with unreliable links spend more time degraded than supervised. Local supervision with periodic data collection is the pragmatic design.
• Regulatory data residency constraints that the vendor cannot satisfy in your jurisdiction. Verify where the data physically sits, and where support staff access it from, before assuming this is solved.
• A legacy estate too fragmented to integrate economically. Several generations of proprietary controllers with no open protocol support can cost more to gateway than the visibility is worth. Sometimes the right first project is controller replacement, not cloud.
• An organisation with no capacity to act on the output. Cloud analytics generate findings. Findings that nobody has the labour to fix are a subscription to a list of known problems. If there is no execution capacity, fix that first.

A hybrid is often the honest answer and it is under-proposed because it suits nobody's sales motion: keep full supervisory capability on site, and add a cloud layer for exactly the functions where remoteness is the point, which is portfolio reporting, analytics and alarm distribution. You get the cross-site view without moving control authority or accepting write access from outside. For a sizeable estate with real in-house capability, that is frequently the best architecture available.

The idea to walk away with

Cloud BMS is not a deployment choice about a building management system. It is a decision about one layer of a three-layer stack. Control stays on site and stays autonomous, because that is a physical and safety requirement and not a preference. Supervision, history, analytics, alarming and access are the layers where the cloud earns its place, and they earn it most decisively across a portfolio of sites where the alternative is a server room per building and no way to compare anything.

The two things that decide whether the move goes well are not in the vendor's product. The first is whether the security work on your own controls network gets funded properly, because connecting an unpatched, flat, shared-credential OT estate to the internet is the real risk in this project. The second is whether the organisation deliberately keeps enough technical understanding of its own buildings to hold the service to account. Get those two right, start with the read-mostly analytics overlay rather than the full managed service, and test the outage behaviour and the data export before you need them.

Final thoughts

The most useful question in any cloud BMS conversation is the simplest one: what specifically are you unable to see or do today that this would let you see or do. If the answer is that nobody can tell which of thirty sites is wasting energy out of hours, or that alarms reach nobody after six o'clock, or that no site smaller than a certain size has any supervision at all, then cloud supervision addresses a real problem and the business case will hold up. If the answer is that the current system is old and cloud sounds modern, the project will deliver a subscription and a nicer set of graphics, and the underlying problems will still be there.

Start with the layer split, insist on autonomous control, prefer the read-mostly overlay for a first step, fund the network segmentation, write the export clause and exercise it, and keep one person in your own organisation who genuinely understands how the buildings work. That combination gets the benefit of cloud supervision without the two failure modes that cause the regret, which are an exposed controls network and an organisation that no longer understands its own estate.

Related reading: Building management systems: a complete guide, BMS software and platforms: how to evaluate, BMS cybersecurity for connected buildings, BMS energy optimisation, FDD and analytics, Multi-site CAFM architecture, Cloud-based CMMS vs on-premise.