Preventive Maintenance Software: How to Choose the Right One

Search for preventive maintenance software and you will get a wall of results that all look interchangeable: work orders, PM schedules, a phone in a technician's hand, a dashboard with a green compliance gauge. Sit through six of those demos, as I have with clients many times over, and you will not be able to tell them apart from the demo alone. That is by design. Every product in this market demos well, because the demo is built from clean data, on a happy path, by someone who knows the software intimately. The differences that decide whether your PM programme survives its second year are almost never the things the demo shows you. This guide is about those differences.

The message up front: preventive maintenance software is not its own category, it is a CMMS (or the PM module inside a CAFM or EAM). The buying decision is not "which product has the most features", it is "which product matches the size, literacy and connectivity of my actual maintenance team, and can carry the PM library I intend to build". Over-buying is far more common than under-buying, and the single biggest cause of failed implementations is choosing a platform whose administrative burden exceeds the organisation's capacity to carry it.

1. What preventive maintenance software actually is

There is no software category called PM software. There is a function called preventive maintenance, and there are three classes of system that contain it:

• A CMMS. This is what most people mean when they search for preventive maintenance software. A computerised maintenance management system exists to run maintenance work: asset register, work orders, PM schedules, spare parts, contractors, reporting. Preventive maintenance is its central mechanism, not a bolt-on. If maintenance is your problem, a CMMS is almost certainly your answer. MaintainX, Limble, Fiix, UpKeep and eMaint all sit here.
• The PM module of a CAFM or IWMS. If you run buildings with end users who log helpdesk tickets and book rooms, and preventive maintenance is one workstream among cleaning, security, space and soft services, then the PM capability arrives inside a facilities platform. Planon and Archibus are the obvious examples. The PM engine is usually competent but rarely as deep as a dedicated CMMS, and that trade is often correct because you are buying breadth on purpose.
• The PM module of an EAM or ERP. At the enterprise end, preventive maintenance is one discipline inside enterprise asset management: IBM Maximo, Hexagon EAM, Infor EAM, SAP PM. Here the PM engine is genuinely deep (job plans, task lists, hierarchical routes, meter and condition triggers, forecasting, reliability linkage) and the cost of that depth is configuration effort and administrative overhead that a small team cannot absorb.

Getting this framing right saves you from the most expensive mistake in the market, which is buying an EAM to solve a CMMS problem. If you are not sure which of the three you are shopping for, the category comparison in CAFM vs CMMS vs EAM vs IWMS is the place to start, and which one is right for you walks the decision. For the maintenance discipline itself, independent of software, the complete guide to preventive maintenance is the pillar this article sits under.

2. What a PM engine has to do, mechanically

Strip away the interface and a preventive maintenance engine does five mechanical things. If you understand these, you can interrogate any product properly.

• Hold a PM master. A reusable definition of a recurring job: what asset or asset class it applies to, what work is done, which trade does it, how long it takes, what parts and tools it needs, what safety controls apply. The PM master is the template; everything else is generation and execution.
• Attach a job plan or task list. The actual steps the technician performs, ideally with a readings or acceptance field per step rather than a single free-text comment box at the end.
• Trigger on time, meter or condition. Calendar-based (every 90 days), meter-based (every 500 running hours), condition-based (when a reading crosses a threshold), and ideally the combination with whichever comes first.
• Generate work orders on a forecast. Not just "create the work order on the day", but project the next twelve months of PM demand so planners can level the workload and budget the labour.
• Capture the result back. Completion date, actual labour, parts used, readings taken, findings, and where the PM revealed a defect, a follow-up corrective work order linked to the parent.

Almost every product claims all five. The variation is in the second, fourth and fifth, and those are exactly the ones a demo glosses over. In demos I have sat through, the forecast is frequently either absent or a list rather than a levelled projection, and task-level data capture is frequently a single notes field pretending to be a checklist.

3. The capability checklist that actually matters

This is the list I would work through with a client, in roughly the order of how often it decides the outcome. Treat it as the skeleton of your requirements document rather than a feature-tick exercise, because the phrasing of the question matters as much as the answer.

