Equipment Maintenance Software vs CMMS

P-104 is a pump. On the day it is entered into the system the record looks simple: P-104, Pump, Process Area A. One line. Nothing controversial.

Four years later the same pump has a history. It failed. A spare pump was fitted in its place while it went to the repair shop. Its motor was replaced during that repair. The repaired P-104 came back into service, but in a different part of the plant.

Now ask a plain question about each of the following: its work history, its failure history, its operating hours, its preventive maintenance, its component history, its costs, its condition records, its meter readings, its spare-parts relationships and its location history.

Did those records belong to the physical pump, to the position where it was operating, to the process function it performed, to its parent system, or only to the work orders that were raised?

That question is the subject of this guide. It is not answered by whether a product is described as equipment maintenance software or as a CMMS.

Are they different things?

Equipment maintenance software and CMMS are not necessarily separate software categories. Equipment maintenance software is commonly used to describe software focused on maintaining machinery and physical equipment, and many CMMS products support those same processes. The useful distinction is therefore not the label. It is whether the system can represent the equipment you maintain — its identity, structure, usage, components and history — at the depth your operation requires.

This guide is a companion to the terminology question rather than a repeat of it. Where CMMS vs maintenance management software deals with overlapping category language, this one asks what changes when the physical equipment becomes the centre of the evaluation.

A work order tells you what happened. An equipment record should help preserve what it happened to.

What does the maintenance history belong to?

Every maintenance event attaches to something. The question is what. There are at least six candidates, and products differ in which ones they treat as real.

• The physical equipment — the particular pump, motor or vehicle, identifiable by serial number.
• The functional position — the place in the operation that a piece of equipment occupies.
• The location — the building, room, area or coordinates.
• The component — a maintainable part inside a larger machine.
• The system — the parent asset or process the equipment belongs to.
• The work order — the job record, with nothing durable left behind on the equipment.

The distinction stops being academic the moment the physical equipment and the position stop being the same thing.

Six seal failures

Pump Position 4 records six seal failures over three years. On the face of it, that is a problem pump. But three different physical pumps occupied that position during those three years.

That changes what maintenance should investigate. If the failures follow the position, the lines of inquiry might include process conditions, piping strain, alignment, installation practice or operating environment. If they follow one physical pump as it moved between positions, the equipment itself becomes the line of inquiry. Neither is a diagnosis. They are different investigations, and the data structure decides which one is even visible.

Bad equipment identity can create false maintenance history.

Position and physical unit

A position is the functional place in the operation — Process Area A, Cooling System, Pump Position 4. A physical unit is the particular maintainable object occupying that place — Pump P-104, serial number and all.

For years the two can look identical, because the same unit has always been in the same place. Then P-104 is removed and P-211 is installed in Pump Position 4. The position continues. The physical equipment has changed.

There is no universal right answer in that table. Some information belongs to the position, some to the unit, and some matters to both. What matters for evaluation is narrower.

Can the system represent the distinction our operation requires?

For fixed equipment that never moves, position and unit may never need to separate. For pumps, motors, rotating spares, vehicles, portable equipment and rebuildable components — the kind of population described in heavy equipment maintenance software — the distinction can matter substantially. Do not require any particular vocabulary from the vendor. Products use different terms for the same structural idea. Evaluate the operational result.

What public procurements ask equipment records to do

Public solicitations are useful here because the buyer writes down what the equipment record has to carry before any vendor answers. Five documents below show what organisations ask of equipment structure, usage and status.

Tacoma Public Utilities specifies support for a minimum of eight hierarchy levels with drill-down, and states in its published questions and answers that the eight levels are intended to align with ISO 14224. It defines drilldown as navigating from a high-level view of assets in the hierarchy into progressively more detailed levels — starting at a top level such as a plant or facility and moving into subsystems, equipment and individual components. The same document addresses what happens when equipment leaves service: certain preventive activities may need to be shelved or skipped depending on asset status or operating conditions, and it gives the example of equipment already taken out of service for an overhaul, where related PM triggers during that time may not be necessary — suspended until the equipment returns to service without deleting or disabling the underlying rule.

Arlington County's asset register requirement asks for a visual display of asset hierarchy, with a diagram spanning Group, Facility, Process, SubProcess, Functional Location, Physical Location and Assets/Components. A vendor asked whether that was a hierarchy or a list of attributes; the County answered that the assets being managed are wastewater treatment process assets. Elsewhere in the same addendum the County states that the existing asset hierarchy will not be migrated because an updated hierarchy has been developed, and that the new hierarchy is a function-based structure with physical location as an attribute.

