Energy solutions / Building controls guide
Building Automation System Upgrades: When to Integrate, Modernize, or Replace

Choose a controls upgrade path that fits your existing systems, operating needs, and budget—with a clear plan for compatibility, commissioning, and handover.
A building automation system upgrade can retain usable field devices, integrate selected systems, replace unsupported components, or combine those approaches. The right scope starts with the owner’s operating needs, a verified inventory, and a practical plan for testing and handover.
When should a building automation system be upgraded?
Start with a specific operating problem: unsupported software, unavailable replacement components, unreliable communication, inconsistent schedules, missing trend data, unresolved alarms, or an interface that makes routine work difficult. Building expansion and mechanical equipment replacement can also create a need to review the controls architecture.
An old interface alone does not prove that every controller or sensor needs replacement. Conversely, a new dashboard cannot correct faulty sensors, failed actuators, unsuitable control sequences, or an unsupported network. Separate the condition of the field equipment, controllers, communications, supervisory software, and operating procedures.
Write down the outcomes the project must deliver. Examples include reliable alarm delivery, access to useful trends, consistent naming, documented control sequences, manageable schedules, and an agreed support arrangement. These requirements make proposals and acceptance testing easier to compare.
Retain, integrate, or replace: compare the upgrade paths
| Approach | When to investigate it | What must be demonstrated |
|---|---|---|
| Retain and optimize | Supported equipment is functioning, but sequences, schedules, sensors, graphics, or operator practices need attention. | The cause of the problem is understood; corrections can be tested and supported. |
| Integrate and modernize in phases | Some infrastructure is useful and compatible, while selected controllers, networks, or software need replacement. | Required data and commands can cross the proposed interfaces reliably, with a defined support owner. |
| Replace a defined subsystem or platform | Unsupported components, repeated failures, severe limitations, or a changed building use make retention impractical. | The replacement scope includes dependencies, downtime planning, migration, commissioning, and operator handover. |
A building can use more than one approach. For example, a project might retain verified sensors, replace selected controllers, modernize the supervisor, and correct sequences in the same phase. Document the condition and interface checks that justify each retained component.
What should the controls inventory cover?
Collect current drawings and compare them with the installation. Record controllers, supervisory devices, software versions, licenses, sensors, actuators, communication protocols, gateways, network dependencies, and connected mechanical equipment. Identify who owns credentials, programming tools, backups, and support agreements.
A point schedule should identify what each item represents, its units, read or write permissions, expected update behavior, alarm role, and trend requirements. Define naming conventions before migration so operators can recognize the same equipment in graphics, trends, service reports, and the asset register.
Does BACnet make every device automatically compatible?
BACnet provides a common communications framework for building automation. BACnet International’s BTL program independently tests products against its certification requirements. A listed product is useful evidence, but it does not replace project-specific verification of the functions, model, firmware, points, network design, and interactions the owner actually needs.
Before committing to a broad rollout, ask the project team to demonstrate the required readings, commands, alarms, schedules, and trends across a representative integration. Identify any gateway or license dependency and name the party responsible for supporting it.
What should a BAS upgrade proposal include?
Require a deliverables schedule as well as a hardware list. It should explain what the owner receives, how success will be demonstrated, and who resolves exceptions.
| Deliverable | What to specify |
|---|---|
| System boundary and exclusions | Buildings, systems, points, retained equipment, replaced components, interfaces, and work by others. |
| Sequences and point schedule | Approved operating logic, consistent names, units, access permissions, alarms, and trend requirements. |
| Software and ownership | Licenses, recurring costs, owner access, export formats, programming access, and transfer of configuration records. |
| Network and security responsibilities | Facilities and IT contacts, authorized remote support, network design, update responsibilities, and backup/restore arrangements. |
| Commissioning and acceptance | Test procedures, expected results, witnesses, exception handling, and required seasonal or deferred tests. |
| Training and support | Operator training, usable documentation, support hours, escalation contacts, warranty terms, and response definitions. |
NIST treats building automation as operational technology, where security measures must account for reliability and safety. Involve the owner’s IT and facilities teams early. They should agree on access, segmentation, change control, recovery, and support responsibilities before a new connection or remote-access method is introduced.
Evaluate the total project cost: discovery, design, integration, software, field work, commissioning, training, and ongoing support. Record savings as forecasts until a defined measurement process demonstrates them. A lower installation price can be offset by omitted interfaces, limited access to data, or recurring licensing costs.
How to phase a building automation upgrade
- Establish the baseline. Record known defects, the current architecture, representative operating trends, and the outcomes the owner expects.
- Define the migration design. Identify what will remain, what will change, and how each dependency will be managed. Agree on outage windows and recovery steps.
- Pilot a representative system. Verify the proposed interfaces, sequence behavior, operator view, alarms, and data access before expanding the rollout.
- Implement controlled phases. Coordinate affected occupants and equipment owners. Keep an accurate record of which systems have moved to the new arrangement.
- Test the required operation. Confirm point accuracy, commands, schedules, alarms, trends, and documented responses to approved test conditions. Qualified personnel should control testing and protect required safeties.
- Complete the handover. Deliver configuration records, backups, training, licenses, support contacts, and a list of deferred or seasonal tests.
Acceptance should demonstrate behavior, not just the presence of a new screen. For each agreed test, retain the date, system, expected result, actual result, exception, and disposition. Keep unresolved items assigned to a responsible party until closed.
When controls work is linked to equipment replacement, coordinate it with the HVAC capital plan. After handover, connect routine inspections and support to the maintenance budget so the new system has a sustainable operating plan.

Documented experience: Bryn Mawr College
The Tustin Group’s historical Bryn Mawr College case study describes a five-year modernization beginning in 2003 across a 50-building campus. Approximately 3,000 existing control points were retained while the controls environment was modernized.
The project illustrates why compatibility, phasing, and preservation of useful infrastructure belong in an owner’s planning discussion. It is a historical project example, not a recommendation to use its original technology today or a guarantee of savings for another facility.

Common questions about building automation upgrades
Can existing sensors and actuators stay?
Possibly. Verify their condition, accuracy, interface, range, installation, and suitability for the intended sequence. Retention should be an explicit design decision supported by evidence.
Can the work be completed without shutting down the building?
Some work can be phased, but permitted outages depend on the systems, migration method, and operating risks. Require the project team to identify interruptions and contingency measures before committing to a schedule.
Will a new BAS automatically reduce energy use?
No specific saving should be assumed. Outcomes depend on existing performance, implemented sequences, mechanical condition, commissioning, and ongoing operation. Define the baseline, assumptions, and verification method.
How can an owner avoid losing access to system information?
Specify the required owner accounts, configuration records, licenses, backups, trend exports, documentation, and support arrangements in the proposal and acceptance checklist.
Plan the next step for your building controls.
Tustin’s energy solutions include building automation, controls integration, commissioning, monitoring, and custom programming. Bring your system inventory, known limitations, and operating goals to the first discussion.
Discuss a controls upgradeFind your local Tustin teamSources and further reading
- BACnet International: About BACnet.
- BACnet International: BTL Product Certification — product testing and listing information.
- NIST SP 800-82 Revision 3: Guide to Operational Technology Security, final publication. The linked page also identifies subsequent draft work.
- The Tustin Group: Bryn Mawr College HVAC Controls Modernization, with the original project PDF available on the case-study page.
Compatibility, security, controls design, and acceptance procedures require review of the actual installed systems and the owner’s requirements.


