Start with the end: what does success look like?
Before choosing fields or importing a single row, agree what the system has to do for your plant in the first three months. Good measures are concrete and observable: every breakdown on the pilot line has an owner within minutes; the next shift reads the handover instead of asking around; the parts used on a job come off the stock count. Bad measures are vague (“digitalise maintenance”) or depend on features you will not use yet.
Write the measures down. They decide the pilot, the training and, eventually, whether you go live.
Step 1 — Install it (day 1)
Self-hosted, UR Maintain runs on one Linux server with Docker Compose: start the containers and the application is up. No cluster, no consultant and no large IT team. If you would rather not run a server at all, the managed cloud gives you a workspace the same day. Either way, answer the few questions your IT team will have about where the data lives and who can reach it. The deployment page compares the two, and the self-hosted requirements describe the server baseline.
Step 2 — Users, roles and permissions (days 1–2)
Create the sites, then add people: who signs in, with which role, and which sites each person can see. It is a few clicks per person. Getting site scope right now saves awkward permission fixes later.
Step 3 — Machines, parts and documents (days 2–4)
Import locations, machines, parts and users from templates. The rule is the same as in any move away from Excel: machines first, because everything hangs off them; parts second. Use staged imports that report every row as valid, warning or error before anything is written, so you fix the file instead of cleaning the system afterwards.
Then upload the technical documents — the drawings and manuals people actually reach for — to the machines they belong to, and add the preventive-maintenance plans and checklists you run today. The archive can follow later.
Step 4 — Labels and stock (day 5)
Print QR labels for the pilot machines and stick them where a technician will actually look. Set up stock locations and opening balances through controlled opening transactions, so the stock ledger starts from a known state rather than a guess.
Step 5 — Train five actions, not fifty (day 5)
Technicians need five actions to start: see their shift, take a job, wait or resume with a reason, report the machine running, and close out the report. Everything else can wait. The storekeeper, the planner and the manager each get their own screens and their own short session. A training plan that covers every menu teaches people that the system is complicated.
Step 6 — Go live (week 2)
Start with real breakdowns and jobs. Watch for the honest signals: are breakdowns being taken in the system or still by radio? Is the handover read? Are parts issued against jobs? Fix what the team trips over during the week, then switch the plant over when the measures you wrote down are met.
Who needs to be involved
A CMMS rollout is not an IT project with a maintenance audience. It needs four people on the plant side, even if some of them wear two hats:
- An owner — usually the maintenance manager — who decides naming, priorities and what success means, and who can say no to scope creep.
- A planner or supervisor who knows the preventive-maintenance plans and the backlog as they really are.
- A storekeeper who can vouch for part numbers and shelf locations before they are imported.
- Two or three technicians on the pilot line who will use it first and tell you honestly what slows them down.
From IT you need answers more than hours: where the system runs, how people sign in, and who approves data leaving the network if you choose the cloud.
Prepare the data before week one
The fastest rollouts are the ones where the plant arrives with three files already in shape:
- A machine list with one unique tag per machine, its location and, where known, maker, model and serial number.
- A parts list with part numbers, descriptions, units and the shelf or bin where each part lives.
- The preventive-maintenance plans you actually run, with their intervals and the machines they cover.
Gaps are fine. A machine without a serial number can be imported and corrected later from its own page. What slows a rollout is not missing fields — it is two people disagreeing about what a machine is called.
The two-week timeline
For one plant with a clear owner on the customer side, the whole rollout fits in two weeks:
- Day 1
Install: start the containers on one Linux server with Docker Compose, or open a managed cloud workspace. Running the same day.
- Days 1–2
People and permissions: add users, give them roles and choose which sites each person can see.
- Days 2–4
Machines, parts and documents: import machines and parts from your Excel through templates; upload drawings and manuals to the machines they belong to; add your current preventive-maintenance plans.
- Day 5
Labels and training: print QR labels for the machines and train technicians on five actions in one short session.
- Week 2
Go live: run real breakdowns and jobs, fix what the team trips over, and switch the plant over when it is ready.
The software is the quick part. What sets the pace is the machine list: a plant that already agrees what its machines are called can be done sooner than two weeks; one that first has to sort out its naming will spend those days there.
The mistakes we see most
- Importing ten years of history first. It delays go-live and rarely gets used. Bring forward what you trust; leave the rest searchable in the old system.
- Configuring for the report, not the technician. If the field workflow is slow, the data will be wrong. See why a CMMS should not turn technicians into data-entry clerks.
- Going live everywhere at once. A pilot on a few machines finds the problems while they are still cheap.
- No owner on the plant side. Somebody has to decide naming, roles and what “done” means. Software cannot.
If you want to plan a rollout for your plant, request the free demo and bring your machine list — the conversation is more useful with real data on the table.
Frequently asked questions
How long does a CMMS implementation take? Two weeks for one plant: installation on day one, users and data in the first week, live use in the second. Several plants or very messy source data take a little longer.
Do we need a big IT team? No. Self-hosted needs one Linux server with Docker Compose and someone who can start containers; the managed cloud needs nothing installed at all.
Do we have to stop production? No. You start on real work alongside your current way of working; nothing is switched off until the team is ready.
Can we start with history from our old system? Yes, in slices, and only what you trust. Start with machines and parts; history can follow once the basics work.
What if the first week shows problems? Fix them while the scope is small: a role that needs changing, a document missing from a machine, a part number that does not match. That is what week two is for.
