Decide the workflow first
Statuses, roles and permissions before a single piece of data goes in. It's the cheapest thing to get right at the start and the most expensive to fix later.
Guide
Almost no CMMS fails. It gets abandoned
And when it gets abandoned, the conclusion is usually that the software wasn't good enough. It rarely is: the reasons repeat with a regularity that's honestly a bit unsettling.
What it means for a rollout to have gone well
It's worth defining before you start, because otherwise you never know if it's finished. A rollout has gone well when the work that gets done is logged without anyone having to remember to do it, when whoever asks something gets the answer from the system instead of asking a person, and when the team opens the tool because it makes their day easier, not because they're forced to. None of that requires a complete inventory or every module switched on, which is exactly why aiming for the second usually gets in the way of the first.
The five mistakes
In order of how often they happen.
- Building the full inventory before starting. Four months in, nobody remembers the project and the inventory is still half done.
- Configuring the status workflow on the fly. Changing it later, with a thousand orders already inside, costs ten times more than thinking it through for an afternoon at the start.
- Training managers and not technicians. Whoever decides if the system gets used is whoever works in the field, and they decide in the first week.
- Migrating the entire history without filtering it. Poor records mixed with good ones ruin the indicators instead of enriching them.
- Not defining when it's done. Without a definition of finished, the rollout turns into a perpetual project that nobody ever signs off on.
What to do instead
The order that actually works.
Start with one part
One contract, one plant or one line, with a minimal inventory. Real orders running within weeks are worth more than a perfect inventory a year from now.
Support the team
In the first days, with their own real orders, fixing the specific friction points as they show up. That week determines the outcome.
Automate afterwards
Preventive plans get adopted on their own once the team is already working inside the system. Before that, they're just one more burden.
Measure last
Indicators only make sense once there are months of reliable records. Pulling them out earlier only teaches people to distrust them.
What to bring along and what to leave behind
Almost nobody starts from zero, and the temptation is to bring everything. It's worth resisting. What's worth migrating is what will actually be used: the asset inventory with its identification and location, active contracts, technical documentation and ongoing regulatory obligations. From the history of past work, bring enough for the indicators to make sense, which is rarely ten years' worth. Bringing a decade of work orders closed with "checked and working" doesn't improve the analysis: it pollutes it, because it mixes poor records with good ones and you can no longer tell them apart.
Shall we look at it with your way of working?
Leave your details and we will get in touch to see whether we fit. No commitment, no lock-in period.
Without someone to own it, there's no rollout
The factor that best predicts whether a project like this is still alive two years on isn't the product or the budget: it's whether there's one specific person explicitly tasked with keeping it going. They don't need to be technical, and they don't need to work on it full time, but they do need a name, and the rest of the team needs to know who to ask when something doesn't add up. Systems that get abandoned almost never get abandoned all at once: they slowly fall out of date because someone left, because nobody registered the new equipment, because the plans kept pointing at a machine that's no longer there. Each one of those gaps is small and fixable on its own; together they're the reason that, two years in, nobody trusts what they see. And fixing it is only cheap while the gap is still small.
An order that avoids redoing the work
There's a sequence that repeats itself in rollouts that go well, and its merit is that each step leaves what the next one needs ready to go. First the inventory of what actually gets maintained, because without assets there's nothing to hang the work on. Then corrective work, which is already happening and doesn't need to be invented: the team starts logging what it does, without also being asked to design anything. Once that runs on its own, preventive maintenance comes in, and it comes in with a huge advantage over setting it up on day one, which is that there are already a few months of history to decide what deserves a plan. Reports come last, and they need everything before them to have been running for a while. Reversing this order — starting with plans and dashboards, which is the flashiest part — is the most common reason for having to redo everything a year later.
Frequently asked questions
Is it worth migrating the history from the previous system?
It depends on whether anyone is going to look at it. Migrating years of past work takes a considerable amount of cleanup and data mapping, and what gets recovered often never gets looked at again. What almost always pays off to migrate is the asset inventory and documents with active validity; the history of past work orders should be weighed separately, and it's often enough to keep the old system available to browse for a while.
How many people are needed on the client side?
Fewer than you'd fear, but not zero, and that's where projects that only budgeted for the software get stuck. You need someone who knows the site for the inventory and the plans, and someone to support the team in the first months. They can be the same person. What doesn't work is making it everyone's responsibility, because then it's nobody's.
Why do CMMS rollouts fail?
For five reasons that keep repeating: wanting the full inventory before starting, configuring the workflow on the fly, training only managers, migrating the entire history without filtering it, and not defining when the project is done.
Do I need the full inventory to get started?
No, and wanting it is the most common mistake. With the identification, location and model of the assets in one area, you can already get started, and the rest comes later.
How much history should I migrate?
Enough for the indicators to make sense, which is rarely ten years' worth. Bringing in work orders closed without a real description pollutes the analysis instead of enriching it.
What matters most of all?
That the field team gets something out of it from day one. That's what decides whether the system gets used, and it gets decided in the first week.
Already tried this once?
Even better: knowing what went wrong then saves half the work now. Tell us about it in a short demo.