Predictive maintenance is the logical evolution beyond preventive maintenance. Instead of changing a bearing on a calendar schedule whether it needs it or not, you change it when sensor data tells you failure is approaching. In theory, this eliminates unnecessary maintenance and prevents unexpected breakdowns simultaneously.
In practice, most companies that buy IoT sensors never get actionable data from them. The gap between a successful pilot and production deployment is where projects die. Sensors get installed, dashboards get built, and then nobody knows what to do with the data — or the data quality is too poor to act on.
This guide is for maintenance managers, reliability engineers, and operations directors who want to implement IoT-based predictive maintenance that actually works — not a showcase project that impresses visitors but does not reduce downtime.
Condition-Based vs Predictive Maintenance: Get the Terms Right
The industry uses predictive maintenance (PdM) and condition-based maintenance (CBM) interchangeably, but they are meaningfully different. Getting this distinction right will save you from buying more sophisticated technology than you actually need.
Condition-based maintenance triggers a maintenance action when a sensor reading crosses a defined threshold. A vibration sensor on a pump detects that vibration amplitude has exceeded 8 mm/s — the work order is created automatically. The logic is simple: sensor value crosses threshold, action is taken. No machine learning required.
Predictive maintenance uses historical sensor data and machine learning models to predict when a failure will occur — not just that a threshold has been crossed, but that the bearing is likely to fail within the next 14 days based on the rate of change in vibration signature. This requires months of baseline data, failure history to train the model, and ongoing data science work to maintain model accuracy.
Most companies that think they need predictive maintenance actually need condition-based maintenance first. CBM is achievable with off-the-shelf sensors and basic CMMS rules. Full PdM requires data infrastructure, a baseline dataset, and usually a specialist partner. Start with CBM. Once it is working reliably, you have the data foundation to build toward true prediction.
Which Assets Are Worth Monitoring with IoT
Not every asset justifies the cost of continuous IoT monitoring. The ROI calculation is straightforward: cost of sensor plus connectivity plus analysis infrastructure versus cost of unexpected failure.
Rotating equipment is the highest-value target for IoT monitoring. Motors, compressors, fans, and pumps exhibit characteristic failure signatures in vibration and temperature data before they fail catastrophically. A bearing in early failure shows increased vibration at specific frequencies weeks before the bearing seizes. A motor with developing insulation breakdown shows abnormal current draw before it trips. These signatures are detectable and actionable.
Critical HVAC equipment — particularly in environments where HVAC failure has process or compliance implications — is a strong second category. Chiller compressors, cooling towers, and air handlers in cleanrooms, pharmaceutical facilities, or hospitals carry significant failure costs beyond the repair itself.
Production equipment with long lead-time parts is another clear candidate. If a critical gearbox takes 14 weeks to procure, knowing it is approaching failure with 3 weeks of lead time fundamentally changes your response options. The sensor investment pays back in avoided emergency procurement costs alone.
The assets that do not justify IoT monitoring are those with low replacement costs, short lead times, or failure modes that IoT sensors cannot detect. A failed light fixture is not an IoT problem. A V-belt that snaps without warning is a spares inventory problem, not a sensor problem. Apply IoT where the failure mode is detectable, the failure cost is significant, and the lead time for parts or response creates the real business risk.
Sensor Types and What They Actually Tell You
Vibration sensors are the workhorse of predictive maintenance programs. Accelerometers mounted on bearing housings measure vibration in the time domain and frequency domain. Frequency analysis — specifically, fast Fourier transform of the vibration signal — reveals bearing defect frequencies, imbalance, misalignment, and looseness. A good vibration analyst can diagnose specific mechanical faults from the spectral signature. Modern IoT platforms do this automatically.
Temperature sensors are low-cost and provide broad coverage across electrical panels, motor housings, and bearing surfaces. An abnormally hot motor bearing or a switchgear bus bar running 15 degrees above baseline is an early failure indicator that thermal sensors catch before it becomes a breakdown. Infrared thermography cameras provide non-contact thermal imaging for surveys of large electrical panels — useful for periodic inspection, less so for continuous monitoring.
Current sensors on motor inputs detect degradation in motor winding insulation, rotor bar failures, and load changes that indicate driven equipment problems. A pump cavitating will show a characteristic current signature. A gearbox developing a fault will change the load pattern on the driving motor. Current monitoring is often overlooked because it seems indirect, but it requires no physical access to the driven equipment.
Ultrasound sensors detect high-frequency sound from compressed gas or steam leaks, early bearing failure, and electrical arcing. They are particularly valuable for detecting failures in components that are inaccessible for direct contact monitoring. Airborne ultrasound can find a steam trap that is failing open — wasting energy and process steam — before it shows up on any other measurement.
Oil analysis is not a real-time IoT technology, but it deserves mention as a condition monitoring technique. Sending oil samples to a laboratory on a regular schedule reveals metal particle content (indicating internal wear), water contamination, additive depletion, and viscosity changes. For large gearboxes, compressors, and turbines, oil analysis is the highest-confidence failure prediction method available.
CMMS Platforms with Native IoT Integration
A sensor that generates an alert which a technician then manually creates a work order from is not a predictive maintenance system — it is a dashboard with extra steps. The value of IoT in maintenance comes from automatic work order creation triggered by sensor conditions, with relevant sensor data attached to the work order for the technician to review on arrival.
IBM Maximo Application Suite integrates with Watson IoT Platform and can ingest sensor data from any IoT source to trigger work orders, condition monitoring rules, and asset health calculations. For large industrial operations already using Maximo, the IoT extension is the natural path.
Facilio was built from the ground up for IoT-connected building and facilities management. Its sensor integration layer is more flexible than Maximo's for building systems, and its work order triggering logic is simpler to configure. Strong in commercial real estate and large facility portfolios.
Fiix CMMS has a sensor-triggered work order module that works with common industrial IoT platforms. It is more accessible than Maximo for mid-market manufacturers and has a deployment track record across food and beverage, pharmaceutical, and general manufacturing environments.
Infraspeak's IoT module connects to building automation systems and environmental sensors commonly found in commercial and industrial facilities in Spain and Portugal. Its alert-to-work-order flow is straightforward, and the platform's mobile app means technicians receive IoT-triggered work orders directly on their phones.
HxGN EAM supports industrial IoT integration through its condition monitoring module, with specific strength in energy and utilities, mining, and heavy industrial environments where EAM is already the asset management standard.
Your First 90 Days: A Realistic Implementation Timeline
Month one is about identifying your pilot assets and establishing baselines. Pick three to five assets — not twenty. Choose equipment where you have existing failure history, where the failure consequences are significant, and where you can physically access the mounting points for sensors. Install sensors, verify data is transmitting, and spend the first two weeks doing nothing except watching the baseline data come in.
This baseline period is the step most implementations skip. You cannot set meaningful alert thresholds without knowing what normal looks like. A motor that runs at 6 mm/s vibration under normal load needs a different alert threshold than one that runs at 2 mm/s. The baseline establishes the normal operating envelope for each specific asset.
Month two is validation. Manually inspect the pilot assets on a schedule you would have used under your preventive maintenance program. Compare what the sensors are telling you against what the physical inspection reveals. If sensors are showing normal and inspection reveals developing wear, your sensor placement or sensitivity needs adjustment. If sensors are alarming and inspection shows nothing, your thresholds are too sensitive. This validation step is the difference between a working program and an alert-fatigue problem.
Month three is where you build the alert rules and connect sensor conditions to CMMS work order creation. With two months of baseline data and validated sensor placement, you can now set thresholds that reflect real asset behavior. Configure the work order creation rules in your CMMS, assign the triggered work orders to the appropriate technician or team, and run the system in parallel with your existing PM program for one month before trusting it as the primary maintenance trigger for those assets.
Why Most IoT Projects Fail — and How to Avoid It
The most common reason IoT predictive maintenance projects fail is that the sensor data never gets connected to maintenance action. Sensors generate data. Data generates alerts. Alerts go to dashboards that nobody checks regularly enough to respond in time. And when a technician does respond, they have no context — just an alert number with no history, no previous readings, and no guidance on what to do next.
The second common failure is scope. A plant manager sees a vendor pitch for 200 sensors across a facility and wants to do it all at once. A 200-sensor rollout in a 90-day project is a project management problem masquerading as a technology problem. Start with five sensors on three assets. Get those working end-to-end — sensor data, automatic work order, technician response, closure with findings recorded in the CMMS asset history. Then scale.
The maintenance programs that succeed with IoT are not the ones with the most sensors. They are the ones where every sensor data point ultimately connects to a maintenance action tracked in the CMMS.