• PM masters and job plan reuse. Can one PM definition be applied to two hundred identical assets and then edited once, centrally, with the change flowing to all of them? If every asset needs its own copy of the schedule, your PM library becomes unmaintainable at a few hundred assets. This is the single most commonly underestimated requirement.
• Meter and condition triggers. Genuine meter-based PM requires meter readings to be captured, rolled up, and used to compute the next due date, plus handling for meter rollover and replacement. Ask to see a meter-triggered PM generate, not just a meter field on an asset form.
• Twelve-month forecasting and workload levelling. Can you see next year's PM labour demand by trade and by week, and shift work to smooth it? Without this you will discover every January that your statutory work all lands in the same month.
• Mobile execution that genuinely works offline. Not a responsive web page. A real app that holds the assigned work, the job plan, the asset history and the attachments on the device, lets a technician complete work in a basement plant room with no signal, and syncs cleanly on reconnection. Offline is the requirement that most often separates products in practice, and the one most often answered with a vague yes.
• Task-level acceptance criteria. Per-step pass/fail, numeric readings with limits, and the ability to force a follow-up when a step fails. A PM that records only "completed" is a compliance record, not an inspection.
• Failure and findings capture. Structured codes rather than free text, so the PM programme eventually tells you which PMs are finding defects and which are pure cost. Ask how the system links a PM finding to the corrective work order it spawned.
• Schedule compliance reporting. PM compliance measured properly, against the due date and an agreed grace window, not against "completed at some point". Ask exactly how the product calculates it, because the definitions vary and a generous definition flatters everybody.
• Parts and inventory linkage. The kit of parts attached to the PM, reserved or issued against the work order, with consumption feeding reorder points. Weak inventory is tolerable in a small operation and crippling in a large one.
• Permits, safety and statutory evidence. If you operate under permit-to-work, or have to produce an inspection audit trail to a regulator or insurer, that has to live in the same system as the work, with signatures and timestamps.
• Integration to ERP, procurement and building systems. A documented API, and ideally a track record of the specific integrations you need: purchase requisitions to finance, asset and cost centre masters inward, BMS or SCADA readings for condition triggers. Ask for API documentation before the contract, not after.
• Multi-site structure and permissions. Site hierarchy, per-site data segregation, role-based access, and reporting that rolls up across sites without letting every site see every other site's work.
• Configurability without a developer. Can an administrator add a field, change a workflow status, or build a report, or does each change become a vendor change request with a fee and a queue?

Two more items belong on the list even though they are not features. First, the quality of the vendor's data import tooling, because your implementation is mostly a data migration. Second, how work order types are modelled, since a PM programme that cannot distinguish a planned inspection from a corrective follow-up cannot report on itself honestly. The taxonomy is covered in work order types in a CMMS.

4. A scoring table you can lift

Requirements documents that list two hundred features with equal weight are worse than useless, because they let a product win on volume. What works better is a short weighted scorecard where the weights are argued about before any demo is booked. Below is the frame I would start from. Adjust the weights to your operation, but keep the list short enough that every line gets a real conversation.

Two rules make this scorecard useful rather than decorative. Score only what you have seen with your own data, and record who scored it. A five awarded on the strength of a vendor statement is not a score, it is a hope.

5. The landscape, honestly described

Products move, get acquired and reposition, so treat any named list as a starting map rather than a ranking. What is stable is the shape of the tiers.

If you want the individual product write-ups rather than the tier view, I have separate introductions to MaintainX, Limble, Fiix, UpKeep and eMaint, plus a consolidated buyer shortlist. For very small operations, best CMMS for small teams is the narrower comparison.

6. Pricing models and what actually drives cost

I am deliberately not going to quote figures. Published prices in this market change, discounting is heavy and regional, and any number I write here will be wrong by the time you read it. What is stable and genuinely useful is the structure of how you get charged and what pushes the number up.

The pricing models you will encounter:

• Per named user per month. The dominant mid-market model. Watch the distinction between a full user, a technician user, and a request-only or view-only user, because the count of full seats is what actually drives the invoice.
• Tiered feature bundles. Common alongside per-user pricing. The feature you care about most (usually integration, advanced reporting, or single sign-on) tends to live in the tier above the one you were quoted.
• Per asset or per site. Used by some facilities-oriented platforms. Predictable if your estate is stable, punishing if you are growing or if your asset register is about to be cleaned up and grow by a third.
• Enterprise subscription or perpetual plus maintenance. The EAM end of the market, negotiated rather than listed, usually with an annual support percentage on top and a separate implementation contract.
• Consumption or module-based. Increasingly common in cloud platforms, where mobile users, storage, API calls or specific modules meter separately. This is where budgets quietly drift.

