How do you integrate legacy building systems into one data platform?

Find out first what the existing systems can reliably expose. Then connect them in order of value, read-only first, and prove each connection under real conditions before anyone relies on it. Legacy integration is an engineering and operating exercise long before it becomes a dashboard project, and its aim is modest but demanding: a maintainable flow of trustworthy information that does not destabilise equipment already serving the building.

Survey first, choose gateways later

Every system in scope needs a short dossier, whether it is the building management system (BMS), lighting control, meters, lifts, access control or fire alarm interfaces. Record the controller makes, models, firmware and software versions; the interfaces and protocols supported, such as BACnet, Modbus, KNX, OPC, a proprietary API, or none at all; where the system sits on the network and how it could be reached securely; what documentation exists, including point lists, network drawings and licences; and who supports it, and whether that supplier permits third-party connections.

Then check a sample of real data against the equipment itself. Point lists often contain abandoned, renamed or misleading entries, and "available" on paper is not the same as readable in practice.

Decide what is worth connecting

Some sources justify a supported connector; some need a carefully managed protocol gateway; others are better left until the system is replaced anyway. Writing the classification down stops most of the budget disappearing into the hardest, least useful system.

Connect read-only, and design the security in

Read-only connections are the right starting point wherever possible. Gateways and connections belong where the building's network segmentation design puts them, which is seldom the most convenient spot on the day. NIST's guide to operational technology security, SP 800-82, recommends multi-factor authentication for remote access to OT systems and monitoring of information flows between security domains. Legacy integration creates exactly such flows, and each one should be designed and documented before it carries data.

Prove each connection before trusting it

A connection that works in a demonstration can still fail in service, so each one deserves a few pointed tests. Does polling affect the controller's performance or the network? Are timestamps applied at source or on arrival, and in which time zone? Is a value of 215 a temperature of 21.5 °C or 215 kWh? What happens after a network or power interruption, and is the history backfilled? And what happens when a point is added or renamed on the source system?

Throughout, preserve the source identity and record every transformation. A converted unit or renamed point must remain traceable to its origin, particularly once it supports operating decisions.

When the source system and the platform disagree, someone has to diagnose the fault. Agree in advance who is responsible for the source, the gateway, the network and the platform, and how a fault that crosses those boundaries is escalated.

Keep a register as you go

An integration register records each source, its interface, gateway, owner, polling rate, connected points, known limitations and test results. It is dull to maintain and invaluable later, because it becomes the basis for support, for expansion and for the eventual replacement of each legacy system.