How to Build a Preventive Maintenance Program in a CMMS

Someone opens the preventive maintenance screen in a new CMMS. The form asks for an asset, a job plan, a frequency, a next due date, a meter, a lead time, a season and a status. Each field has a small label and an empty box.

The form looks administrative. Most of it is not.

Configuration choices that look administrative can change the maintenance program physically experienced by the asset.

A frequency of 30 days is a decision that this maintenance action should recur on a 30-day basis. A setting that calculates the next occurrence from the previous target date rather than the previous completion date changes every future date on the schedule. A generation lead time changes when the work enters the planning system. A job-plan sequence can change which scope of work reaches the technician on different repetitions.

Building a preventive-maintenance program in a CMMS means translating maintenance reasoning into software rules that will be repeated over and over. The difficult part is not making work recur. It is preserving why the work exists, making the recurrence behave as intended, capturing what each occurrence teaches, and changing or retiring the rule when the evidence changes.

The CMMS does not merely store the PM program. Once activated, it executes the program's assumptions over and over again.

This guide follows one fictional asset through that translation. Pump P-104 has been identified for recurring preventive maintenance, and someone has proposed a sentence that sounds complete:

Inspect and lubricate P-104 every 30 days.

That sentence contains at least a dozen unresolved decisions. Why does this task exist? What failure or condition is it meant to address? Why inspection, and why lubrication? Why 30 days rather than 45, or 500 operating hours? What does “every 30 days” mean when the work is completed late? What should the technician record? What happens when the inspection finds a problem, when twenty inspections find nothing, and when P-104 fails between two PMs? Who can change the interval, and can anyone later determine why it changed?

“Every 30 days” is the end of several maintenance decisions, not the beginning.

Start With the Maintenance Reason, Not the Frequency Field

PM design does not begin with “how often should we PM this asset?” That question assumes the answers to four earlier ones:

• What function or required performance matters on this asset?
• What failure, degradation or condition are we trying to prevent, detect or manage?
• What recurring task is applicable to that problem?
• Why is predetermined intervention appropriate here rather than repair on failure or condition monitoring?

NASA's reliability-centered maintenance guidance states the screening criteria plainly: tasks must be applicable, meaning they address the failure mode and consider its characteristics, and tasks must be effective, meaning they reduce the probability of failure and are cost-effective.[1] The same guidance notes that the selection process guides which type of task is done but is less helpful in establishing task frequency.[1]

Nothing here requires every organization to perform formal RCM analysis before creating every PM. Many recurring tasks are justified by manufacturer guidance, a regulatory requirement or hard-won operating experience. The principle is narrower and harder to argue with: recurring maintenance should have a reason, and someone should be able to state it.

A CMMS can make a PM repeatable without making it justified.

Automation increases the persistence of a maintenance decision. That makes the quality of the original decision more important, not less. A weak decision executed once is a wasted afternoon. The same decision encoded as a recurring rule is a standing claim on labor, parts, access and equipment availability for as long as the rule remains active.

The chain below is how this guide describes the translation from maintenance reasoning into software behavior. It is an explanatory model used by CMMSBuyersGuide, not a formal industry standard.

MAINTENANCE REASON ↓ TASK ↓ TRIGGER ↓ INTERVAL / THRESHOLD ↓ CMMS RECURRENCE LOGIC ↓ GENERATED WORK

Most PM programs that disappoint their owners were built from the bottom of that chain upward. Someone chose a frequency, attached a task list, and the reason was never written down.

If you are still deciding whether preventive intervention is the right strategy for a given failure behavior at all, that question comes before this guide. Our comparison of preventive and predictive maintenance covers how trigger logic and evidence differ between the two, and our guide to asset maintenance management covers how maintenance strategy attaches to the function an asset is expected to deliver.

Preserve Why the PM Exists

This guide uses the term PM provenance for a specific idea:

Provenance can come from several places, and this guide does not rank them universally:

• Manufacturer or OEM guidance
• Regulatory, insurance or statutory inspection requirements
• Engineering or reliability analysis
• Documented failure history on this asset or similar assets
• Operating experience at this site
• An internal maintenance standard applied across a class of assets
• Qualified technical judgment, recorded as such
• Another documented basis

No PM needs an academic dossier. The test is smaller: a maintainer arriving three years from now should have some way to understand why important recurring work exists.

