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. How long it takes depends more on the software than on the volume of data. In a modern cloud service where importing is part of the core product rather than an add-on, the basics are in place in minutes. In a more traditional system the same takes hours at least, and in some cases weeks, because the migration is done as separate work with the vendor. It is also the stage where you should decide in advance what to move and what to leave, 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. The software decides this one too, but differently: what matters now is how much the product guides the user. When the app comes from the app store and tells people what to do next, the crew is on board within days and no separate training is needed. When use requires an installation, credentials handed out and a manual, the same takes months. Of the three parts this is still the only one that can fail completely, whichever product you pick.
When a vendor says setup takes ten minutes, they mean the first one, and that may well be true. In a modern service that guides the setup and can use AI to fill in the basics for you, ten minutes is a realistic number rather than sales talk. When a consultant says it takes three months, they mean the third, and that holds for a heavier system. So both can be right at the same time. Ask which number you are being quoted, and 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, and it costs no time at all when the software is built for it. In a modern service one view shows at a glance who has logged and who has not, and the reminder goes out without anyone sending it. The weekly check is then a one minute job whose only content is asking the one person whose rows are missing. With an older system the same means running a report and comparing rows by hand, which is exactly why it stops happening. Done four weeks running the check 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
Data migration goes wrong in two opposite ways. One is moving everything as it is, so the new system starts with the same duplicates, lapsed customers and years-old prices as the old one. The other is leaving everything old behind on principle, and finding six months later that this was exactly the information you needed.
In a modern service the import itself is fast, so volume is not the deciding factor. What matters is what you move and in what condition. Start with what you need tomorrow to do the work:
- Active customers. The ones sending you work now or soon.
- Sites in progress. With all their variations and additional work, because that is the information you need fast and from one place.
- Current employees with contact details, tax numbers and qualifications.
- The price list and your most common work items. Do this one carefully, because it affects quoting speed every single day.
Old projects are the most valuable data the company has, not dead weight. Actual hours and costs per work phase from completed sites are the only material you can price the next quote from correctly. If the old system holds actuals, move them, even as a summary: quoted against actual per site and per work phase. The same goes for earlier jobs for the same customer. When the next job at the same property comes in, the history has to be where the quote is written.
A completed site is not complete from a liability standpoint either. Under the Finnish YSE 1998 general conditions the warranty period is two years from handover, and in cases of gross negligence and certain other situations liability runs for ten years. When a warranty claim comes in you need the contract, the site diary, the photos and a record of who did what and when. Move those at least for the sites whose warranty period is still running. Material from a disputed contract is always moved in full.
For former employees, the law says what to keep. The retention obligation does not end with the employment. Under the Finnish Working Hours Act, working time records must be kept at least until the limitation period expires, which is two years from the end of the employment, and the same applies to annual leave records. Payroll records are accounting material and are kept for ten years from the end of the financial year. The list of workers on a shared construction site must be kept for six years from the end of the year in which the site was completed. The GDPR draws the line in the other direction: personal data may not be kept longer than there is a reason for it, so a former employee's phone number, qualification cards and other unnecessary details do not come along into the new system.
In practice the retention obligation means the information can be found when someone asks for it, not that it lives in the new system. If the old system stays available for reading, that is enough. If the old system is shut down, export working time, annual leave and payroll data and the site worker lists before it closes, and agree who is responsible for them and where they are. This is where a company easily ends up without the material: the old vendor's contract has ended, and a labour inspector or a former employee asks for the records.
Leave behind quotes that led nowhere, customers who have stopped trading and expired prices. When old material is moved, clean out duplicates before the import, not after, and mark completed sites and ended employments as archived straight away so they stay out of the daily lists.
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.
Some of these questions disappear with good software. The app is in the app store, credentials work immediately and the site is in the list under the right name. What remains are the questions that are yours: how sites get named, who logs what, and what happens when the agreed way does not fit. No vendor has a ready answer to those, which is why one site at a time is the right approach even when the software is good.
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.