CAFM Implementation: What to Prepare Before Go Live
In short
Before a CAFM go live, prepare a clean asset register with consistent naming, an agreed location structure, PPM schedules checked against team capacity, user roles and permissions, and technicians who can log in on their own phones. Name one internal owner, train supervisors first, and test real jobs end to end.
Software rollouts rarely fail because the software was bad. They fail because nobody could find an asset in the system, or because the technicians never really moved off WhatsApp. Both of those are decided in the weeks before go live, not after.
This guide assumes you have chosen a system. If you are still comparing options, start with how to choose CAFM software in the UAE and come back to this one once you have picked.
Here is what to have ready.
Who owns the project on your side?
Name one person. Not a committee, not “the FM team”.
That person decides what the asset naming looks like, signs off the PPM schedules, chases the data, and is the one everyone asks when something is unclear. Without them, every small decision waits for a meeting, and a six week rollout turns into six months.
They need enough time for it. Treating a CAFM rollout as something a supervisor does between jobs is the most common reason projects drift.
What asset data do you need?
This is the big one. Whatever you load is what your team lives with for years.
At minimum, for every asset you plan to maintain:
- A unique asset code
- What it is, in consistent wording
- Where it is, using your location structure
- Make, model and serial number
- Installation date or age, if known
- Which PPM schedule applies to it
Two rules make the difference between a register people use and one they fight.
Be consistent. If one row says “AHU” and another says “Air Handling Unit” and a third says “A/H/U”, nobody can search or report. Pick one form of each word and apply it everywhere. A short naming standard on one page, agreed before data entry starts, saves weeks later.
Make the code tell you where it is. Something like TWR1-L03-AHU-02 lets a technician confirm they are at the right unit without opening anything. A code like AST-004871 tells them nothing.
How do you set up locations?
Build the location tree before the assets, because every asset hangs off it.
Most portfolios need something like site, then building, then floor or zone, then room or plant room. Keep the depth consistent across buildings. Mixed depth, where one building goes four levels and another goes two, breaks reporting later.
Use the names your team already says out loud. If everyone calls it the podium, do not label it Level 00 Retail Annex in the system. The system should match the building, not the drawings.
What about your existing data?
If you are moving from another system or from spreadsheets, clean the data before you move it, not after.
Expect to find duplicates, assets that were removed years ago, and equipment that was replaced but never updated. Migrating all of it means paying to carry rubbish across, and then working around it forever.
A practical approach: export what you have, walk a sample of sites to check it against reality, and mark anything you cannot verify. Assets you cannot confirm should not go in as if they were confirmed.
Old work order history is a separate decision. It is useful for spotting repeat failures, but it is also the messiest data you have. Many teams load assets and open jobs only, and keep the old history in an archive they can look up if needed.
How do you prepare PPM schedules?
Decide what each schedule actually is before anyone configures it.
For each one you need the assets it covers, the frequency, what the technician has to do, how long it should take and what skill it needs. Manufacturer manuals and your maintenance specifications are the starting point, and your contracts may require specific frequencies.
Two things to watch:
Do not import every schedule you have on paper. Most teams find schedules nobody has run in years. Go live is the moment to drop them.
Check the workload. Once schedules are in the system, it will generate every job on time, which is the point. If that produces 400 jobs in the first week for a team that can do 150, the team will start closing jobs without doing them, and your data stops meaning anything within a month.
What do you need to decide about people?
Three things.
Roles and permissions. Who raises jobs, who assigns, who closes, who approves, who sees costs. Write it down as a short table before configuration, because these decisions are much harder to change once people are working.
How requests arrive. Tenants through a portal, a helpdesk number, supervisors only, or a mix. Whatever you choose, make sure the old routes actually close. If people can still WhatsApp a supervisor directly, some of them always will, and those jobs never reach the system.
Devices. Do technicians have phones that can run the app, and do they have data or site wifi. This sounds obvious and is missed often enough to be worth checking early.
How should you test before go live?
Run your own jobs through the system before it matters.
Pick a small set of real situations: a tenant complaint, a breakdown at night, a PPM job in a plant room with no signal, a job that needs a part from stores, a job that gets reassigned. Walk each one end to end with the people who will actually do it.
Then produce the report you will send to your client or management. If it looks wrong or takes too long to build, fix that now, while there is still time.
Should you go live everywhere at once?
Usually not. One building or one team first, for a few weeks, then the rest.
A pilot surfaces the things nobody predicted: the location name everyone disputes, the job type that does not fit any category, the plant room where the app cannot connect. Fixing those across one building is a conversation. Fixing them across forty is a project.
The exception is a portfolio small enough that a pilot is most of it anyway.
How should training work?
Train supervisors first, properly, and let them train technicians.
Technicians usually need fifteen minutes on their phone, not a classroom session: find my job, do it, add a photo, close it. Supervisors need much more, because they will be answering questions long after the vendor’s training ends.
Agree what happens for new joiners, since crews change and a system only one trained group understands slowly stops being used.
What usually goes wrong
| Problem | When it shows up | How to avoid it |
|---|---|---|
| Inconsistent asset naming | First time someone runs a report | Agree a naming standard before data entry |
| Migrated bad data | Weeks after go live, as complaints | Clean and verify before loading |
| Too many PPM jobs generated | Within the first month | Check workload against team capacity |
| Old request routes still open | Immediately, and permanently | Close the old routes at go live |
| No internal owner | The whole way through | Name one person with time for it |
| Technicians not trained on their phones | First week | Short, hands on, on their own device |
A checklist for the week before go live
- Asset register loaded, and a sample verified on site
- Location tree agreed, using the names the team uses
- PPM schedules configured, with workload checked
- Roles and permissions set
- Request routes live, old routes closed
- Technicians can log in on their own phones
- Test jobs completed end to end
- One report produced and approved
- Supervisors trained
- Everyone knows who to ask in week one
Where CAFMTEK fits
CAFMTEK is HITEK AI’s CAFM system, covering work orders, planned maintenance, asset history and mobile job completion.
If you are still at the selection stage, our guide on how to choose CAFM software in the UAE covers what to check and what to ask vendors. If you are weighing CAFM against a maintenance-only system, CAFM vs CMMS explains the difference.