Consider a record in the library:

PM-1027 — Lubricate bearing every 30 days.

Why lubrication? Why this bearing? Why 30 days? Who or what established that interval? If nobody can answer, the PM will still generate work orders on schedule, and every one of those work orders will consume real labor.

A recurring task without an understandable basis can become organizational folklore encoded as automation.

Task validity and interval validity are separate decisions

TASK VALIDITY ≠ INTERVAL VALIDITY

Lubricating that bearing may be entirely justified. Thirty days may still be the wrong number. The two questions have different evidence behind them, and confusing them makes PM review harder than it needs to be — a challenge to the interval gets defended as though it were a challenge to the task.

NASA's guidance treats interval as a separate and revisable variable. Its age exploration method varies key aspects of the maintenance program to optimize it, continually adjusting the task performance interval and reviewing whether the technical content of the tasks addresses the identified failure modes.[1]

Record the basis for the task and the basis for the interval separately, even if both are one sentence.

Choose the Trigger Before the Number

“Monthly or quarterly?” is rarely the first scheduling question. The first question is what exposure or event should cause this maintenance to become due.

Common predetermined trigger forms

TIME — elapsed calendar time since the previous occurrence or its target date.

USE — metered exposure such as runtime hours, mileage, cycles, starts or throughput.

EVENT OR OPERATING WINDOW — seasonal startup, shutdown, an annual outage, a production campaign or another operating event.

COMBINATION — for example, elapsed time or metered use, whichever reaches its threshold first.

IBM's Maximo documentation is a useful concrete example of how these appear in one product. It describes time-based PMs driven by elapsed time, meter-based PMs driven by metered asset usage, and combinations such as a PM that triggers work every six months or every 300 hours, whichever comes first.[3] Other systems express the same ideas with different terminology and different behavior, so treat this as one product's model rather than a universal one.

The same documentation shows how a combined trigger resolves in that product: a PM scheduled every 3,000 miles or three months compares an estimated next due date on the time-based subtab against one on the meter-based subtab and uses the earlier of the two.[5]

A metered trigger is still a predetermined trigger

METER-BASED ≠ CONDITION-BASED

A PM every 500 operating hours is predetermined maintenance. Usage is the trigger, but the decision to intervene was still made in advance, before anyone looked at the machine. Condition-based work responds to an observed condition. Our guide to preventive versus predictive maintenance works through where that line sits and why metered triggers are often mistaken for condition evidence.

A sophisticated trigger rule is still a rule.

A PM trigger is a claim about what kind of exposure or event matters to the maintenance need. Runtime hours matter when wear tracks operation. Calendar time matters when degradation continues while the asset sits — moisture, contamination, seal ageing, fluid degradation, regulatory clocks. Calendar triggers are not a lesser choice. Sometimes elapsed time is exactly what matters, and a meter would be the wrong claim.

Define What “Every 30 Days” Means

This is the section most PM implementations skip, and the one that most changes the schedule an asset physically receives.

Maximo distinguishes fixed and floating schedules. On a fixed schedule, work is planned from the target start date of the previous work, and the target start increments by the specified frequency; multiple work orders can be created in advance. On a floating schedule, work is planned from the closure of the previous work, and a new work order cannot be generated until the current one is completed.[4] In that product, fixed-schedule PMs are scheduled from a Last Start Date value and floating-schedule PMs from a Last Completion Date value.[4]

Apply that to P-104. Frequency is 30 days. The January occurrence targets January 1. The work is completed on January 10.

Neither is universally correct. Fixed recurrence preserves an intended cadence and absorbs late execution without pushing the calendar; it can also stack work on a team that is already behind. Completion-based recurrence preserves elapsed time since the prior intervention, which matters when the interval represents real exposure between interventions; it also lets late execution move every future date.

Ask what exactly anchors the next occurrence in the system you are evaluating:

• The previous scheduled date
• The previous target start date
• The moment the physical work was performed
• The work-order completion status change
• Work-order closure, which may happen days after the work
• A meter reading, and if so, which reading and when it was captured
• Something else entirely

Drift is not inherently wrong. On a completion-anchored PM, drift is the intended behavior: the interval is meant to measure time since the last intervention. Drift becomes a problem when nobody chose it — when a program intended to hold an annual regulatory cadence slowly slides by six weeks a year because the recurrence anchor was left at its default.

