Can an existing building be converted into a smart building?

In many cases, yes, and without gutting it. Better use of the controls already installed, a few targeted sensors, selective integration and some well-chosen replacements can deliver much of the value. The age of the building matters less than three practical facts: whether the installed systems are in decent condition and still supported, how much data can actually be extracted from them, and how much disruption the occupiers will put up with.

That is why conversion works best as a phased programme. A self-contained first phase can prove its worth on its own, so the whole project never has to be justified at once.

A survey that answers the right questions

An equipment list is not a survey. Before anyone designs anything, the owner needs to know which controllers, servers and software versions are still supported by their manufacturers and which are at end of life, and who holds the passwords, licences and configuration backups. The question of supportability is quickly followed by one of access. Which systems expose a documented interface, such as BACnet, Modbus or a published API, and does the installed configuration actually make the needed points available? A protocol name on a datasheet proves nothing. The US Department of Energy identifies this as one of the main barriers to better building control: integration typically involves several vendors, each with proprietary hardware, software and protocols, which leaves data in unconnected silos.

Then come the quieter questions that often decide the budget. Are sensors reading plausibly, and are point names consistent enough to identify equipment and locations without guesswork? Is there a separate network for building systems, who administers it, and does it have the capacity and power for more devices? How accurate are the drawings, asset registers and operation and maintenance manuals? And when can work actually happen? A school, clinic or occupied office may allow only short windows, and some changes need a planned shutdown.

The survey should end with a short register of findings, each graded as usable, usable after correction, or not usable.

Reuse, integrate or replace

For each system, the survey leaves three options.

Two mistakes recur. One is keeping an obsolete controller only to claim the retrofit preserved everything, then paying again and again to work around it. The other is wholesale replacement justified mainly by a supplier's preferred ecosystem. The fair comparison is whole-life effort, from the installation price to fault diagnosis, security updates and future access to data.

Security belongs in the first drawing

Connecting older building systems to new networks or remote services increases their exposure, so the survey should establish whether each older controller supports authenticated access and protected communication at all. NIST's guide to operational technology security (SP 800-82) includes building automation systems in its scope and frames security alongside performance, reliability and safety. A retrofit design should therefore show which systems sit on which network segment, what traffic may pass between them, and how remote support is authenticated and logged. Where an old controller cannot be adequately secured, isolating or replacing it may be the honest answer.

A first phase that stands on its own

A good first phase solves a real operating problem, can be accepted on its own merits and teaches you something about the rest of the building. It needs a named operational owner and clear acceptance criteria.

Planning what comes next

With the pilot complete, the later phases can be set out in a sensible order. The enabling works come first: the network segments, power, metering and sensor repairs that several later phases will rely on. The priority use cases follow, ranked by value and feasibility, each with its own acceptance criteria. Controller and plant replacements are best timed to their natural end of life, so that smart capability arrives when the equipment is being renewed anyway. Running through all of this are the data foundations: naming conventions, an asset register and, where several applications will share data, a documented data structure.

Where it is cheap to do so during current works, such as installing containment while ceilings are open, reserve pathways and spare capacity for later phases. Resist buying every future licence now, though. Subscriptions start costing money on activation, and requirements often change once the first phase is in use.

Questions for the owner's team

• Which of our systems reach end of life within the planning period, and what does that mean for sequencing?
• What will it cost, in engineering time and licences, to unlock the data we need from existing systems?
• Which works can be done in occupied conditions, and which need shutdowns?
• What is the rollback plan if a change disrupts operation?
• Who will operate the new capability, and have they been involved in the design?