Construction ERP migration checklist
Contractor ERP rollouts rarely fail on features. They fail because the masters were never cleaned, the running projects were never brought across, and nobody wrote down what had to be true before the spreadsheets stopped. This is the sequence that avoids that — whoever you buy from.
Opens in Excel, Google Sheets or LibreOffice, with Done / Owner / Notes columns to fill in. Free to use and share — no sign-up, no email required.
How to use it
- Use it before you sign, not after. Half of these checks are questions for your vendor.
- Assign an owner per row on your side. A migration with no named data owner stalls at the first disagreement about which rate is correct.
- Treat the go-live section as a contract with yourself — agree it in writing before the work starts.
Before you commit
Why it matters. "Everything" is not a scope. Three workflows can be tested; everything cannot.
What to look at. Your own list — typically site reporting, procurement and billing.
Why it matters. Migration stalls the first time nobody can say which of three rates is right.
What to look at. One named person for masters, one for projects, one for balances.
Why it matters. Implementation cost is where quoted price and final invoice usually part company.
What to look at. Get it in writing: migration, training sessions, configuration, support period.
Why it matters. Most contractors keep their accounting software. Find out whether it is a migration or an ongoing integration — they are very different promises.
What to look at. Ask specifically: one-time import, or continuous two-way sync?
Why it matters. Without acceptance criteria, a rollout has no end and the spreadsheets never stop.
What to look at. A short written list: these workflows, running in the system, signed by these people.
Masters — where the work actually is
Why it matters. The same cable in four spellings at three rates produces confident, wrong reporting forever.
What to look at. Sort your item list alphabetically and read it. You will find them.
Why it matters. Importing dead vendors carries a decade of noise into a clean system.
What to look at. Vendors with no transaction in 24 months.
Why it matters. Bills will be checked against these rates. Wrong rates are worse than no rates.
What to look at. Spot-check ten rates against the actual work orders.
Why it matters. Changing the structure after data is in is the most expensive rework in any rollout.
What to look at. One page: how you want to see cost, and whether reports can produce it.
Why it matters. Role design decides whether site staff actually use the system or work around it.
What to look at. Who raises, who approves, who sees money. Write it as a table.
Live projects and balances
Why it matters. If only new projects go in, two systems run in parallel and one of them wins — usually the spreadsheet.
What to look at. Count your live projects. All of them should appear in the plan.
Why it matters. Otherwise the first RA bill from the new system is wrong, and trust is lost in week one.
What to look at. Cumulative quantity billed per project, as at the cut-off date.
Why it matters. Without them the first month's cash view is fiction.
What to look at. Tie the totals to your books at the cut-off date, and have your accountant sign it.
Why it matters. An advance that does not migrate is an advance nobody recovers.
What to look at. Ledger of open advances at cut-off.
Why it matters. Ambiguity about the cut-off produces double entry and missing entry at once.
What to look at. One date, written down, communicated to site and office.
People and go-live
Why it matters. Generic training does not survive contact with a real site.
What to look at. Separate sessions for site staff and office staff, on your migrated projects.
Why it matters. If the field cannot file from a phone, the data stops at the office and the system becomes a reporting burden.
What to look at. Have one site engineer file a daily report during the demo, on their own handset.
Why it matters. Parallel running without an end date is how a rollout quietly becomes permanent duplication.
What to look at. Two to four weeks is typical. Write the end date down.
Why it matters. This is the moment the rollout either lands or drifts.
What to look at. Each agreed workflow demonstrated end to end, signed by the person who owns it.
Why it matters. The first month generates more questions than the next year.
What to look at. Named contact, hours, channel, and what counts as chargeable.
Why it matters. Rarely needed, and the day you need it you will need it badly.
What to look at. Your exported data, and the date until which the old system stays available.
A four-week sequence that works
Illustrative plan for a mid-sized contractor — yours is agreed before work starts and may differ.
Doing this without remembering to
This is the sequence sotyn.ai onboarding follows, with the one-time onboarding fee stated on the pricing page and acceptance criteria agreed in writing before go-live.
A demo is 20 minutes on your own trades and project sizes. Nothing is booked until you confirm a time.
See this on your own numbers
A 20-minute walkthrough on your trades and project sizes — not a slideshow. Three fields and we will call you back.