The system we run for an engineering consultancy covers projects, finance, HR and procurement across thirty-five modules, which is to say thirty-five separate working parts. More than 150 people use it every day across four countries. It did not arrive that way, and there was never a night when the old thing switched off and the new thing switched on.
Moving everything across in one weekend keeps getting proposed because it is easy to draw on a slide. It is also how organisations end up unable to invoice for three weeks.
Start where the pain is, not where the diagram starts
Every ERP diagram begins with the core records: customers, products, suppliers. Every successful replacement I have been part of began somewhere else, with the one process currently costing somebody their evenings.
Get that into daily use, by real people, early. You get two things out of it. The users discover the new system is not a threat, and you discover what your data is actually like, which is never what the documentation says.
Run both systems side by side, deliberately, for longer than feels comfortable
Running the old and the new at the same time is tedious and it is the cheapest insurance available. Somebody enters things twice for a while. That period is when you find the twelve exceptions nobody mentioned while the requirements were being written.
Agree in advance what would make you stop and go back to the old system, and write it down. Nobody makes that call well under pressure without a limit set beforehand.
Move less across than you want to
The instinct is to bring everything. Ten years of records, every old field nobody uses, the column somebody added in 2016 that four records rely on.
Bring what the business needs to operate and park the rest somewhere people can still read it. A move that carries every historical oddity forward fails on data quality, and you spend the project cleaning records nobody will look at again.
The connections between systems are the project
The new system is rarely the hard part. The hard part is the internal database nobody owns, the finance package that only exports on Tuesdays, and the one spreadsheet that turns out to be holding the whole thing up.
Go looking for those in week one. There is always at least one you were not told about, usually because the person who maintains it does not think of it as a system.
Put the tools where people already work
The document search we built for the same client took structural beam design from four hours to about five minutes. It gets used because it sits inside AutoCAD and Revit, the drawing software the engineers have open all day anyway. Had it been a separate website they needed to switch windows to reach, the number would look impressive in a report and the tool would sit unopened.
Software that does the repetitive drawing work follows the same principle and saves 100 to 200 hours on a typical project. Whether people use a system is settled by how it is designed at the start, not discovered as a training problem at the end.
About the uptime figure
It has been available 99% of the time since. That is a product of the dull choices above rather than anything clever, and I would rather have the dull choices.
Working through this on a live programme?
A 45-minute call with the engineer who would run the work. We will tell you whether AI is the answer, including when it is not.