Choose recurrence logic because it represents the maintenance requirement, not because it is the software default.

Recurrence can depend on workflow behavior

There is a dependency here worth surfacing during evaluation. Maximo's floating schedules do not generate the next work order until the current one is completed.[4] Where recurrence works that way, administrative behavior influences future maintenance timing: a work order that sat uncompleted for three weeks after the physical work was finished has moved the next occurrence by three weeks.

Not all systems behave this way, and some allow the anchor to be set independently of workflow status. The point is to find out, before the program is built on top of the assumption.

TWO CLOCKS PHYSICAL MAINTENANCE CLOCK When the maintenance was physically performed on the asset. CMMS RECURRENCE CLOCK The event or value the software uses to calculate the next occurrence.

Ask whether those two clocks can diverge in the system and process you are choosing, and by how much. Our guide to maintenance tracking covers the related problem of completion records that describe administrative events rather than physical ones.

Separate the Due Date From the Planning Time

DUE DATE ≠ GENERATION DATE MAINTENANCE INTERVAL ≠ PLANNING HORIZON

A PM may be due on June 30 and generated on June 1, so the organization has four weeks to plan the job, obtain material, coordinate equipment access, schedule labor and prepare permits or isolation requirements.

Maximo describes lead time as an amount of time specified on the PM record so that work orders are generated in advance of their next due dates, and distinguishes lead time added to a single top-level PM for gathering tools and materials from slack time used to generate weekly or monthly batches of work orders.[6]

Creating work early should create planning time, not silently redefine when the maintenance is due.

Where early generation also moves the due date, two things break at once. Technicians see work presented as due before it is. Compliance reporting measures execution against a date the maintenance decision never specified.

The planning horizon is a planning decision, and it belongs with the rest of them. Our guide to maintenance planning software covers what has to happen between generation and execution, and our guide to maintenance scheduling covers committing that work to specific people and dates.

“Annual” is several different requirements

Frequency words carry hidden operating windows. “Annual” can mean:

• Every 365 days from the previous occurrence
• Once in each calendar year, on any date
• Before the summer cooling season
• Before the winter heating season
• During the annual plant outage
• Before seasonal startup, whenever that falls this year

These are not equivalent requirements, and they fail differently. A PM completed in January and again in December satisfies “once each calendar year” and badly violates “every 365 days.”

Systems handle this with varying degrees of directness. Maximo supports seasonal PMs that are active only during specified seasons, allows multiple active seasons for a single PM, allows active days of the week to be set, and reschedules work that becomes due on an inactive day.[7] Its next-due logic also accounts for this: where a due date falls outside the active season, the system finds the earliest date inside the season instead.[5]

Frequency words such as monthly, quarterly and annual can hide the operating window that matters.

Design What Happens When Frequencies Collide

A realistic PM set for one asset looks like this:

In December, all three become due in the same period. What reaches the technician?

Programs and products resolve this in different ways. Some create three separate work orders. Some use a higher-level job plan that already contains the lower-level scope. Some bundle the work under one parent. Some suppress overlapping scope. Some use sequence logic that selects a different job plan on different occurrences. There is no universal correct answer, and the answer you get by default is often nobody's decision.

Maximo's job plan sequences are a clear product example of one approach. Multiple job plans can be assigned to a PM, and sequence numbers determine how often each plan is used; its documentation illustrates a monthly basic turbine inspection, a quarterly inspection of components, and a yearly inspection of the turbine and its feeder system, with the system selecting the job plan with the highest sequence number that divides evenly into a counter incremented at each generation.[8]

RECURRENCE FREQUENCY ≠ TASK FREQUENCY

“This PM runs monthly” does not mean identical work occurs every month. The recurrence is monthly; the scope may rotate. Understanding that distinction changes how a PM library is designed, because a rotating-scope PM and three separate PMs produce very different history, different compliance records and different failure analysis later.

Frequency design is also scope design.

Distinguish the PM Definition From One Occurrence

PM TEMPLATE / DEFINITION ≠ GENERATED WORK ORDER

The recurring PM is logic that may generate a hundred future occurrences. A generated work order is one occurrence. They live in different applications, carry different permissions in most systems, and changing one has nothing to do with changing the other.