Lake County states in its procurement questions and answers that its assets are set up in a parent/child hierarchy, and that it wants the vendor to look at the County's data to see whether there would be a better way to set up the hierarchy before importing it into the CMMS, so that the data is set up in a way that makes sense for use with the software. Hierarchy design is treated as an implementation decision to be worked out against the operation, not a box the software either ticks or does not.

Eastern Washington University describes over 100 different vehicles made up of trucks, vans, cars, mowers, heavy equipment, lift forks, scissor lifts, UTVs and other equipment, and states the system should allow these vehicles to be inventoried with all the pertinent information and followed by PMs using hours and miles. The same document states that PM work can be generated based on meter readings, thresholds and/or frequency. Calendar frequency is one option among three in that sentence, not the default.

The City of Mobile's requirement matrix asks that assets have unique IDs preventing duplication, that hierarchical relationships between a parent asset and related child assets can be assigned and viewed, that assets can be grouped into user-defined systems and sub-systems with parent and child assets designated for each, that equipment downtime can be tracked as in service or out of service with reason codes, that different statuses can be assigned to assets such as draft, to be reviewed, operational and out of service, that expected lifecycle data can be tracked at system, subsystem and component level, and that asset lifecycle information includes in-service date and projected and actual retirement dates.

None of these buyers are asking whether the software has an equipment list. They are describing structure, status, usage and lifecycle — what the record has to hold as the equipment changes.

The Equipment Identity Test

Take one piece of equipment that genuinely matters to your operation and ask eight questions of the system in front of you.

1. What is it? Unique identification — asset or equipment number, serial number, manufacturer, model.
2. Where is it? Can its location or operating position change without destroying its identity?
3. What is it part of? Are parent-child and system relationships preserved?
4. What is inside it? Can components or sub-assemblies be independently maintainable where that matters?
5. How has it been used? Hours, miles, cycles, starts, throughput, meter readings.
6. What has happened to it? Failures, inspections, preventive maintenance, repairs, findings, modifications, component changes, costs.
7. What is its current state? Operating, out of service, spare, under repair, retired, replaced. These are examples, not a universal industry list.
8. What happens when it changes? Relocation, rebuild, component replacement, temporary removal, spare substitution, retirement, replacement.

The eighth question is where products separate most. The first seven describe a record. The eighth describes whether the record survives the events that real equipment goes through.

History continuity

A single equipment record can carry several distinct histories, and products preserve different subsets of them.

The buyer's job is to work out which of these change a maintenance decision in your operation. Preserving a history nobody uses is an administrative cost. Failing to preserve one you rely on is a gap you discover years later, when the evidence you need does not exist.

Hierarchy is not a folder tree

The hierarchy is often presented in demos as navigation — an expandable tree on the left of the screen. The procurement evidence above describes something with wider consequences. Tacoma's definition of drilldown is about moving from plant or facility into subsystems, equipment and individual components; its eight levels are intended to align with ISO 14224. Arlington's asset register requirement places equipment inside Group, Facility, Process, SubProcess, Functional Location, Physical Location and Assets/Components. Mobile asks for expected lifecycle data tracked at system, subsystem and component level.

The hierarchy is not merely where the equipment appears on screen. It determines what the system believes belongs together.

What the system believes belongs together governs work attribution, preventive maintenance inheritance, cost roll-up, failure analysis, condition reporting, risk assessment, reporting filters and navigation. A structure chosen for tidy navigation can quietly decide what your failure analysis can group.

The counterpoint

More hierarchy is not inherently better. Each additional level creates administrative work, migration complexity, navigation burden, ongoing data maintenance and a governance requirement for who is allowed to change the structure.

Lake County's position is instructive here: its assets are in a parent/child hierarchy, and it asked vendors to review the data and consider whether there would be a better way to set it up before importing it, so the structure makes sense for use with the software. Hierarchy design is an implementation decision about your operation, not a feature checkbox.

The goal is not the deepest hierarchy. It is enough structure to preserve the relationships that matter.

The granularity problem

Consider one line of equipment: Packaging Line 3, then the Filler, then the Drive Assembly, then the Motor, then a Bearing. Should every one of those become an independently maintained object with its own record and history?

