BMS Service Contracts: OEM, Integrator or In-House

The question is usually framed as a price comparison. The manufacturer quotes one number, a local integrator quotes a smaller one, and the decision looks like a procurement exercise. It is not. A building management system service contract is the mechanism through which you either keep or lose control of the system's configuration, and the cost difference between the models is frequently smaller than the cost of the position you end up in. I have watched organisations save fifteen percent a year on a maintenance contract and then pay several years of that saving back in a single retrofit, because nobody could obtain the tool needed to edit a controller.

The message up front: there is no universally correct model. A single building with a modest system is usually better served by a competent local integrator; a multi-site portfolio with a common platform is usually better served by a framework with the manufacturer or one of its larger partners; and in-house capability is worth building only where you have enough estate to keep a specialist busy. But whichever you choose, the decision that matters is not the model, it is whether the contract gives you ownership of the programming, access to the engineering tool, and a defined, priced route out. Settle those three and most of the lock-in argument disappears.

1. What a BMS service contract actually buys

A building management system service contract usually bundles several quite different things under one annual figure, and buyers compare the figures without comparing the bundles. Before any model comparison is meaningful, separate what is in scope:

• Planned preventive attendance. Scheduled visits to check panels, batteries, controller health, communications, sensor calibration and a sample of points. This is the part most like conventional maintenance, and it is the part most often reduced to a visual inspection and a signature.
• Reactive call-out and fault rectification. Response to failures, with a stated response time, and usually a distinction between remote diagnosis and attendance on site. Whether labour and parts are included or charged separately is the single largest driver of apparent price difference between quotations.
• Software maintenance and version currency. Access to head-end software updates, security patches, and the right to run the current version. On some platforms this is a separate subscription without which the head end gradually falls out of support.
• Remote monitoring and connectivity. A connection into the system for diagnosis, alarm forwarding, or a supplier-hosted dashboard. This has security consequences that belong in the discussion from the start rather than as an afterthought, which is why it is worth reading alongside BMS cybersecurity for connected buildings.
• Engineering and change work. Modifications to sequences, graphics, setpoints, alarms, schedules and points. Sometimes a bundled allowance of hours, sometimes wholly excluded and quoted per task. This is where the commercial relationship really lives.
• Lifecycle and obsolescence advice. A view on what is approaching end of support, and a plan. Rarely contracted explicitly, and valuable when it is.

A quotation that does not separate these lines is not comparable with one that does. The first thing I would do with three BMS service quotations is rewrite all three onto a single sheet with these six rows, and ask each supplier to confirm which rows their number includes. The answers are usually illuminating and occasionally change the ranking entirely. The scope wording that supports this belongs in the same family as the clauses covered in BMS specification clauses.

2. The four delivery models

The market is usually described as a choice between "the manufacturer" and "a local firm", which collapses four genuinely different positions into two. The four are:

• Manufacturer direct. A service contract with the controls manufacturer's own service organisation. The four names that dominate the large commercial market are Johnson Controls, Siemens, Honeywell and Schneider Electric, compared at a platform level in the four-way BMS vendor comparison. Direct service means the party that wrote the firmware is the party holding your contract.
• Manufacturer-authorised partner. An independent company trading under a manufacturer's authorisation, with access to that manufacturer's tools, training, firmware and parts channel. Most installed controls in most markets are actually maintained this way rather than by the manufacturer directly. Quality varies enormously between partners of the same manufacturer, which is the fact that most undermines vendor-level comparison.
• Independent integrator. A controls company not aligned to one manufacturer, typically working across several platforms, often with strength in open-protocol and framework-based systems. Commercially the most flexible position and the most variable in depth.
• In-house. Your own employed controls engineer or team, usually supplemented by a call-off arrangement for specialist work and out-of-hours cover. Rare below a certain estate size and extremely effective above it.

The distinction between the first two matters more than buyers expect. When somebody asks whether the manufacturer is better value than a local integrator, they are often comparing a manufacturer-direct quotation with an authorised partner of the same manufacturer, which is not a platform question at all. It is a question about two service organisations with identical technical access.

3. What each model is genuinely good and bad at

The table below is editorial assessment, based on how these arrangements behave in practice rather than on any vendor's published material. It generalises, and the variance within each model is wide enough that a strong example of one will beat a weak example of another.

4. The lock-in mechanisms that actually bite

"Open system" is claimed by every controls manufacturer and means very little at the service-contract layer. A system can speak BACnet fluently, interoperate well, and still be practically impossible for anyone but the incumbent to modify. Protocol openness and commercial openness are different properties, and the second is the one that determines your position in three years. These are the mechanisms worth examining, roughly in order of how much trouble they cause:

• Engineering tool availability. The software used to write and edit controller logic is a separate product from the operator front end, and on many platforms it is restricted to trained and authorised parties, sometimes licensed per engineer, sometimes not sold to end users at all. If only your incumbent can obtain it, the openness of the protocol is irrelevant: you cannot change a sequence without them. This is the single most important question on this list.
• Ownership of the application programming. The logic in your controllers was written by somebody, and the question of whether you own it, hold a licence to it, or merely benefit from it is almost never addressed in a service contract. Where it is unaddressed, assume you do not own it.
• Source form of the programming and graphics. Compiled logic running in a controller is not the same as the editable source. Graphics in particular are frequently handed over as rendered screens rather than as the editable project, which makes the next change a rebuild rather than an edit.
• Licence keys and activation. Head-end licences tied to a supplier account, point-count licences, driver licences for each integrated protocol, and licences that must be re-issued when hardware changes. A licence your supplier holds on your behalf is a licence you do not control.
• Firmware and parts channel. Controller firmware is often distributed only through authorised channels, and some parts are not available on the open market. This is a legitimate manufacturer position and a real constraint on independent maintenance.
• Proprietary extensions above the open protocol. Many systems use a standard protocol for interoperation and a proprietary mechanism for their own controller-to-controller traffic, configuration and alarm handling. Replacing part of the system then means replacing more than you expected.
• Documentation as a deliverable. The points schedule, sequences of operation, panel drawings, naming conventions and as-installed records determine whether anyone else can pick the system up. Their absence is a soft but highly effective lock-in, and it is covered in detail in BMS points lists and field devices.
• Hosted components. Where analytics, dashboards or remote access run on the supplier's platform rather than yours, ending the contract ends the capability and may end access to the history. The trade-offs are set out in cloud BMS and building management as a service.

5. How to score lock-in before you sign

This is the part to do while you still have leverage, which means before contract award rather than at renewal. Each question below has a good answer, and a supplier's reluctance to answer in writing is itself informative.

• Can we buy the engineering tool, and on what terms? Ask for the product name, the licence model and the price. If the answer is that it is not available to end users, you have established the central fact of your situation. That is not necessarily disqualifying, but it must be priced into the comparison.
• Can a third party we appoint be trained and authorised? If the tool is restricted but authorisation is obtainable by any competent firm, your position is far better than if authorisation is limited to a closed partner network.
• Who owns the application programming and the graphics project, and in what form will we receive them? Put the words "editable source" in the question. Accept nothing that only promises a backup or an archive file you cannot open.
• In whose name are the software licences registered? Yours, or the supplier's. Ask for evidence, not assurance.
• What happens to licences and remote access on termination? Specifically, does the head end keep working.
• Where does trend history live, in what format, and can we export all of it on demand? History is the asset that makes analytics possible later, and it is the asset most easily stranded.
• Which parts and firmware are channel-restricted? A straight list. This tells you what an independent maintainer could and could not do.
• What is the priced cost of a full handover to another supplier? Asking for this number at tender stage is the single most useful piece of commercial hygiene available, because it converts an unknown future risk into a line you can compare across bidders.
• Will you provide the as-installed documentation set as a contractual deliverable with a retention tied to it? Documentation promised without a payment milestone attached arrives late or not at all.

Score each bidder across these and the picture usually separates quickly. In my experience the bidders who answer all nine in writing without hedging are a small minority, and they are frequently not the cheapest, and they are frequently the right choice anyway.

6. The clauses worth arguing over

Most BMS service contracts are the supplier's standard document with a price and a site list inserted. These are the amendments I would prioritise, roughly in descending order of value:

7. What actually drives the price

BMS service pricing is less arbitrary than it appears, and knowing the drivers lets you negotiate the right things. The main ones are the number and dispersion of sites, the controller and point count, the number of integrated third-party systems, the response time required, whether parts and labour are included, the age and support status of the installed hardware, whether out-of-hours cover is included, and how much engineering change allowance is bundled.

Two of these are worth attacking specifically. Response time is often specified far tighter than the building needs, because a short response commitment sounds prudent and costs real money; differentiating response by criticality, so that a chiller plant fault and a single office thermostat do not carry the same commitment, usually buys back more than any other single change. And the bundled engineering allowance is frequently either far too small to cover a year of realistic change requests, which means every change becomes a quotation and a delay, or large and unused. Size it from last year's actual change history if you have it.

Where the estate is large enough that service cost becomes a material line, the same discipline that applies to any maintenance programme applies here: the contract should be sized from the asset register and the failure history, not from a supplier's standard template. That linkage is the practical reason a BMS belongs in the maintenance system at all rather than being treated as a separate world, which is the argument in the BMS and CAFM integration reference architecture.

8. One small building, or a multi-site portfolio

These two situations have genuinely different answers, and conflating them is why the question feels unresolvable.

For a single small or medium building, with a system of modest size and no unusual integration, a competent local firm is usually the better choice. The work is routine, response time depends mostly on travel distance, and the manufacturer's escalation route into its own engineering is rarely the thing you need. The risk to manage is key-person dependency and documentation, not platform depth. The related question of who should install controls in the first place on a small building follows the same logic: a general mechanical contractor who sub-contracts controls will usually give you a system nobody owns, whereas a controls specialist, whether aligned to a manufacturer or not, gives you one party accountable for the sequences working.

