A BMS replacement should begin with the building’s actual control assets, sequences, integrations, operator workflows, data, and recovery needs—not a front-end software demonstration.

Start with the operating problem—not the vendor name

Clarify what is driving the project: unsupported software or controllers, unavailable parts, recurring network failures, incomplete integration, limited trend storage, poor graphics, licensing cost, remote-access concerns, operator difficulty, equipment replacement, energy goals, portfolio standardization, tenant complaints, or a broader capital program. Separate a front-end refresh, server migration, supervisory-controller replacement, field-controller replacement, pneumatic-to-digital conversion, integration project, and full controls modernization because they carry different scope and operating risk.

Define the facilities included, systems controlled or monitored, occupancy and critical functions, required operating hours, owner and tenant responsibilities, existing service agreements, internal IT and operational-technology roles, and the decisions the study must support. A new interface can leave the underlying controllers, sensors, actuators, sequences, and network constraints unchanged; replacement planning should state which layers are actually being renewed.

Build the installed control-system inventory

Document available system architecture from field devices to the top level: sensors, actuators, valves and dampers, variable-frequency drives, safeties, local and equipment controllers, supervisory devices, panels, gateways, routers, network media, protocols, addressing, servers, virtual machines, workstations, databases, graphics, historian or trend storage, alarm delivery, remote access, engineering tools, licenses, certificates, and integrations with meters, lighting, central plants, packaged equipment, fire alarm, access control, laboratory systems, tenant systems, and enterprise platforms where applicable.

Create a point and equipment inventory that distinguishes physical inputs and outputs, calculated or virtual points, commands, setpoints, statuses, alarms, overrides, schedules, and trends. Record manufacturer, model, firmware or software version where available, communication method, installed condition, support status, spare capacity, panel power, backup power, source documentation, and accessibility. An exported point list is useful, but it should be checked against drawings, graphics, field panels, actual equipment, and operator knowledge.

Recover the owner’s operating intent and sequence ownership

Collect design sequences, control diagrams, points schedules, balancing and commissioning records, operator notes, current programs, overrides, setpoints, calendars, alarm rules, trend definitions, and known workarounds. Compare written intent with installed programming and observed operation. Years of local edits may contain valuable operational knowledge, temporary fixes, abandoned code, safety dependencies, and energy waste; copying every line forward without review is not preservation.

For each system, define the required modes, enable conditions, staging, reset logic, safeties, interlocks, failure responses, manual control, alarm priority, trend interval and retention, and operator permissions. Identify which party may approve a sequence, which party will program it, and which professional retains design responsibility. Controls replacement is a chance to create one current sequence record, but unresolved mechanical problems and missing sensors should not be hidden inside software scope.

Set interoperability, data, and cybersecurity boundaries before procurement

State the required ownership and delivery of databases, controller applications, source files, graphics, histories, trend exports, credentials, certificates, licenses, engineering tools, backups, restore procedures, naming conventions, and configuration records. Identify where open protocols are required, where proprietary devices or gateways remain, which integrations are read-only or command-capable, and what happens if a vendor, product, cloud service, or subscription is unavailable.

NIST treats building automation as operational technology and recommends risk-based security that respects performance, reliability, and safety needs. The project should therefore coordinate network segmentation, accounts and least privilege, remote access, logging, patch and vulnerability processes, approved connections, time synchronization, backup, incident response, and recovery with the owner’s IT and OT security teams. KOW can keep these interfaces visible; cybersecurity architecture, authorization, testing, and ongoing governance remain with the qualified responsible parties.

Plan migration around continuity of operation

Break the work into buildings, systems, floors, equipment groups, panels, controllers, and integrations. For each cutover, identify seasonal and occupancy constraints, shutdown window, temporary or local control, safe equipment state, point-to-point checkout, retained safeties, communication plan, rollback condition, staffing, access, after-hours work, tenant or clinical coordination, and the sequence for restoring automatic operation. Central plants, laboratories, healthcare spaces, data rooms, pressure relationships, freeze protection, smoke-control interfaces, and other critical functions may require specialized phasing and verification.

Preserve the existing database and recovery path before modifying it. NIST’s 2026 OT Backup Quick Start Guide emphasizes integrating backups with change management, creating them regularly, testing them, and reviewing them during recovery exercises. A project backup is not complete merely because a file exists; the owner should know which asset it restores, which software and credentials are required, where it is held, when it was tested, and how the building would be operated during recovery.

Accept performance, documentation, and operator ownership together

Acceptance should progress through submittal and shop-drawing review, panel and network inspection, point-to-point checkout, sensor and actuator verification, sequence testing, alarm and trend verification, graphics review, integration testing, failure and recovery tests, seasonal or deferred tests, and observation under representative operating conditions. The UFGS controls framework treats instrumentation, devices, sequences, BACnet control, integration, cybersecurity, and testing as coordinated parts of a functional system—not interchangeable vendor deliverables.

Closeout should include current architecture and control drawings, point lists, sequences, databases and source files, backups and restoration evidence, licenses, credentials transferred through the owner’s secure process, alarm and trend schedules, graphics, test records, issue dispositions, training, service information, warranty requirements, and a post-occupancy tuning plan. DOE re-tuning guidance relies on BAS trend data, building walk-downs, corrective actions, and continued operational use; the replacement has not delivered its value until operators can understand, recover, and improve the system they now own.

Primary sources

Sources and technical references.

Source review current as of September 2, 2026.