No. Some should, some should not, and the test is not size or cost.

Reasons to give something its own maintenance identity

• Work is performed on it independently of its parent.
• It carries its own preventive maintenance.
• Its failure history is meaningful on its own.
• It moves between parent assets.
• It has a serial number or warranty of its own.
• Its cost needs to be tracked separately.
• It has its own meter or condition measurement.
• It is repaired or rebuilt rather than discarded.
• It is used as a rotating spare.

Reasons not to

• It is a disposable item fitted and forgotten.
• No maintenance decision is ever made about it on its own.
• Its individual history would never be consulted.
• The administrative burden of maintaining the record exceeds any use of it.

Model to the level at which maintenance decisions change.

An equipment record is not equipment history

A database can hold an equipment record and still preserve very little that maintenance can use. P-104, Pump, Building 2, Installed 2021 identifies something. It says nothing about what the pump has experienced.

Useful maintenance history additionally depends on operating exposure, preventive maintenance performed, failures, findings recorded during work, parts and components consumed or exchanged, labour, repairs, condition measurements, modifications and movement.

This is the same gap that separates job completion from maintenance tracking that accumulates into something. The path a work order takes through a CMMS determines how much of it ends up attached to the equipment.

An equipment register tells you what exists. Maintenance history tells you what the equipment has experienced.

The usage clock

Equipment does not age on one clock. Ask which clock the equipment in front of you ages on.

Eastern Washington University's fleet requirement is a plain example of the usage clock in a real document: over 100 vehicles including trucks, vans, cars, mowers, heavy equipment, lift forks, scissor lifts and UTVs, to be inventoried and followed by PMs using hours and miles, with PM work generated from meter readings, thresholds and/or frequency. Frequency is one trigger among three there.

A product can support preventive maintenance as a feature while still failing to represent the operating clock that matters to the equipment.

This is worth testing alongside the wider question of how a preventive programme is built in a CMMS, and against what preventive maintenance software is expected to carry.

Meter continuity

“Does the system support meters?” is answered yes by almost every product. These questions are harder and more revealing.

• Is usage attached to the physical equipment or to the position?
• What happens to accumulated usage when the equipment moves?
• What happens when a meter is physically replaced and the reading resets?
• What happens when a reading is entered incorrectly and later corrected?
• Can more than one usage measure coexist on the same unit where we need hours and miles?
• What happens to usage-triggered PM when equipment is temporarily out of service?
• What happens when a spare becomes the operating unit and starts accumulating usage?

Tacoma's published answer on PM trigger exceptions is a useful reference point for the out-of-service question: equipment already taken out of service for an overhaul may not need its related PM triggers during that period, and seasonal suspension should be possible without deleting or disabling the underlying rule. That is one buyer's expectation, not a standard every product must meet. Decide what your operation needs and test for it.

The Equipment Context Framework

Identity → Position → Configuration → Exposure → Events → History → Decision

Each step depends on the one before it. Without stable identity, position means little. Without configuration, component events cannot be attributed. Without exposure, usage-based decisions have no basis. Without events landing on the right object, history is noise. And history that cannot be assembled supports no decision.

Equipment identity should survive the changes that matter to maintenance.

Five demo tests

These are scenarios to run in a vendor demonstration, in the same spirit as the rest of the demo checklist. Run the same scenario against every product. Do not accept a feature name as an answer to any of them.

1. The component swap test

P-104 contains motor M-22. M-22 fails. A technician removes it and installs spare motor M-31. M-22 goes to the shop, is repaired, and some months later is installed on a different pump.

What the test reveals: whether components are text attributes on a parent record or objects that can hold independent maintenance identity where you need them to.

2. The spare rotation test

Four pumps of the same type. Three operate, one is a spare. An operating pump fails, the spare goes into service, the failed pump goes to the shop, and after repair it becomes the spare.

• How is each physical pump identified through the rotation?
• Does history remain with the physical pump?
• Does the functional position retain useful history of what happened there?
• What happens to preventive maintenance as units swap?
• What happens to usage and meter history?
• Can a user reconstruct which unit was where, and when?
• Can costs remain attributed appropriately?
• Can operating equipment be distinguished from available spare equipment where we need that?

Do not require a feature literally named rotating assets. Test the outcome.

3. The replacement test

P-104 reaches end of life. P-305 permanently replaces it.

