CMMS implementation means introducing a maintenance management system in such a way that technicians, planners and the warehouse team work with it every day and the data can be trusted. Switching on the software is the smallest part of the job. The time goes into setting goals, cleaning up master data, agreeing on the work process, role-based training and continuing to manage usage after go-live. This plan starts where the selection ends; how to choose a system is covered in choosing maintenance software.
Why CMMS implementations stall
When an implementation stalls, the software is rarely the only cause. Look at these points:
- Messy data. Assets without a fixed code, duplicate items, maintenance plans nobody has carried out for years. Migrate that unchecked and on day one you have a system nobody trusts.
- Too much at once. All modules, all sites and all integrations in a single step. Every problem then hits everyone at the same time, and nobody can see where it started.
- No owner. The project sits with IT or with the vendor, and after go-live nobody feels responsible for the configuration and the data.
- A poor fit with the shop floor. No mobile use at the machine, terms nobody recognises, screens designed for the office.
- One-off training. A single classroom session, months before go-live, after which everyone has to work it out alone.
- Nobody manages usage. Work that bypasses the system goes unnoticed, so more and more work bypasses it.
Each of these points has a place in the plan below.
CMMS implementation in eight phases
The phases partly overlap: while master data is being cleaned up, the configuration is already taking shape. The order in which you decide stays the same, though.
- Goals and KPIs. Decide what must be different after the introduction and make it measurable, for example: "all breakdowns come in as a notification", "90 per cent of preventive work is done on time" or "every closed breakdown records cause and action". Measure the starting point now, or you will have nothing to compare against later. Suitable metrics are covered in maintenance KPIs. If your organisation works to ISO 55001, the standard with requirements for an asset management system, align these goals with your asset management objectives.
- Team and owner. The owner comes from maintenance, not IT: someone who knows the work process and stays responsible for it after go-live. Choose a key user per discipline or shift and put technicians on the team from the start, because they are the ones who will use the system every day. And make sure that time is genuinely freed up. If your organisation has a works council or other employee representatives and the system records who did what and for how long, involve them early. In the Netherlands, for example, arrangements for systems suited to monitoring employees' attendance, behaviour or performance require the works council's consent (article 27 of the Works Councils Act).
- Master data. This is often the biggest job. First set up the asset register with fixed codes and a hierarchy; use an existing coding system if there is one, such as KKS in a power plant. Link the spare parts, suppliers and maintenance plans to it. Also agree a short list of failure codes in advance, so closed breakdowns can be analysed from day one. Clean up before you migrate, not after. What such a hierarchy looks like is shown under asset management software.
- Processes and configuration. Map the work process first: from notification through work order to close-out, including who assesses, who schedules and what is mandatory at close-out. Then configure the system: few statuses with a clear meaning, priorities, roles and permissions. Don't rebuild the old system one to one, and don't solve every exception with customisation.
- Pilot. Start in one well-defined area with real work and real people, for example one incineration line in a waste-to-energy plant, the packaging lines in a factory or the sorter in a distribution centre. Four to eight weeks is usually enough to see where the configuration does not fit the way you work, which data is missing and which questions keep coming back. Adjust before you roll out further.
- Role-based training. A technician must be able to raise a notification and close a work order, a planner must be able to schedule work and the warehouse team must be able to issue parts. Keep training short, on your own assets and just before go-live, ideally delivered by the key users. Give everyone a short role-based instruction to fall back on.
- Roll-out and go-live. Roll out by area or site. Pick a quiet period: not just before a major shutdown and not in the middle of the holidays. On the go-live date, set the old system to read-only so there are never two versions of the truth, and make sure key users can be reached on the floor for the first weeks.
- Embed and improve. After go-live the real work begins. Review usage and data quality every month, tackle recurring questions and adjust the configuration. Only add new modules or sites once the core is running steadily.
The diagram below shows the eight phases as a route, with a sketch of system use around go-live underneath. Expect a dip in the first weeks: old habits, questions and small data errors. If you support people and adjust quickly at that point, use keeps growing; if you close the project at go-live, it sags.
Data migration: what to bring across and what to leave
Not everything in the old system or the old lists deserves a place in the new one. A practical split:
| Data | Migrate? | Watch out for |
|---|---|---|
| Assets and positions | Yes, cleaned up | fixed codes, no duplicate records |
| Open work orders and notifications | Only what is truly open | close old open orders first |
| Preventive maintenance plans | Yes, after review | carry over last completion date or meter reading |
| Items and stock | Yes, cleaned up | merge duplicate items; count when the warehouse goes live |
| Suppliers | Active ones only | check contact details |
| Closed work orders | Usually not in full | archive or summarise per asset |
| Drawings and manuals | In stages | link to the right asset |
Carrying over the last completion date of each maintenance plan stops every preventive work order being released on day one. Old history calls for a different trade-off: its quality often varies and its codes don't fit the new structure. A searchable archive of the old system plus a short summary per critical asset (last overhaul, recurring failures) is then more useful than thousands of loose lines. Bring drawings and manuals across step by step; how to organise them is covered in technical document control. An example is shown under technical document management.
Adoption on the shop floor
A CMMS only pays off when the work actually runs through it. Technicians use a system because it makes their work easier, not because they are told to.
- Mobile, at the machine. What people record where the work happens doesn't get forgotten or summarised at the end of the shift. So raising a notification with a photo and looking up asset details should be possible on a phone. How such a notification comes in and is assessed is shown under notifications.
- Simplicity. Every mandatory field needs a reason. Too many mandatory fields don't produce better data, just full stops and "see above".
- Show results early. In the first weeks, show what it delivers: a breakdown picked up faster because the notification with a photo reached the planner straight away, or a part that was ready because it was linked to the asset.
- Feedback. Whoever raises a notification wants to see what happens to it. A notification that disappears into a black hole is the last one that person raises.
- Lead by example. If team meetings and the weekly schedule come out of the system, the rest follows. If the manager asks for a list in a spreadsheet, the rest follows too, in the wrong direction.
How long does a CMMS implementation take?
How long implementing maintenance software takes depends mainly on the state of your data, the number of sites and integrations, and how much time the key users really get. The table gives an indication for one site with its own maintenance team and an asset register that still needs cleaning up. It is not a promise, and phases overlap.
| Phases | Indication | What drives the duration |
|---|---|---|
| 1 and 2: goals, team and owner | 2 to 4 weeks | decision-making |
| 3: master data | 4 to 12 weeks | state of the existing lists |
| 4: processes and configuration | 2 to 6 weeks, partly alongside 3 | number of exceptions |
| 5: pilot | 4 to 8 weeks | size of the pilot area |
| 6 and 7: training, roll-out and go-live | 2 to 4 weeks per area | shift patterns and staffing |
| 8: embed and improve | ongoing | ownership |
A small organisation whose data is already in order can move faster, sometimes within a few weeks. Several sites or integrations with other systems make the project longer.
CMMS go-live checklist
- The asset register for the roll-out area is complete and the codes on the labels match the system.
- Open work has been migrated and checked; the old system is read-only.
- Maintenance plans are active with the correct last completion date or meter reading, and the first work orders have been checked.
- If the warehouse goes live in this phase, stock has been counted on the go-live date.
- Roles and permissions have been tested with real users, and everyone can log in.
- Phones or tablets are ready and connectivity on the shop floor has been checked.
- Everyone has been trained for their own role and has a short instruction.
- Key users are scheduled for support in the first weeks, with a fixed place to report questions and errors.
- The agreement stands: from go-live, new work only runs through the system.
Common mistakes in CMMS implementation
- Running in parallel for months. Old and new side by side means double work and two versions of the truth. So set the old system to read-only on the go-live date. If a parallel period is unavoidable, keep it short, with a fixed end date.
- Migrating all history "just in case". Old records with different codes pollute your new analyses from day one.
- Customising for every request. Every customisation has to be maintained, tested and explained. First ask whether the process can change instead.
- Too many statuses. If nobody can explain the difference between two statuses, one of them is surplus.
- Key users without time. Being a key user on top of a full schedule means the work gets done in the evening, or not at all.
- No baseline. Without a measurement before the start, you can't show what the implementation delivered, and support for the next step crumbles.
Frequently asked questions
Who should lead a CMMS implementation?
Someone from maintenance who knows the work process and remains the owner after go-live, such as the maintenance manager or an experienced maintenance planner. IT looks after accounts, devices and integrations, and the vendor after configuration, but decisions on statuses, mandatory fields and codes belong to maintenance. Also make sure there is a sponsor in management who frees up time and people and uses the system in meetings.
Is it better to roll out a CMMS in one go or in phases?
For most organisations a phased approach works better: first the maintenance core in one area, then other areas and modules. Errors in configuration or data then affect a small group, and key users from the first phase help with the next. A single go-live can work for a small team at one site, provided the data is in order beforehand. A middle way is one go-live per site, with modules added in phases.
What does a CMMS implementation cost besides the licence?
Mainly internal time. Key users and the owner spend weeks on data and configuration, and every user needs training. On top of that come phones or tablets, labels for assets and warehouse locations, any integrations and external support with the configuration. Put these items in your budget; if you only budget for the licence, you will run short of time on exactly the parts that make the difference.
How do you know whether a CMMS implementation has succeeded?
By measuring the goals from the first phase again and comparing them with the baseline. Look at use (what share of breakdowns comes in as a notification), data quality (what share of closed breakdowns records cause and action, how many assets lack core data) and results (preventive work done on time, visibility of the backlog). Measure after three and after twelve months: the first measurement shows adoption, the second whether it lasts.
When should you add modules such as warehouse or purchasing?
Once the core is running steadily: notifications and work orders go through the system, the asset register is accurate and maintenance plans generate work on time. A warehouse module builds on items linked to assets and work orders; purchasing in turn builds on accurate stock and supplier data. If you introduce everything at once, you can no longer see where an error comes from.