Vendor-neutral building automation

The Real Cost of a Locked-In Building Management System

Nobody signs a contract intending to be locked in. It happens gradually.

A proprietary driver here because it was quicker. An undocumented point-naming convention there because the programme was tight. Graphics saved in a format only one contractor can open. A licence registered to the integrator rather than the building owner. Individually, each is a small compromise made for a good reason at the time. Together they mean that five years later, changing supplier costs more than living with the one you have.

The ownership question

Who holds the licences, source files, credentials and data that keep your building changeable?

Where Lock-In Actually Comes From

1

Licences held in the wrong name

If your Niagara or supervisory licences are registered to your integrator rather than to you, you do not own your building's control system in any meaningful sense. This is the single most common form of lock-in and the easiest to avoid - ask at tender stage, and require it in the contract.

2

Proprietary drivers and protocols

Manufacturer-specific protocols mean any future integration has to go through that manufacturer, at their price and on their timeline. Sometimes there is a genuine technical reason. Frequently there is not, and an open BACnet or Modbus interface was available for the same money.

3

Undocumented point naming

A point list nobody can interpret is a barrier to every future project - analytics, cloud integration, retro-commissioning, even routine maintenance. The knowledge lives in one engineer's head, and that engineer works for your contractor.

4

Compiled-only graphics

If you have the running graphics but not the source files, every change goes back to the original contractor. Over a ten-year building life that is a substantial and entirely avoidable revenue stream for someone else.

5

Credentials you do not hold

It is surprisingly common for a building owner to have no administrator account on their own system. Everything routine works fine until the day it does not.

6

Undocumented modifications

Changes made over years without a change log mean nobody - including the incumbent - fully understands the system. That uncertainty is itself a switching cost, because any new contractor has to price the risk of what they cannot see.

What It Costs You

  • Pricing power sits with the incumbent at every renewal and every variation, because both sides know what switching would cost.
  • Data you cannot extract, so analytics, ESG reporting and energy management projects stall before they start.
  • Stranded capital at refurbishment, when a system that should have been extended has to be replaced instead.
  • Delay, because integration work that should take days takes months while commercial terms are negotiated.
  • Compounding rework, as each new contractor works around what they cannot understand rather than correcting it.

None of this appears as a line item. It appears as a general sense that the building is expensive to run and difficult to change, which is exactly why it persists for years without being addressed.

What Open Actually Means - and What It Does Not

We should be honest about the limits. Open does not mean every component is interchangeable. Controllers are manufacturer-specific. Some equipment genuinely only speaks its own protocol. Any integrator who tells you otherwise is selling you something.

What open does mean is this: the interfaces between components are published and standard, the data is described in a schema anyone can read, and everything created on your project is handed to you in a form you can use without us. The lock-in that matters is not hardware. It is knowledge and access. Those we hand over completely.

Our Handover Standard

This is contractual on every project we deliver.

  • All software licences registered in the client's name from purchase, not transferred later
  • Administrator credentials issued to the client at handover
  • Station backups and configuration files in native format
  • Source graphics files, editable
  • As-built drawings, panel schedules and network diagrams
  • Points schedule, naming convention document and tag dictionary
  • Signed point-to-point and functional test records
  • Complete change log for any work carried out post-handover

Ten Questions to Ask Your BMS Contractor Before You Sign

Print this. Take it to your next tender interview. The answers will tell you more than the technical submission.

  1. 1.In whose name will the software licences be registered?
  2. 2.Will we receive administrator credentials at handover, or will you retain sole admin access?
  3. 3.Do we receive editable source graphics files, or only the compiled output?
  4. 4.Which parts of this system use proprietary protocols, and what is the open alternative?
  5. 5.Will you provide a written point-naming convention and tag dictionary?
  6. 6.If we appoint a different contractor in three years, what specifically would they be unable to do?
  7. 7.Can we export our own historical data, in bulk, in an open format, without your involvement?
  8. 8.What exactly is in the handover pack? Please list it in the contract.
  9. 9.Who owns any custom logic, drivers or applications written for this project?
  10. 10.If we integrate a third-party analytics platform later, what will that cost and what will it require from you?

A contractor who answers all ten comfortably is one you can work with for a decade. A contractor who gets uncomfortable around questions six and ten is telling you something important.

Tell us about the building.

Send us the specification, the point list, or just a description of what is not working. You will get a reply from an engineer within one working day.