Ask what happens to P-104's history, its open work, its preventive maintenance, its bill of materials and parts relationships, its warranty, its meter history, its costs, its documents, the position's history, and any successor or predecessor relationship between the two units.

Two failure modes sit on either side of this. The old history simply disappearing is one. Blindly transferring every old event onto P-305 is the other, because it creates a unit that appears to have failed in ways it never did. Ask the vendor to show how the system preserves continuity while recognising that the physical equipment changed.

The City of Mobile's matrix reflects the same lifecycle boundary in procurement language, asking for in-service dates, projected and actual retirement dates, and asset statuses including out of service.

4. The usage clock test

A preventive task is due at 2,000 operating hours rather than on a calendar date.

This is not an invented scenario. Eastern Washington University's document asks for over 100 vehicles to be followed by PMs using hours and miles, with PM generated from meter readings, thresholds and/or frequency.

5. The five-year history test

If those are meaningfully different questions in your operation, the software has to preserve enough information to answer both. If they are the same question for your equipment, you have just learned that you need less structure than you might have been sold.

Optional: the rebuild test

P-104 receives a major overhaul — new motor, new impeller, new bearings, new seals. Is it still the same maintainable identity?

There is no universal answer. Different organisations answer differently and both answers can be defensible. What matters is that the system supports the answer your organisation gives, because that answer affects lifetime cost, failure history, warranty, condition assessment and replacement analysis.

Not every operation needs this depth

A maintenance operation with a modest number of fixed assets, little component movement, calendar-based preventive maintenance and straightforward history requirements may need none of the structure described above. The equipment does not move, nothing rotates through spares, and the position and the unit are the same thing for the life of the plant.

Every additional distinction has a price: setup effort, data burden during migration, training, day-to-day administration and governance of who may change the structure. Depth bought for its own sake is paid for every week thereafter.

Represent only the distinctions that change maintenance decisions. More equipment structure is not automatically better equipment management.

What this means for the buying decision

Neither label wins. A CMMS may represent equipment extremely well. A product marketed as equipment maintenance software may represent it shallowly, or the reverse. The software category proves very little on its own.

Can this system preserve the identity, context and maintenance history of the equipment we maintain as that equipment changes over time?

That question is answerable in a demonstration, with your own equipment and your own scenarios, in a structured comparison run identically across products.

Buyer questions

Work through these before the first demonstration and fold the answers into your requirements.

What are we maintaining?

• What is the smallest object that needs independent maintenance history?
• Which components need their own identity?
• Which equipment moves between locations or positions?
• Which equipment is rebuilt rather than replaced?
• Which equipment rotates through spares?
• Which items are simply consumed and replaced?

Identity

• How is a physical unit uniquely identified in this system?
• Can serialised equipment retain its history across moves and repairs?
• What events preserve an identity?
• What events create a new identity?

Position

• Can a physical unit move without losing its history?
• Can a position retain history when different units occupy it over time?
• Can location and equipment identity be distinguished where we need that?

Hierarchy

• What hierarchy depth do we genuinely require?
• What information must roll up, and to which level?
• Can work, cost and history be reported at the levels we need?
• What administrative burden does each additional level create, and who carries it?

Components

• Which components need independent maintenance identity?
• Can maintainable components move between parent assets?
• Can we reconstruct what a machine consisted of at a past date?

Usage

• What operating clock matters for each equipment class — calendar, hours, miles, cycles or condition?
• Can multiple clocks coexist on one unit where we need them?

Preventive maintenance

• What happens to PM when equipment leaves service?
• What happens when a spare becomes the active unit?
• What happens to PM when equipment is replaced?
• What happens to usage-triggered maintenance in each of those cases?

History

• Can we see the history of a physical unit?
• Can we see the history of a position?
• Can we see the history of a component?
• Can we reconstruct prior configurations?

Retirement and replacement

• What happens to open work when a unit is retired?
• What happens to its preventive maintenance, history, documents, bill of materials and costs?
• Can a successor relationship be recorded between the retired unit and its replacement?

Related reading

For the broader buying question about equipment-focused products: equipment maintenance software. For the terminology question underneath the category names: CMMS vs maintenance management software. Where individual job control stops being enough: CMMS vs work order software. Where maintenance evidence becomes lifecycle and investment decisions: CMMS vs asset management software. And for the discipline itself: asset maintenance management.