Rolling out new facilities software without a stalled implementation

A facilities software implementation that stalls rarely stalls because the software itself was wrong. More often, it stalls because momentum was lost somewhere between signing a contract and the point where staff have genuinely built the new system into their daily routine — and once that momentum's gone, an implementation can drift for months in a half-adopted state that delivers little of the value either side expected.

Sequencing: don't try to switch everything on at once

A common mistake is trying to migrate every category — PPM, reactive work orders, statutory tracking, contractor management — simultaneously, on one cutover date. A more reliable approach brings categories online in sequence, getting one genuinely working and trusted before adding the next, so a problem in one area doesn't stall everything else at once.

Getting frontline staff on board, not just the manager

The person who chose the software is rarely the person whose daily habits need to change the most. An implementation that only trains managers, and leaves engineers to work out mobile use on their own, tends to produce quiet workarounds — jobs still tracked on paper "just for now," which quietly becomes permanent. Getting frontline input during setup, not just training after the fact, makes adoption far more likely to stick.

• –Bring categories online in sequence rather than attempting a single simultaneous cutover across everything
• –Involve frontline staff in setup and early testing, not just managers signing off on the decision
• –Set an explicit point where the old system is genuinely retired, not left running indefinitely as a safety net
• –Track adoption directly — are jobs actually being logged and closed in the new system, not just whether training happened
• –Revisit configuration a few weeks in, once real use has revealed what the initial setup got wrong

Migration quality sets the ceiling for adoption

Staff trust in a new system is heavily shaped by whether the data in it looks right on day one — a poorly migrated asset register with missing history or obvious errors gives everyone a very early, very durable reason to distrust the whole system, which is much harder to undo later than getting the migration right the first time.

This is also where continuity across staff changes matters — an implementation led entirely by one person, with no shared understanding of why decisions were made, is vulnerable in the same way an undocumented handover is vulnerable: fine while that person stays, fragile the moment they don't.