Maximo describes PM records as templates for scheduled preventive maintenance work that are used to generate work orders, with information associated with the PM becoming part of the generated work-order records.[3] It also describes how a job plan applied to a work order becomes the work plan on that work order.[12] Editing the work plan on a single generated work order and editing the job plan that future work will inherit are separate actions.

Changing today's work order and changing the rule that may generate the next 100 work orders are very different actions.

This matters because the error is silent. A supervisor who adds a step to today's work order, believing they have improved the PM, has improved nothing beyond today. A planner who edits the job plan, believing they are correcting one job, has changed the program.

Our guide to how work orders flow through a CMMS covers what happens to that generated work order from release through completion and follow-up.

Ask What Happens to Work That Already Exists

Suppose the system has generated six months of future PM work orders. The organization then changes the PM definition — a new task, a different interval, a revised job plan.

• Do the already-generated future work orders change?
• Do they retain the old scope?
• Can they be refreshed or regenerated against the new definition?
• Does only newly generated work use the new definition?
• Is any of this visible to the person making the change, at the moment they make it?

Behavior varies, and the same system may behave differently depending on whether the change is to the PM record, the job plan, or a master template. Do not assume; test.

Maximo's job plan revision control is one documented example of where the boundary sits in one product: when a job plan is revised, work orders with an existing job plan attached are not updated with the revised version.[13]

A change to recurring maintenance logic does not necessarily mean every work order already generated from that logic has changed.

Standardization Creates an Inheritance Problem

Larger organizations usually want common PM logic across many similar assets and sites, and also need legitimate local exceptions: a harsher duty cycle at one plant, a different regulatory regime, a modified machine.

Maximo's master PM model is a clear product example. Master PMs are templates used to create and update associated PMs and can be shared across sites and organizations.[10] Changes on a master can be applied to associated PMs — frequency, frequency units, alert lead, seasonal dates and job plan sequences are each governed by their own update options — and in the Preventive Maintenance application, an associated PM with the Override Updates from Master PM check box selected is not affected in its schedule by the master.[11]

The general buyer problem sits above any one product:

Standardization and local exception are both legitimate requirements. The system needs a way to distinguish them.

Without that distinction, one of two failures follows. Either a central update quietly overwrites a locally justified interval, or every site protects everything from updates and the standard becomes decorative.

• Can one standard PM definition feed many assets?
• Which attributes inherit, and which do not?
• Can a local exception be protected from central updates?
• What happens to associated records when the master changes?
• Can a user tell whether a value is inherited or locally overridden, by looking at the record?
• Can the organization produce a list of PMs that have diverged from the standard?
• Is the reason for a local exception recorded anywhere the next maintainer will find it?

Capture What the PM Reveals

A PM occurrence should produce more than the word COMPLETE. Three layers of evidence are worth designing deliberately.

Execution evidence

Did the work occur, when, by whom, and what scope was performed? This is the layer most systems handle by default.

Finding evidence

What did the technician observe? Normal condition, early degradation, a defect, a measurement, an adjustment made in passing, a part that was nearly out of tolerance. Findings are the only output of a PM program that can tell you whether the program is aimed at anything real.

Outcome evidence

What followed? No action, corrective work, a follow-up inspection, a failure, a revision to the PM itself, or a change of strategy.

Completion tells you whether maintenance happened. Findings tell you what maintenance saw.

A PM should capture enough evidence to distinguish “the task was performed” from “what the task revealed.” That does not mean prescribing specific database fields, and it does not mean burying technicians in forms. It means deciding, at design time, which observations from this task would change a future decision, and making those the ones the system asks for.

Field capture quality decides whether any of this survives contact with a plant floor. Our guide to mobile CMMS covers what technicians can realistically record at the asset, and our guide to maintenance tracking covers how that record becomes retrievable history.

Do Not Confuse PM Compliance With PM Validity

A dashboard reports PM COMPLIANCE: 97%.

That number is useful. It describes execution against the PM program as defined: whether scheduled work was performed, and performed within whatever window the organization set. Teams that cannot hold a schedule cannot learn anything from one, so the metric earns its place.

What 97% does not independently establish:

• That the right tasks were selected
• That the intervals are correct
• That the trigger reflects the exposure that matters
• That the task addresses the failure behavior it was created for
• That execution quality was good rather than merely recorded
• That the program is improving reliability