The cost drivers that matter more than the licence:

• Data migration and asset register preparation. Almost always the largest single line of internal effort, and almost always underestimated, because the asset data is worse than anyone admits until someone tries to load it.
• PM library build. Writing or importing the job plans, task steps and frequencies. If you are building a few hundred PM masters properly, this is weeks of skilled maintenance-planner time, not an afternoon of data entry.
• Integration. Every interface to finance, procurement, HR or a building management system is a small project with its own testing and its own ongoing maintenance. Two integrations can cost more than the software.
• Training and change management. Especially for platforms with a steeper interface. Technician adoption is the make-or-break variable and it is bought with training time, not licences.
• Internal administration. The ongoing fraction of a person needed to keep the system healthy. On enterprise platforms this is frequently a full role, and it rarely appears in the business case.
• Configuration changes over time. If every field change is a vendor change request, the five-year cost is materially higher than the five-year licence total.

The honest way to compare is a five-year total cost that includes internal effort priced at real day rates. That comparison frequently reverses the ranking you get from licence cost alone: the cheaper licence with the heavier administrative burden often loses. For a fuller treatment of cost structure in this space, see CAFM pricing and implementation cost.

7. Deployment realities nobody demos

The gap between a signed contract and a working PM programme is where most of the disappointment in this market lives. Four realities are worth going in with your eyes open about.

Your asset register is the project. Not the software. The asset information discipline described in ISO 55000 is a useful reference here, even for organisations with no intention of certifying. If assets are not uniquely identified, hierarchically structured, and located, then PM schedules have nothing reliable to attach to. Teams that start by cleaning and structuring the asset register get a working system; teams that start by configuring the software get a working system with unusable data in it.

Cloud is the default, and the question is now about connectivity and data residency rather than hosting preference. Ask specifically what happens in your worst-connected plant room, and whether any regulatory or contractual constraint requires data to stay in a particular jurisdiction. Those two answers matter; a philosophical cloud-versus-on-premise debate usually does not.

Mobile adoption decides everything downstream. Every report, every compliance figure, every reliability insight is downstream of whether technicians actually complete work in the app rather than on paper that someone types up on Friday. Test the app on the oldest phone your team carries, in the worst signal location you have, with a technician who did not attend the demo.

Phase the PM library, do not big-bang it. Where a recognised task library exists for your asset classes, such as the building-services maintenance specification published by SFG20 , starting from it is faster and more defensible than writing every job plan from scratch. Load the PM masters for your critical assets first, run them for a quarter, fix what the first cycle reveals, then extend. A full PM library loaded on day one is a full PM library of untested assumptions generating work orders nobody can complete.

The implementation failure patterns are consistent enough across platforms that they are worth reading as a set: common implementation mistakes covers the ones I see most.

8. How to run a short evaluation that actually separates products

A six-month selection process usually produces a worse decision than a six-week one, because the long process substitutes documentation for evidence. The structure I would recommend:

• Week 1: agree the weighted scorecard. Fourteen lines, weights argued out between maintenance, operations, finance and IT before any vendor is contacted. If you cannot agree the weights internally, you are not ready to evaluate.
• Week 1: prepare a real data sample. Fifty of your own assets across three asset classes, ten of your own PM definitions including one meter-based, and your actual site structure. This sample is the whole evaluation.
• Week 2: longlist to four. Screen on tier fit, not features. If your team has half an administrator, enterprise EAM does not make the list regardless of capability.
• Weeks 3-4: scripted demos with your data. Send every vendor the same script in advance and insist they load your sample. No generic demo. The script should force them to build a PM master, apply it to multiple assets, generate and forecast, execute it offline on a phone, fail a task step, spawn a corrective work order, and produce the compliance report.
• Week 5: trial with real technicians. Two products, a sandbox each, a handful of technicians running genuine work for a week. Adoption evidence beats every other input and this is the only way to get it.
• Week 5: reference calls you chose. Ask for references at your size, in your sector, and ask them three questions: what took longer than expected, what do you still do outside the system, and what would you do differently.
• Week 6: five-year total cost and decide. Licences, implementation, integration, training and internal administration, priced honestly, then score and commit.

