Implementations rarely fail because of the software
When a construction company's ERP rollout goes wrong, the software usually gets the blame. It was too complicated, it did not bend to the way we work, the crew never learned it.
Most of the time none of that is what actually happened. The software was opened, a few sites were created in it, and then two things were left undone: nobody took responsibility for making sure entries got made, and the old way was never dropped. When both ways run at once, neither one is up to date, and three months later the company goes back to the one it already knows.
This guide covers what to consider when adopting a construction ERP, whichever product you end up choosing. It is not a product tour and not a description of one vendor's onboarding. It is a list of the places where implementations typically stumble, and what you can do about them in advance.
Three different things that get confused
The word implementation means three completely different sizes of thing, and mixing them up is why schedule estimates miss by multiples.
Technical opening means the software exists and you can get into it. Accounts are created, company details entered, first users added. In a cloud service this is a matter of minutes, because nothing is installed and no server is bought. If a vendor talks about weeks at this point, ask exactly what those weeks consist of.
Data migration means the system holds your own customers, sites, employees and price lists. This takes hours or days depending on how much old material you move and what shape it is in. It is also the stage where you should do less than you first think, more on that below.
Change of working habits means people in the company actually do things the new way. Hours are logged on a phone at the site instead of on a slip of paper. A receipt is photographed when it is received, not at the end of the month. This is not a matter of hours or days but of weeks, and it is the only one of the three that can fail completely.
When a vendor says setup takes ten minutes, they mean the first one. When a consultant says it takes three months, they mean the third. Both can be right. Agree between yourselves which one you mean before you agree a schedule with anyone.
What to settle before you sign
Sort these out before the contract, because fixing them afterwards costs more than asking about them up front.
Who in the company uses the system daily. Not who owns it but who opens it every morning. If the answer is only the office, this is not an ERP but a reporting tool, and site information still gets created somewhere else.
Which single problem has to be solved first. An implementation succeeds far more often when it has one clear goal. Hours on the right sites. Receipts captured in the same month. Quotes out faster. If there are six goals, none of them happens, because attention splits and nobody notices when one is left unfinished.
Where each piece of information currently lives. List where customer records, price lists, site details and employee data are today. They are usually in more places than people remember: in accounting, in a spreadsheet, in email and in somebody's head. That list is what the data migration gets planned from.
Who handles accounting and which software they use. If the books are with an accounting firm, bring them into the conversation before agreeing on an integration. They know how they want the material, and they are the party that notices first if something goes wrong.
Who owns the implementation
This is the most important section in the guide, and it is usually the one left undone.
An implementation needs one named person inside the company. Not the vendor, someone on your payroll. Their job is not to know the software best but to notice when somebody is not logging, and to ask about it. Without that person the rollout runs for two weeks and then fades, because there is always something more urgent on site than learning a new system.
In a small company this is in practice always the owner or the site manager. It does not take much time, but it takes regularity: once a week you check whether entries were made, and if not, you ask why. Done four weeks running it becomes a habit. Never done, it becomes nothing.
The other half of the same thing is that management has to use the resulting information visibly. If a site manager asks for hours over the phone when they are in the system, the crew learns that logging is an extra step and not where the information really comes from. Read the information where it is entered, or entering it means nothing.
What to migrate and what to leave
The most common migration mistake is moving too much. The old system or spreadsheet holds years of history and taking it along feels natural. In practice it delays the rollout by weeks and produces information nobody looks at.
Move what you need tomorrow to do the work:
- Active customers. The ones sending you work now, not everyone you ever quoted.
- Sites in progress. Finished projects can stay in the old system, where they already are.
- Current employees. Not former ones.
- The price list and your most common work items. Do this one carefully, because it affects quoting speed every single day.
Leave behind old project history, old quotes and archived accounting material. They stay where they are, and the statutory retention obligation is met there just as well. If historical data is ever needed, you fetch it then.
Make one exception: if a job in progress is disputed or carries a lot of variation work, move that material in full. That is exactly where information is needed fast and from one place.
Connecting accounting
The accounting integration is where promises and reality diverge most, so ask about it precisely.
A modern connection is made in the settings in minutes when both ends have a ready interface. That is an entirely normal situation and not something to pay for as a separate project. But it only holds when the ready-made connection is to the specific software you use.
Ask these before you believe an integration promise:
- Does the connection exist for the exact product we use, or for the product family in general. The same vendor may sell several products and the connection may cover only some of them.
- Which way does data flow. Do invoices only go out, or do purchase invoices and payment records come back too. A one-way connection is a different product from a two-way one.
- What does the connection not transfer. This question reveals more than a feature list.
- Who makes the connection and does it need the accounting firm's credentials. If it does, book a time with them in advance, because this is a classic place where a rollout sits still for a week.
- Is the connection in production with other customers, or coming. A forthcoming connection is worth knowing about, but you cannot plan a schedule around it.
If there is no ready connection to your accounting software, it is not necessarily a blocker. Ask instead how the material moves without one and how much manual work that leaves per month. The answer tells you whether this is a minor nuisance or continuous extra work.
Start with one site
The temptation is to go live across the whole company at once, so the transition is over quickly. In practice that is the most efficient way to fail.
When everything starts at the same time, every problem arrives at the same time for everyone. One person cannot find the site in the list, another has no app on their phone, a third logs hours to the wrong project. Twenty small questions appear in a single day, nobody has time to answer them, and the crew goes back to paper because the work has to get done.
A better way is to take one site already in progress and do everything the new way there for two weeks. One site produces the same set of questions as all sites, but they arrive one at a time and can be handled. Once that site works, the next ones start faster, because the answers already exist and some people can now show others.
Pick an ordinary site as the first one, not the easiest and not the hardest. The easiest reveals no problems and the hardest makes the whole system look broken.