PM compliance is an execution metric, not a maintenance-strategy verdict.

A maintenance team can execute the wrong preventive-maintenance program with excellent compliance. The compliance figure will look better as the program becomes less demanding, which is worth remembering when it is used as a performance target.

PM PROGRAM QUALITY DESIGN — Are the recurring maintenance decisions defensible? EXECUTION — Are those decisions performed and documented properly? LEARNING — Does accumulated evidence influence the program when appropriate?

A mature PM program needs all three. Most maintenance reporting measures the middle one, because it is the easiest to count.

Repeated Normal Findings Are Evidence, Not an Answer

Return to P-104. Twenty consecutive monthly inspections have been completed. Every one records: normal.

What does that mean? Several readings are available, and the data alone does not choose among them:

• The equipment remained healthy, and the inspection is part of why
• The inspection remains justified because the consequence of failure warrants conservative monitoring regardless of findings
• The interval may be conservative, and a longer one might carry acceptable risk
• The task may have low discriminatory value — it would record “normal” whether or not degradation were present
• The recorded result may be too vague to distinguish those cases
• The failure behavior of concern may not be well addressed by this task at all
• Something else specific to this asset and its duty

Repeated normal findings are evidence. They are not an automatic recommendation.

A result is not the same thing as an interpretation. The most common mistake in PM optimization is treating twenty clean inspections as an argument for extending the interval, when a hidden protective function with severe consequences may be exactly the case where clean results are the point.

NASA's age exploration method is one documented approach to using accumulated evidence to reconsider intervals: the technical content of tasks is reviewed to ensure identified failure modes are addressed and existing tasks produce the desired reliability, and the task performance interval is continually adjusted until the rate at which resistance to failure declines is determined.[1] NASA's facilities guidance likewise describes RCM as an ongoing process that gathers data from operating system performance and uses that data to improve design and future maintenance.[2]

Failures Between PMs Are Part of the Learning Story

P-104 again. The PM is performed on January 1. A corrective failure occurs on January 18. The next PM is scheduled for January 31.

The reflex reading is that the PM failed. That reading is usually premature. The questions that matter:

• Was the failure the same failure mode the PM was designed to address?
• Was the PM intended to address it at all?
• Was the task technically capable of detecting or preventing it?
• Was the PM executed properly, and does the record show enough to tell?
• Did the operating context change — duty, load, environment, process conditions?
• Was the interval longer than the time available between detectable degradation and functional failure?

PM COMPLETED ≠ FAILURE PREVENTED FAILURE AFTER PM ≠ PM FAILURE

Some failures fall outside what any predetermined task could have caught. Some reveal that the interval is longer than the warning available. Some reveal that the task was aimed at the wrong component. These lead to different decisions, and the difference between them is only visible if the corrective work and the PM history can be examined together.

Our guide to equipment maintenance software covers how asset history has to be assembled for this kind of review to be possible at all.

More PM Is Not Automatically Better

Maintenance is itself an intervention. NASA's guidance is direct about the limits: the majority of equipment is not subject to wear-out at a specific operating age, timed maintenance can often result in unnecessary and in some cases harmful maintenance, and preventive maintenance can be costly and ineffective when it is the sole type of maintenance practiced.[1]

The intrusiveness of the task belongs in the decision alongside the risk being managed. Some tasks are close to free: a reading taken from outside the machine, a visual check on a running asset. Others require shutdown, isolation, opening equipment, disassembly, adjustment, replacement, reassembly and restart — each of which is an opportunity to introduce a problem that was not there before.

The goal is not to maximize preventive maintenance. It is to use preventive maintenance where predetermined intervention makes sense.

More maintenance activity is not the same thing as more reliability. None of this is an argument against preventive maintenance; it is the argument for designing it deliberately, which is what the rest of this guide is about.

Build a Learning Loop, Not Just a Work Loop

Every CMMS gives you the first loop. It runs whether or not anyone is paying attention.

WORK LOOP TRIGGER → GENERATE → PLAN → SCHEDULE → EXECUTE → RECORD → next occurrence

The second loop has to be designed, staffed and scheduled like any other work.

LEARNING LOOP FINDINGS / FAILURES / VARIANCE / FOLLOW-UP → REVIEW → DECIDE → RETAIN / REVISE / RETIRE / CHANGE STRATEGY → updated PM logic

