CMMS Integration: Why Your Maintenance Data Is Trapped

A vibration sensor flags a developing bearing fault. The condition monitoring platform knows. The CMMS does not. Someone has to notice the alert, look up the asset under a different name in the CMMS, and create a work order by hand. If that person is busy, the warning time that justified the sensors drains away, and the repair that could have been planned becomes an emergency.

That handoff is where many predictive maintenance programs stall. A small pilot works because a motivated engineer bridges the systems manually. Scaling to hundreds of assets fails because nobody can bridge that many by hand. This article explains why maintenance data ends up trapped, the architecture that frees it, and how to start.

Why the data is trapped

Most plants run at least four systems that each hold part of the maintenance picture:

Each system was bought by a different team for a different purpose, and each uses its own asset identifiers. CMMS and ERP think in transactions (a work order opened, parts issued, labor charged, work order closed), while historians and monitoring platforms think in continuous signals. Connecting them is less a technology problem than an agreement about identity, ownership, and timing.

Why pilots stall at scale

Manual bridging scales linearly with the number of alerts, and alerts grow with every asset you add. Three failure patterns show up again and again:

• The copy-and-paste workflow. Alerts are exported or emailed, then re-keyed into the CMMS. It works for a handful of assets and collapses when volume grows, because planners spend their day transcribing instead of planning.
• Point-to-point connectors. Each pair of systems gets its own custom integration. Every vendor upgrade can break one, and nobody owns the whole chain.
• Conflicting status. The CMMS shows an asset healthy because its PM was just completed, the historian shows a slow decline, and the monitoring platform shows a critical alert. Without rules about which system has authority for which kind of data, planners stop trusting all of them.

The cost of that stall is real. NIST's study of U.S. manufacturers found that establishments relying most heavily on reactive maintenance were associated with 3.3 times more downtime than others, while predictive maintenance was associated with 15% less downtime ^[1]. An alert that never becomes a work order delivers none of that benefit.

The architecture: one system of record per data type

The single most useful design decision is to give each kind of data one authoritative home and let every other system subscribe to it, instead of letting systems overwrite one another:

ISA-95 is the usual reference for this boundary. It defines an abstract model of the enterprise, including manufacturing control functions and business functions, and the information exchanged between them ^[2]. You do not need to implement the whole standard to benefit from its central idea: decide which layer owns which information, and exchange it through defined interfaces.

Three integration layers

A scalable design separates collection, movement, and action.

1. Connectivity: getting data off the equipment. OPC UA is the common choice for reading from controllers and plant systems. The OPC Foundation describes it as a platform-independent, service-oriented architecture released in 2008, with an information modeling framework and security controls including encryption, signing, and certificate-based authentication ^[3]. For lightweight sensors and edge gateways, MQTT is widely used; it is an OASIS standard messaging protocol for IoT, designed as an extremely lightweight publish/subscribe transport ^[4].

2. Movement: a message layer between systems. Instead of wiring every system to every other system, publish events (a new alert, an asset change, a work order completed) to a broker or integration platform that buffers, retries, and logs them. If the CMMS API is down, the alert waits in a queue instead of disappearing.

3. Action: the workflows that matter. These are the handful of flows that turn data into maintenance:

Our CMMS integration guide goes deeper on field mapping, triage, and testing for specific CMMS platforms.

Design for OT security from day one

Integration crosses the boundary between plant networks and business systems, which is exactly where security reviews stall projects. NIST SP 800-82r3, the Guide to Operational Technology Security published in September 2023, provides guidance on securing OT while addressing its unique performance, reliability, and safety requirements ^[5]. Use it to shape the design before you build:

• Keep plant devices from initiating connections to the internet; push data outward through defined, monitored paths.
• Prefer broker or gateway patterns over exposing a CMMS or historian directly to external services.
• Use per-integration service accounts with only the permissions each flow needs, such as creating work orders and reading assets.
• Log every cross-boundary transaction so failures and misuse can be traced.

Asset identity is the foundation

None of this works if the same pump has four different names. Before connecting anything, build and verify a mapping from every sensor tag and historian point to exactly one CMMS asset ID, assign an owner to maintain it, and include it in your management-of-change process for new or replaced equipment. Our article on why predictive alerts point to the wrong asset walks through the checks.

Consistent failure codes matter almost as much. A model cannot learn from work orders that say "fixed noise." Standardize failure mode, cause, and action codes for the asset classes you will monitor first.

What to do on Monday

1. List your systems and owners. CMMS, historian, monitoring platform, ERP, and who administers each. 2. Fill in the system-of-record table. Agree which system owns identity, operating data, health, maintenance status, and parts. 3. Pick one flow and one asset class. Monitoring to CMMS work orders for critical pumps is a good start. 4. Verify the asset mapping for that class end to end, from sensor tag to work order. 5. Build the flow with a queue and retries, and run it in shadow mode, creating draft work orders a planner reviews, before going live. 6. Measure the handoff. Time from alert to work order, failed syncs, and alerts that never became work. Those numbers tell you when to add the next flow.

Monitory solves the CMMS integration problem with a purpose-built integration layer that connects to 50+ CMMS platforms, IoT sensor networks, and ERP systems. Instead of building brittle point-to-point connections, Monitory's predictive maintenance platform provides the middleware architecture described above out of the box, turning anomaly detection into automated work orders in minutes, not days.

Frequently asked questions

Why is CMMS integration hard?

Because each system uses its own asset identifiers and data model, and nobody has defined which system owns which data. The technical connection is the easier part.

What is a system of record in maintenance integration?

The one system whose version of a piece of data is authoritative. Others read it or subscribe to changes rather than overwriting it.

Should I use point-to-point integrations or a message layer?

Point-to-point is fine for one or two flows. Beyond that, a message layer with buffering and retries is easier to maintain and stops alerts from being lost when a system is down.

Which protocols are used to connect plant equipment?

OPC UA for controllers and plant systems ^[3] and MQTT for lightweight publish/subscribe messaging from sensors and gateways ^[4] are common choices.

References

[1] NIST, "Research Suggests Significant Benefits to Investing in Advanced Machinery Maintenance," 2020. https://www.nist.gov/news-events/news/2020/06/research-suggests-significant-benefits-investing-advanced-machinery

[2] International Society of Automation, "ISA95, Enterprise-Control System Integration." https://www.isa.org/standards-and-publications/isa-standards/isa-standards-committees/isa95

[3] OPC Foundation, "Unified Architecture." https://opcfoundation.org/about/opc-technologies/opc-ua/

[4] MQTT.org, "MQTT: The Standard for IoT Messaging." https://mqtt.org/

[5] NIST, "SP 800-82 Rev. 3, Guide to Operational Technology (OT) Security," September 2023. https://csrc.nist.gov/pubs/sp/800/82/r3/final