Connecting your ERP and BMS without breaking what already works

Resistance to automating processes usually comes from a legitimate fear: breaking a system that already works. That fear isn’t unfounded. A badly migrated ERP, a BMS reconfigured with no rollback plan, or a spreadsheet that “no longer adds up” can halt an entire operation for days. The right conclusion isn’t to avoid automation; it’s to choose the right integration pattern.

Why “rip and replace” fails

Replacing a legacy system with a new one looks like the cleanest solution on paper: you eliminate the technical debt in one shot. In practice, it almost always fails for three reasons. First, the real operational knowledge lives in the head of whoever uses the system daily, not in its documentation, and that knowledge doesn’t automatically migrate to the new tool. Second, the cost and time of a full migration are almost always underestimated, because third-party integrations that depend on the old system don’t get counted. Third, and most important: during the transition, the company runs two systems at once, which multiplies friction instead of reducing it.

The alternative is to build logical bridges between systems (ERP, BMS, spreadsheets) that respect the existing workflow and only remove the manual friction between them. No system gets replaced. It gets connected.

The logical bridge pattern

A logical bridge isn’t a native integration between two products (which rarely exists between legacy systems) or a data migration. It’s a middle layer, usually orchestrated with n8n, that listens for events in one system, transforms them into the format the other system expects, and delivers them through its API or standard import mechanism. That layer doesn’t store the business truth — the truth still lives in the ERP or the BMS — it only transports and translates.

This has an important practical consequence: if the bridge fails, it can be disconnected without losing data, because both systems remain self-sufficient on their own. That’s a property a “rip and replace” never offers during the transition.

Concrete example: from an ERP invoice to a BMS ticket

A common case: the ERP generates a maintenance invoice for a supplier, and that invoice should automatically open a follow-up ticket in the BMS so the facilities team can confirm the work was done before the payment gets approved. Without a bridge, this gets solved today by someone reviewing the ERP, copying the relevant data, and entering it by hand into the BMS.

The logical bridge automates exactly that step:

1. n8n listens for the “invoice created” event in the ERP (via webhook if the ERP supports it, or via a periodic call to its API if it doesn’t).
2. It extracts the relevant fields: supplier, amount, contract reference, date.
3. It transforms those fields into the schema the BMS needs to create a ticket (field names almost never match between systems, and that transformation is the real engineering work).
4. It creates the ticket in the BMS via its API, and stores the cross-reference between invoice and ticket.
5. When the ticket is marked resolved in the BMS, another flow notifies the ERP (or the responsible person) that the payment can be approved.

Nobody had to copy a single piece of data by hand, and neither system changed how it works internally.

Idempotency: the detail that decides whether the bridge is reliable

A logical bridge that isn’t idempotent is a risk, not an improvement. If the ERP’s webhook gets resent twice because of a network glitch (a common occurrence) and the flow doesn’t account for it, two duplicate tickets get created in the BMS for the same invoice. The fix is simple but not optional: every event must carry or generate a unique identifier (the invoice ID, for example), and before creating a new ticket, the flow checks whether one with that reference already exists. If it does, it does nothing. This idempotency check is one of the first things validated during the Build phase, before a flow is considered finished.

Access control: fewer permissions, not more

Connecting two systems shouldn’t mean giving one full access to the other. The credential the bridge uses to talk to the BMS only needs permission to create and query a specific type of ticket, not admin rights. This least-privilege principle limits the potential damage if that credential is ever compromised, and it’s a standard security practice that often gets skipped in the rush to ship the first integration.

The core idea

No system gets replaced. It gets connected. A well-designed, idempotent logical bridge with scoped permissions lets two legacy systems collaborate as if they’d been designed together, without the risk or cost of a full migration — and without anyone on the team having to learn a new tool.