A CMMS makes repetition easy. A preventive-maintenance program also needs a way to learn whether what it is repeating still makes sense.

Without a learning loop, old maintenance assumptions remain embedded in recurring software rules long after their original reasoning has been forgotten. The rules keep working. That is the problem: nothing breaks to tell you the reasoning expired.

The CMMS is not the decision-maker here. It should not automatically extend intervals because findings were clean, and it should not retire tasks because they rarely produce work. It should preserve the evidence people need to make those decisions, and make the review possible without a data project.

The CMMS should preserve the evidence needed for people to make the decision.

Know When to Revise or Retire a PM

PM libraries accumulate. Most have a well-worn creation path and no retirement path at all, which is why ten-year-old libraries contain recurring work for assets that were removed, tasks for components that were redesigned, and intervals nobody has defended since the original implementation.

A PM needs controlled ways to be revised, superseded, made inactive, retired or replaced by a different strategy, while preserving history where appropriate.

Status handling is one mechanism. Maximo, for example, documents PM statuses where work orders cannot be generated from a draft PM, an active PM generates work orders, and an inactive PM does not generate work orders and typically represents work discontinued temporarily or permanently, with inactive PMs able to be returned to active status.[9]

Reasons that can justify reviewing a PM include:

• Asset modification, replacement or rebuild
• A changed operating duty, load or environment
• New manufacturer guidance
• A changed regulatory or insurance requirement
• New failure experience on this asset or a similar one
• Persistent findings that keep producing the same corrective work
• Repeated corrective failures between occurrences
• New monitoring capability that makes condition evidence available
• Repeated normal findings, where review is appropriate for that consequence class
• Component or design changes that make the original task inapplicable

These are candidates for review, not automatic triggers for change.

A mature PM library needs retirement decisions as well as creation decisions.

A PM can remain perfectly configured in the CMMS while becoming wrong for the asset it now serves. Configuration validity and maintenance validity are unrelated properties, and only one of them is visible on the screen.

Preserve PM Change History

P-104's PM was originally set at every 500 operating hours. Two years later it is 750. Someone in a review meeting asks why.

• What changed?
• When did it change?
• Who changed it?
• What was the previous value?
• What happened to the next due calculation at the moment of the change?
• What happened to work orders that had already been generated?
• Why was it changed, if the organization records a reason anywhere?

The current PM tells you what the program says now. Change history should help explain how the recurring maintenance decision evolved.

Not every CMMS offers formal version control over PM records, and this guide does not claim one is required. What matters is knowing what change traceability exists before the program is built, because the alternative is a maintenance decision that can be altered by one person in one field with no durable record.

Historical work should stay interpretable

There is a second, quieter version of this problem. A work order completed in 2025 was generated under the job plan as it existed then. If the template has since been rewritten, can the organization still see the work plan that applied in 2025?

Some systems address this through revision control. Maximo's job plan revision function duplicates the job plan under the same name with an incremented revision number and saves a record of the changes, and work orders with an existing job plan attached are not updated with the revised version; the original moves to revised status and can no longer be changed.[13] Where no such mechanism exists, a compliance record or a failure investigation can end up describing work whose actual scope is no longer recoverable.

Historical work should remain interpretable after the recurring maintenance template changes.

Migrating an Existing PM Program

Most organizations are not starting from a blank sheet. The PM logic already exists — in a legacy CMMS, in spreadsheets, in paper procedures, in OEM manuals, in a regulated inspection program, in site standards, and in the heads of two people who have been there twenty years.

The risk is defining migration success as a count:

We imported 1,800 PM records.

An import moves records. It does not evaluate them, and a new system makes an old library's problems more durable rather than less. Migration is the one moment when the whole library is in someone's hands at once.

Where practical, use it to identify:

• PMs for assets that no longer exist or are no longer in service
• Duplicate recurring work created by two people for the same need
• PMs whose rationale nobody can state
• Incorrect or obsolete meters, or meters no longer being read
• Conflicting intervals for the same task across similar assets
• Task descriptions too generic to execute or to audit
• Procedures superseded by newer manufacturer or regulatory guidance
• PMs with legitimate local differences that must be preserved deliberately
• PMs that should be carried across exactly as they are

