ERP Implementation Questions to Ask
Twenty questions to put to ERP vendors and implementation partners before signing. They cover total cost of ownership, timeline and milestones, integration with existing systems, security, customization limits, the upgrade path, training, and the rollback plan if go-live goes badly.
The questions
Open any question for the note
What is the all-in cost for the first three years, including licences, services, integrations, training and support?
Why ask it
Ask for it as one number with the assumptions written down. Proposals that quote licence cost cleanly and services as an estimate are telling you where the overrun will come from, because services are the larger and less predictable half.
On your last three projects our size, what was the ratio of services fees to licence fees?
Why ask it
A partner who has done this work has the number and will give you a range. Refusing on the grounds that every project is different is a way of avoiding a comparison you can hold them to later.
Which of your recent implementations ran over, and what caused it?
Why ask it
Everyone has overruns, so a claim of none means the answer is being managed. Useful answers name a cause you can check for in your own organisation, usually data quality or unavailable client staff.
Who specifically will be on our project team, and what else are they assigned to?
Why ask it
The people in the pitch are frequently not the people who deliver. Ask for names, roles and percentage allocation in the contract, and ask what happens if the lead consultant leaves mid-project.
How much of our staff time do you need, from whom, and for how long?
Why ask it
This is the cost most organisations fail to budget, and honest partners will quantify it in days per week by role. An answer of minimal involvement predicts a system configured around assumptions nobody at your company checked.
What are the milestones, and which of them release payment?
Why ask it
Payment tied to elapsed time rather than accepted deliverables removes your only real leverage. Look for money held back until after go-live and a defined acceptance test.
How does our data get out of the current system, and who is responsible for cleaning it?
Why ask it
Migration effort is driven by the state of your existing records, and cleansing is the task most often left unowned in the plan. If the answer is that you will handle extraction, price that internally before you sign.
How many test cycles are planned, and who decides whether a cycle passed?
Why ask it
One test cycle means the first real test is go-live. Ask who writes the test scripts, since scripts written by the partner tend to test the software rather than your processes.
Which of our existing systems will you connect, and are those connectors standard or built for us?
Why ask it
Standard connectors get maintained through upgrades and custom ones become your problem. Ask specifically who fixes an integration that breaks after a vendor update, and under which agreement.
Where does configuration end and customization begin in this system?
Why ask it
Vendors use the words loosely and the distinction determines your upgrade cost for the next decade. Ask for an example of something you have requested that would cross the line.
What actually happens on go-live weekend, hour by hour?
Why ask it
A partner who has done this has a runbook and will walk you through the cutover window, the freeze on transactions and the checkpoints. Vagueness here is the clearest signal of inexperience in the whole conversation.
If go-live fails, what is the rollback plan and how long do we have to invoke it?
Why ask it
There is usually a point after which returning to the old system is no longer possible because transactions have diverged. Knowing that deadline in advance is what lets you make a calm decision at two in the morning.
How will we operate during the period when both systems are running?
Why ask it
Parallel running costs double effort and confuses reporting, so ask how long it lasts and which system is authoritative for each process. Plans that skip this period entirely are assuming a clean switch nobody gets.
Who trains our people, and how do we train the ones who join next year?
Why ask it
Partner-led training ends when the project does, which leaves you dependent on whoever happened to be in the room. Look for materials you own, recorded sessions and a named internal trainer.
How do upgrades work, how often are they mandatory, and how much of the work falls on us?
Why ask it
Cloud products push updates on a schedule you do not control, so the real question is your regression testing burden each cycle. Ask how much notice you get and whether you can defer.
Where will our data live, who at your firm can access it, and what have you been audited against?
Why ask it
Ask for the audit report rather than the certificate logo, and ask about subcontractors, since offshore delivery teams often hold access nobody mentioned. Get the breach notification timeline in writing.
What compliance and audit requirements in our industry have you built for before?
Why ask it
Look for the specific regime you are subject to and a client who passed an audit on their build. General assurances about being compliant describe the software, not your configuration of it.
Which reports exist on day one, and which will we have to build ourselves?
Why ask it
The gap between standard reports and the numbers your board actually reads is a common late surprise. Bring your five most-used current reports and ask which of them survive.
When does the project team leave, and what does support look like the week after?
Why ask it
The handover from implementation to support is where organisations feel abandoned. Ask for a defined hypercare period, its length, and who answers the phone once it ends.
Can we talk to a client of yours where this went badly?
Why ask it
Reference calls are curated by default, and asking for a difficult one tests candour. Partners who agree usually have a real story about what they changed, which is more informative than three happy references.
Before You Sign
Practical guidance for the conversation itself
Protecting yourself in the contract and the plan
Name an internal owner with authority to say no
Projects without a single decision maker accumulate contradictory requirements from every department. The owner needs enough seniority to refuse a customization request from a director.
Write scope exclusions down, not just scope
Disputes are almost always about what someone assumed was included. A short list of what is explicitly out of scope, and a stated price mechanism for change requests, prevents most of them.
Budget for your own people, in hours
The partner's fee is the visible cost. The hidden one is your finance, operations and warehouse staff spending a day a week on this for months while their normal work continues.
Pick a go-live date away from your busiest period
Avoid month end, quarter end, year end and your seasonal peak. The pressure to close the books through a system nobody has used yet is how a manageable rollout becomes a crisis.
Where these projects come apart
Rebuilding your old system in the new one
Customizing to preserve every existing quirk raises cost, delays go-live and makes upgrades painful for years. For each request, ask whether the process exists for a reason or only because the old software required it.
Migrating dirty data
Duplicate customers, obsolete part numbers and inconsistent units carry straight across and are harder to fix afterwards. Decide early how many years of history you actually need in the new system.
Training only the project team
The people who configured the system understand it and the people who use it daily may not. Sign-off from a super user is not evidence that a warehouse shift can complete a transaction.
Treating go-live as the finish
Productivity usually dips for weeks afterwards while people relearn familiar tasks. Plan for reduced throughput and keep experienced help available rather than releasing everyone the day after.
Making reference calls worth the time
- 1Ask to speak to a client at your scale and in your industry, not the largest logo they have.
- 2Ask for the actual timeline: planned go-live date against the real one.
- 3Ask what the final cost was against the original proposal, and what caused the difference.
- 4Ask which consultant they worked with and whether that person stayed for the project.
- 5Ask what they would do differently, which people answer more honestly than what went wrong.
- 6Ask who on their team quit or burned out during the rollout. The answer tells you the real internal load.