Somewhere in your building there is a length of twisted pair with a dozen controllers hanging off it, and it’s been doing its job quietly for 25 years.
Then a vendor tells you it’s time to move everything to BACnet/IP. Maybe they’re right. But maybe they’re describing a project you don’t need.
Migrating from MS/TP to BACnet/IP is a real change in what your building automation system can do, and a real cost in money and disruption to get there. The only question that matters is whether your building needs what it buys.
Here’s how to work that out before you sign anything.
What Actually Changes When You Migrate to BACnet/IP
MS/TP and BACnet/IP carry the same language. Same objects, same properties, same BACnet commands. What changes is the road underneath.
MS/TP is a serial bus. Devices are wired in a chain and take turns passing a token, so only one device talks at a time and everyone else waits. Add devices to that chain and every device’s turn comes around less often. It’s a shared lane.
BACnet/IP, on the other hand, rides on the same Ethernet and switch infrastructure the rest of your building already uses. Each device gets its own connection to a switch port instead of a slot in a queue, and the raw speed of that link is orders of magnitude beyond what a serial bus was designed for.
That creates three distinct advantages:
- Responsiveness. Trends sample faster, graphics stop lagging, and global commands take effect closer to when you press the button. On a long, busy MS/TP trunk, these degrade in ways operators learn to accept as normal.
- Headroom. More devices, more data points, more history, without the trunk shaping your design.
- Reach. A device on the OT network can be reached from anywhere on it. Remote diagnostics, multi-building visibility, and analytics platforms all assume this; MS/TP only reaches them through a translation layer.
The practical version: on a serial trunk, the wire shapes what you can ask the building to do. Migrating to IP removes that constraint — which only matters if it’s currently constraining you.
Do You Actually Need to Migrate?
Not automatically. Three honest answers:
No, if the capability doesn’t map to a problem you have. A stable MS/TP trunk running a straightforward air handler schedule, with no analytics ambitions and no expansion plans, is not broken. “Old” is not a fault condition. If nobody is complaining about response time and nobody is waiting on data the system can’t deliver, migration buys you capability you won’t use. Nate Benes, who runs operations at the University of Nebraska, put it plainly on our podcast: “I’m probably not going to walk into a building that’s happy and working well and rebuild it just because it seems cool.”
No, if it means tearing out working infrastructure to get there. Pulling new cable through occupied space and replacing controllers that still do their job is expensive and disruptive, and the payback is hard to write down honestly. If a proposal starts with the whole building coming out, ask what problem is being solved.
Yes, if it’s new construction or a major retrofit — without much hesitation. When the walls are open and the controllers are being bought anyway, the marginal cost of doing it over IP is small and the option value is large. You get capacity you haven’t spent yet, and a network that connects to whatever supervisory or OT monitoring tools you adopt in ten years. Setting up a BACnet HVAC network on IP from day one is the cheapest version of this decision you will ever be offered. Our own assessment of how much life MS/TP has left is blunt on this point: “If you’re starting from scratch, there’s no value in investing in outdated technology that will need to be replaced sooner than later.”
The most common real-world answer is somewhere in between: an IP backbone with MS/TP surviving at the edges. That is a legitimate end state, not a half-finished project.
Listen: How to Handshake, Ep. 1 — The drive for energy savings starts with OT networks
Alex Waibel, President of BuildingLogix, on existing buildings: “don’t replace something that isn’t broken.” Optigo’s Ping Yao makes the opposite case for new builds, where the price gap between MS/TP and IP controllers has all but closed.
Things to Keep in Mind If You Migrate to BACnet/IP
Migration is not free of consequences. The ones that bite hardest:
- Older devices strain under IP traffic. Field controllers with modest processors were specified for a quiet serial bus, not a network with broadcast traffic on it. Some become unreliable in ways that look like mechanical faults and get chased for weeks.
- Broadcast behaviour becomes your problem. The BACnet/IP protocol leans on broadcasts for discovery, and broadcasts don’t cross subnets on their own. That’s what BBMDs are for, and misconfigured BACnet routing is one of the most common causes of devices that appear, disappear, and appear again.
- A bigger network is a bigger attack surface. MS/TP’s isolation was accidental security. Once building controls share infrastructure with the rest of the enterprise, segmentation, access control, and patching stop being IT’s private concern.
- Ownership gets political. The moment your building automation system lives on switches, IT and facilities have to agree who owns the VLAN, the addressing, and the 2 a.m. phone call. Sort that out before commissioning, not during.
- Troubleshooting changes shape. You can no longer walk the trunk with a laptop and find the chatty device by elimination. Problems become intermittent, distributed, and invisible to the tools that used to work.
Where Do You Start?
Start with what you have, not with what you’re buying.
Inventory the system. Which controllers are on which trunks, which are at end of life, and which vendors still support them. You want a current picture of your BACnet topology, because plans built on drawings from the original fit-out tend to fail in week two.
Baseline the network you have today. Capture how the current system actually behaves — traffic levels, error rates, devices that already misbehave. Without a before picture, every post-migration complaint becomes an argument nobody can settle.
Find the natural boundaries. New floors, a chiller plant replacement, a controller line going end of support. Migration is cheapest riding along with work already funded.
Plan the hybrid deliberately. A BACnet IP router lets existing MS/TP segments live behind an IP backbone. Document where those boundaries sit and how broadcasts cross them, because that’s where the confusing failures live.
Agree the IP design with IT first. Subnets, addressing, VLANs, remote access, and who monitors what. If BACnet is new to your IT group, start them on what network health means in a BACnet context. Hardware bought before this conversation gets revisited expensively.
Don’t Build a Faster Network and Then Look Away
Everything you gain by migrating depends on the network underneath staying healthy — and an IP-based OT network hides its problems better than a serial bus ever did. A device flooding the network with broadcasts, a duplicate device ID, a BBMD pointing at a dead address: none of these announce themselves. They surface months later, as an operator saying the graphics feel slow.
OptigoVN exists for that gap. It watches your BACnet network continuously, scores its health, keeps a live device inventory, and runs device-level diagnostics that name the root cause instead of handing you a packet capture to interpret. Baseline the network before migration and compare against the same view after, which turns “it feels worse” into something you can prove or dismiss.
Our rundown of the best OT network monitoring tools covers where each fits. Either way, set up the visibility before the first controller moves.
Request a free trial of OptigoVN and see your BACnet network the way it actually behaves.
FAQ
Do I need to migrate from MS/TP to BACnet/IP?
Only if the capability buys you something. A stable MS/TP trunk running a straightforward sequence, with no expansion plans and no analytics ambitions, is not a problem waiting to happen. The clear yes is new construction or a major retrofit, where the walls are already open and the controllers are already being bought.
How do I know whether my MS/TP network is actually causing problems?
Look for the symptoms operators have stopped reporting: graphics that lag, trends with gaps, commands that take a while to land, devices that drop off and come back. Then confirm it rather than assume it. A packet capture and health check will tell you whether the trunk is the constraint or whether something else is.
Can MS/TP and BACnet/IP run on the same system?
Yes, and most real buildings end up this way. An IP backbone with MS/TP segments behind BACnet routers is a legitimate design, not a half-finished migration. It also lets you move in phases as budget and access allow, instead of taking the whole building at once.
Do I have to replace all my field controllers?
No. MS/TP controllers can keep doing their job on their existing trunk, reached through a BACnet IP router. You replace controllers when they reach end of life, when the vendor drops support, or when you need a capability they don’t have — not because the backbone changed.
What is a BACnet router, and do I need one?
A BACnet router passes traffic between BACnet networks that use different data links, such as an MS/TP segment and an IP backbone. If any MS/TP is staying, you need routing between the two. Getting that configuration right is most of the difference between a quiet network and a confusing one.
What is a BBMD, and why does it matter after migration?
BACnet/IP uses broadcasts for discovery, and broadcasts do not cross subnets on their own. A BBMD forwards them across subnet boundaries so devices can still find each other. Misconfigured BACnet routing and BBMD tables are among the most common causes of devices that appear, disappear, and appear again.
Should new construction still use MS/TP?
Rarely, and the reason is economic rather than technical. When controllers are being purchased anyway and the cabling pathways are open, the marginal cost of specifying IP is small while the capacity and reach you get are not. Long runs and isolated equipment groups remain the reasonable exceptions.
What should I do before the migration starts?
Three things: inventory what’s actually installed, baseline how the network behaves today, and agree the IP design with IT. The baseline matters most — without a before picture, every complaint after cutover becomes an argument nobody can settle. OptigoVN gives you that baseline and the same view afterward, so you can prove what changed.
FAQs are generated with the assistance of AI.