None of this assumes a legacy library is bad. Many contain hard-earned knowledge that no analysis would reproduce. The point is to separate the two kinds of content.

Migrating an old PM library can preserve old maintenance assumptions along with useful maintenance knowledge.

A PM migration is an opportunity to distinguish recurring maintenance knowledge from recurring maintenance clutter. A practical review format, which organizations can adapt rather than treat as required CMMS fields:

This is also the moment to settle asset structure, because a PM is only as sound as the asset it is attached to. Our guide to asset maintenance management covers how that hierarchy shapes everything attached to it.

A Practical Build Sequence

The sequence below is a practical CMMSBuyersGuide implementation order, not an industry-standard methodology. Its value is the order, which puts every software decision downstream of a maintenance decision.

1. Define the maintenance need. What function, condition or failure behavior makes recurring work worth considering?
2. Define the task. What recurring action addresses it, and is that action applicable to the failure mode?
3. Document the basis. Why does this task exist, and where did the reasoning come from?
4. Choose the trigger. Time, metered use, an operating event or window, a combination, or another justified trigger.
5. Set the interval or threshold, and record the basis for the number separately from the basis for the task.
6. Define recurrence behavior. What anchors the next occurrence, and how should late execution affect future timing?
7. Design overlapping scope. Decide what happens when monthly, quarterly and annual work coincide.
8. Set the planning horizon. How early should work be generated, and does that change the due date?
9. Build the executable job plan: tasks, procedures, materials, skills, tools, and safety or access requirements.
10. Define useful findings. What evidence should each occurrence produce beyond completion?
11. Define the exception and follow-up flow. What happens when a PM discovers additional maintenance need?
12. Test the software logic against realistic scenarios: late work, collisions, template changes, retirement, meter corrections.
13. Launch in controlled scope. Validate behavior on a limited set of assets before broad rollout.
14. Review the evidence. Look past completion at findings, follow-up work and failures between occurrences.
15. Retain, revise or retire deliberately, and keep the library alive rather than only growing.

Steps 12 and 13 are where most of the avoidable pain is prevented. Our guide to CMMS implementation covers how controlled rollout works alongside the rest of a deployment.

Buyer Questions for PM Capability

These questions are worth asking during demonstrations and reference calls. They follow the structure of this guide, so each one has a reason behind it.

PM design

• Can the system preserve why a recurring task exists, in a field a maintainer will find?
• Can task instructions link to a source procedure, manual section or regulatory reference?
• Can different maintenance strategies coexist on one asset — time-based, metered and condition-triggered work?
• Can a PM record who owns the recurring decision, not just who performs the work?

Triggers

• Which trigger types are supported: elapsed time, meters, events, operating windows?
• Can a single PM use more than one meter?
• How is a combined trigger resolved when two thresholds disagree?
• How are meter corrections and meter rollovers handled, and what do they do to the next due date?
• What happens when a meter stops being read?
• Can seasonal or event-based windows be expressed directly, or only approximated with dates?

Recurrence

• Are fixed and completion-based recurrence both available, and is the choice per PM?
• Exactly which event or value anchors the next due calculation?
• What happens to future dates when work is completed late?
• What happens when an occurrence is missed entirely — does it disappear, accumulate or block the next one?
• Can a schedule be reset deliberately, and is the reset recorded?
• Can recurrence be suspended without deleting the PM?

Scope

• Can different job plans occur at different frequencies under one recurring definition?
• What happens when monthly, quarterly and annual work become due together?
• Can duplicate or overlapping scope be suppressed or bundled?
• Can a PM generate a hierarchy of related work for a parent asset and its components?

Planning

• How early can work be generated ahead of the due date?
• Does early generation change the due date presented to technicians and to compliance reporting?
• Can future PM demand be forecast for labor and material planning?
• Can generated work be batched by week or period for planning purposes?

Templates and governance

• Can a master template feed many assets across sites?
• Can a local exception be protected against central updates?
• Can a user see whether a value is inherited or locally overridden?
• Can the organization list PMs that have diverged from the standard?
• Who can change PM logic, and is that permission separate from editing a work order?

Change control

• What happens to already-generated work orders when the PM definition changes?
• Can an interval change be reconstructed later — old value, new value, who and when?
• Can a reason for the change be recorded with the change?
• Can historical work orders retain the scope that applied when they were generated?