For a multi-site portfolio, the calculation inverts. Consistency across sites, a common head end, comparable data, one escalation route and one obsolescence plan become worth more than the price difference. This is where a framework agreement with a manufacturer or a large partner usually earns its premium, and where a patchwork of local arrangements quietly costs the most: every site develops its own naming, its own graphics conventions and its own undocumented local knowledge, and portfolio-level reporting becomes impossible. If you are consolidating a portfolio onto one head end, the platform-layer considerations are covered in how to evaluate BMS software and platforms.

For a critical facility, neither heuristic governs. Response, escalation depth, change control and evidence matter more than price in almost any configuration, and the requirements that follow from that are set out in BMS for data centres and critical facilities.

9. When in-house is the right answer

In-house controls capability is undervalued, and also frequently attempted at a scale that cannot sustain it. The conditions under which I would advise building it:

• Enough estate to keep a specialist genuinely busy on controls work rather than absorbing them into general maintenance within six months, which is the usual failure.
• A platform whose engineering tool you can actually license. If you cannot obtain the tool, an in-house engineer can operate the system but not change it, which captures only a fraction of the value.
• A continuous improvement agenda. The real return on in-house capability is not call-out savings, it is the hundred small sequence and schedule corrections per year that no service contract would ever fund and no external engineer would notice.
• A documentation discipline you will actually enforce. In-house change without change records produces the worst lock-in of all, as noted in the table above.
• A retained specialist arrangement alongside it, for out-of-hours cover, holiday and sickness, major works and the faults that need manufacturer escalation. In-house instead of a contract is usually a mistake; in-house plus a smaller contract is usually the strong position.

10. How to leave, and why to plan it before you arrive

A supplier transition on a BMS is more involved than on most maintenance contracts, because the thing being transferred is knowledge and configuration rather than a routine. A workable sequence:

• Take a verified full backup before giving notice, of every controller, the head end, the graphics project and the trend history, and confirm that the backup restores. A backup nobody has tested is a hope.
• Collect the documentation set against a list rather than accepting whatever arrives: points schedule, sequences, panel drawings, network topology, licence records, device schedule, alarm and trend configuration.
• Establish licence position in writing before termination, including which licences transfer and which must be re-issued, and what that costs.
• Overlap the two suppliers deliberately, with a joint site walk and a handover of local knowledge as a contracted activity rather than a goodwill gesture.
• Change every credential and revoke every remote access path on completion, and verify the revocation rather than requesting it.
• Run a verification period during which the new supplier proves the system against the documentation, because transition is when you discover what was never really documented.

The reason to plan this at award rather than at exit is simple. Every item above is cheap to secure as a condition of winning the work and expensive to obtain from a supplier who has already lost it.

11. The honest part: openness claims and the service contract

The controls industry has spent two decades talking about open systems, and genuine protocol interoperability has improved a great deal. A modern system from any of the major manufacturers will exchange data with other systems far more readily than one from the 1990s, and the standards work behind that is real. If you want the detail of how that interoperation actually happens, it is in BACnet explained and BACnet versus Modbus.

But openness at the protocol layer has turned out to be compatible with a high degree of closure at the service layer, and buyers routinely mistake the first for the second. A system that publishes every point over a standard protocol, so that any analytics platform can read it, may still be a system whose sequences only one firm on earth can edit. Both statements can be true of the same building at the same time, and the sales conversation tends to feature only the first.

This is not a conspiracy, it is a straightforward commercial equilibrium. Manufacturers invest in engineering tools, training and firmware, and restricting them protects both that investment and the quality of work done in their name, which is a defensible position. The consequence for a buyer is simply that you have to ask the service-layer questions explicitly, because nothing in a protocol specification answers them and nobody volunteers the answers.

The idea to walk away with

The model matters less than the terms. A manufacturer contract with no configuration ownership and an unpriced exit is a weaker position than an independent integrator contract that hands you editable source, registers the licences in your name and fixes the handover cost at award. The reverse is also true. Choosing between the four models is a genuine decision with genuine trade-offs, but it is the second decision, not the first.

So run the three-question test before anything else. Who owns the programming, in what form. Who can obtain the engineering tool, and on what terms. What does it cost, in writing, to leave. If a bidder answers all three without hedging, you are negotiating about service quality and price, which is a comfortable place to be. If they will not, you are not buying maintenance, you are buying a dependency, and it should be priced as one.

Final thoughts

BMS service contracts get renewed for years on the basis that nothing has gone badly wrong, which is not the same as the arrangement being sound. The test is not how the last twelve months went. It is what happens the day you want to change something significant, or the day the supplier relationship ends, whichever comes first.

If you inherit a contract rather than award one, the useful first move is a documentation and licence audit: establish what you actually hold, in whose name, in what form, and what is missing. That audit is unglamorous, takes a few days, and tends to reset the conversation at the next renewal more effectively than any amount of benchmarking.

Related reading: BMS maintenance, servicing and lifecycle, BMS specification clauses, Siemens vs Schneider vs Honeywell vs JCI, Evaluating BMS software and platforms, BMS points lists and field devices, BMS cybersecurity for connected buildings.