Your portfolio keeps evolving. Your platform should too.
Your BMS does its job well, and it will keep doing it. What it was never built to do is span the other vendors in your portfolio — so every system you add arrives as its own integration project, on the vendor's schedule. CMS Buildings is the layer above: open and governed, started wherever the need is greatest, adding capability in whatever direction your portfolio grows. Governed and tested at every step.
The lock-in isn't the protocol. It's everything above it.
Your BMS speaks an open protocol and probably exposes an API. But the data model, the engineering tool, and the change process are the vendor's — so reaching across two vendors, or reshaping a workflow, still means a bespoke project on someone else's schedule. While that project waits, teams paper over the gap with spreadsheets and one-off scripts no one governs.
- Open protocol, vendor data model: every integration re-derives the same semantics
- Every cross-vendor link is a bespoke connector, hand-built and hand-maintained
- Ungoverned shadow IT grows to fill the gaps while the project waits
- Key-person risk: the workarounds live in one integrator's head
CMS Buildings doesn't replace what's underneath — it adds the layer that was never standardized: governed composition across vendors, evolving and tested by you, with the BMS you already trust left in place. Governance still happens; it's built in and continuous instead of a manual re-do.
A system of record per vendor vs. one governed layer across them.
How CMS Buildings compares with the BMS and building software most portfolios run today — at the orchestration layer, where the two don't overlap.
| Dimension | BMS / building software today | CMS Buildings |
|---|---|---|
| Philosophy | Open at the wire, vendor-configured above it | Open, evolves continuously, governed at every step |
| Changing needs | Each cross-vendor integration is a bespoke, hand-built project | AI-assisted change, human-approved and audit-ready |
| Growth path | Buy another module — or another vendor | One platform: operations → connect → beyond |
| Compliance model | An audit trail per system, in each vendor's format | Governance by construction — compliance in the architecture |
| Implementation | Months to years, dedicated integrator | Live in months, then evolves from there |
| Ownership | Vendor license — stops when you stop paying | Portable artifacts you own — your team can keep developing it |
| AI integration | Little to none | AI-native: Azi assistant + governed MCP for any model |
| Interface | A separate engineering tool per vendor, training-heavy | Familiar, guided interfaces for everyday work |
Start narrow. Grow into the platform.
You don't need everything on day one — you need to solve today's problem and know the platform won't box you in tomorrow. CMS Buildings lands on your highest-pain workflow and expands from there, without a re-platform.
Start where the pain is
Land with Operations alongside your existing BMS — value in months, not a multi-year rip-and-replace.
Your config becomes the template
The first governed configuration becomes a proven blueprint that accelerates every next workflow and every next site.
Expand without re-platforming
Connect, then energy management, tenant experience, and beyond — the same governed architecture grows with you instead of forcing the next purchase.
What a closed platform costs your portfolio.
- ~40%
- Of global energy use runs through buildings you can't fully see into
- Dozens
- Of siloed, single-vendor systems in a typical portfolio
- Months–Years
- To integrate a new system with a closed BMS
- Ongoing
- Integrator fees to maintain point solutions that don't evolve
See what an open building platform looks like.
We'll start with your highest-pain workflow and show how CMS Buildings grows from there.