Execution

• What does the technician receive, and does it include the task detail and safety requirements?
• Can one occurrence be modified without altering the recurring definition?
• Can findings be recorded in a form that can be analyzed later rather than only as free text?
• Can a finding generate controlled follow-up work linked back to the PM occurrence?
• What happens to the schedule when an occurrence is cancelled rather than completed?

Learning

• Can a reviewer see findings across all occurrences of one PM?
• Can corrective work between PM occurrences be discovered from the PM or the asset?
• Can repeated findings be counted or compared without exporting data?
• Can a PM revision be related to the evidence that prompted it?
• Can PM cost and labor be seen alongside the corrective work on the same asset?

Retirement

• Can recurring generation stop without erasing history?
• Do retired PMs remain searchable and attributable to their historical work?
• Can a retired PM be reactivated, and is that visible?

Don't Just Ask Whether It Has PMs. Test the PM Logic.

Every CMMS has preventive maintenance. The differences show up in behavior, and behavior is only visible under test. Each of these can be run in a vendor demonstration or a trial environment.

Run these against the same asset in the same demo session. Our CMMS demo checklist covers how to structure that session so vendors demonstrate behavior rather than narrate features.

The Distinction Wall

PM DEFINITION ≠ GENERATED WORK ORDER TASK VALIDITY ≠ INTERVAL VALIDITY FREQUENCY ≠ TRIGGER LOGIC METER-BASED ≠ CONDITION-BASED DUE DATE ≠ GENERATION DATE MAINTENANCE INTERVAL ≠ PLANNING HORIZON FIXED RECURRENCE ≠ COMPLETION-BASED RECURRENCE RECURRENCE FREQUENCY ≠ TASK FREQUENCY PM COMPLETED ≠ PM EFFECTIVE PM COMPLIANCE ≠ PROGRAM VALIDATION NO FINDING ≠ NO VALUE FAILURE AFTER PM ≠ PM FAILURE PM COMPLETED ≠ FAILURE PREVENTED MORE PM ≠ MORE RELIABILITY CHANGING ONE WORK ORDER ≠ CHANGING THE PM ACTIVE PM ≠ STILL-JUSTIFIED PM

The PM Program Loop

This is how the pieces fit together. It is a CMMSBuyersGuide explanatory model, offered as a way to see where a program is incomplete.

MAINTENANCE REASON ↓ TASK ↓ TRIGGER ↓ CMMS LOGIC ↓ GENERATED WORK ↓ EXECUTION ↓ FINDING ↓ OUTCOME ↓ REVIEW ↓ RETAIN / REVISE / RETIRE / CHANGE STRATEGY ↓ back into future PM logic

A PM program is a maintenance decision that becomes executable software logic, produces physical work, produces evidence, and stays reviewable as that evidence accumulates. Programs usually break at one of two joints: between finding and review, where evidence is captured but never examined, and between review and revision, where the conclusion is reached but the rule is never changed.

Back to P-104

The guide started with one sentence:

Inspect and lubricate P-104 every 30 days.

By the end of a properly built program, the organization can say considerably more than that. Why the work exists and what failure or condition it addresses. Why inspection and lubrication were the tasks selected. What causes the work to become due, and whether that trigger reflects calendar exposure or operating exposure. What “30 days” anchors to, and what happens to the next date when the work runs late. How the monthly, quarterly and annual scopes behave when they coincide. How early the work enters planning, and whether that changes the due date. What the technician should record beyond completion. How a finding becomes controlled follow-up work. How a corrective failure between occurrences gets reviewed against the recurring task. Who can change the interval, and how that change can be reconstructed later. And how the PM can eventually be revised or retired without losing the history it produced.

The goal is not to fill the CMMS with preventive-maintenance schedules. The goal is to translate defensible maintenance reasoning into repeatable work without allowing repetition to turn old assumptions into permanent rules.

The CMMS does not merely store the PM program. Once activated, it executes the program's assumptions over and over again. A CMMS makes repetition easy. A good preventive-maintenance program makes sure what it repeats still deserves to be repeated.

If you are earlier in the process and still assembling requirements, our guide to preventive maintenance software covers what this category of product does, and our guide to building CMMS requirements covers how to turn the questions above into evaluation criteria.