The scripted demo is the step that does the most work. It is remarkable how much a product reveals when it has to perform a specific sequence on unfamiliar data, and how many capabilities that were confidently confirmed in writing turn out to need a workaround. If the process needs to be formal, how to write an RFP for this kind of platform covers the documentation side.

9. Vendor marketing games to watch for

None of this is dishonesty exactly. It is the ordinary compression of a complicated product into a sales message. Knowing the patterns just means you ask the second question.

• "Fully offline mobile." Ask what is cached: only the assigned work order, or the asset history, attachments, manuals and job plans too? And what happens to two technicians who edited the same record offline?
• "AI-powered predictive maintenance." In most mid-market products this means threshold alerts and trend charts, which are useful and are not prediction. Ask what data the model is trained on and what it outputs. Condition-based alerting sold as failure prediction is the most common overstatement in this market right now.
• "Integrates with everything." A REST API is a capability, not an integration. Ask for a named customer running the specific interface you need, and ask who maintains it when either end upgrades.
• "Implementation in two weeks." Sometimes true for the software configuration. Never true for the asset register and the PM library, which is where your project time actually goes.
• "98 percent PM compliance across our customers." Ask how compliance is defined in the product. Measured against completion rather than due date, with an open grace window, almost any system reports high compliance.
• "Unlimited users." Check which user class is unlimited. It is usually the requester or view-only class, not the technician or full user class.
• "Configurable, no code." Ask which specific changes an in-house administrator can make, and which come back as a paid change request. The boundary is the thing that matters.

10. When the answer is not to buy software

This is the section most buyer guides leave out, and it applies more often than the market would like.

If you have fewer than about fifty assets, one or two technicians, and a stable set of a dozen recurring tasks, a well-kept shared spreadsheet plus calendar reminders may genuinely be adequate, and software will add administrative overhead without adding control. The tipping point is not asset count alone; it is when you can no longer answer, from memory, what is due this week and what was missed last month.

If your asset register does not exist in any form, buying software first is the wrong sequence. Build the register, even in a spreadsheet, get the hierarchy and identification right, then buy. The software will not create discipline you do not have; it will document its absence in more detail.

And if the real problem is that maintenance work is being done but not recorded, or that PMs are being signed off without being performed, no platform fixes that. That is a supervision and culture problem, and a new system will simply produce more precise evidence of it. I would rather tell a client that at the start than have them discover it after a procurement.

The idea to walk away with

Preventive maintenance software is a CMMS, or a PM module inside a larger platform, and the decision is a fit decision rather than a feature decision. Match the tier to your administrative capacity, score a short weighted list against your own data, insist on seeing offline mobile execution and task-level capture with your own hands, and price five years including internal effort. Do that and you will make a defensible choice from four products in six weeks.

The failures I see are not caused by picking the wrong product from a good shortlist. They are caused by buying a platform heavier than the organisation can administer, starting configuration before the asset register was fixed, loading an untested PM library all at once, and accepting written confirmations instead of demonstrated behaviour. Every one of those is avoidable, and none of them depends on which logo you choose.

Final thoughts

If you take one operational step from this article, make it the scripted demo with your own data. Fifty of your assets, ten of your PMs, one fixed sequence every vendor has to perform. It costs you a day of preparation and it will tell you more than a month of documentation review, because it replaces claims with observed behaviour. The second step, almost as valuable, is pricing the internal administration honestly in the business case, because that is the line that decides whether the system is still healthy in year three.

Beyond that, resist the pull toward capability you will not use. The market rewards breadth in its marketing and punishes it in your implementation. The smallest platform that genuinely covers your PM programme, your integrations and your compliance obligations is almost always the right answer, and you can move up later from a clean asset register far more easily than you can move down from a platform nobody can administer.

A note on independence. This guide is written from 22+ years of implementation and advisory work across CMMS, CAFM, EAM and ERP platforms. Products are named because they are genuine examples of their category tier, not because of any commercial arrangement. It is not a paid review, and no vendor has had editorial input into, or a commercial relationship with, this publication. There are no affiliate links, no referral fees and no reseller arrangements behind any name mentioned above. Where I have avoided quoting prices, it is because I cannot verify them as current; get a written quote scoped to your own requirements.

Related reading: Preventive maintenance: the complete guide, Best CMMS software: buyer shortlist, Best CMMS for small teams, CAFM vs CMMS vs EAM vs IWMS, Pricing and implementation cost, How to write an RFP.