How to Evaluate an ERP Implementation Partner

Evaluate an ERP implementation partner by asking questions whose answers you can check, not questions that invite a pitch. Find out who will do the work and meet them, ask for one real document from a finished project, hand them one of your own workarounds and see whether they push back, and pay for a small, bounded piece of real work before you sign for the whole implementation. A proposal shows you how well a firm sells. Those four things show you how it delivers.

Why This Method Does Not Start With a Scorecard

The standard advice for choosing a partner is a procurement process: define weighted criteria, issue a request for proposal, score the proposals, check references, pick the finalist. For a large, formal selection it is the right shape.

The problem with it for most small and mid-sized companies is simple: you cannot score what you cannot verify. A proposal is written by the people whose job is writing proposals. Three good firms will send you three documents that all promise discovery, a methodology, named roles and post-go-live support, and the scorecard ends up measuring prose. The things that decide whether your implementation works, such as who shows up on Monday, whether they write decisions down, and whether they will tell you no, are not in the proposal at all.

The method below is built around evidence you can collect yourself in two or three weeks: questions whose answers can be checked, one paid test, and a short list of answers that should end the conversation on the spot. Run every candidate through all three.

Part One: Questions Whose Answers You Can Check

If you cannot verify an answer, it is a pitch, not evidence.

1. Who, by name, will do the discovery, the configuration and the migration?

Not the role. The person. Then ask how much of that person's week is yours. The answer you want is a name, a share of their time, and a straight statement of what happens if they leave mid-project.

How to check: ask to meet that person before you sign, and put your technical questions to them rather than to the salesperson. A firm that will not introduce the delivery team until after signature is either hiding a staffing gap or planning to assign whoever is free.

2. Walk me through one implementation like ours that you personally ran.

The useful word is personally. Firm-level case studies tell you about the firm's history, not about the person in front of you. Ask the named consultant to describe one project with your shape: your industry, roughly your size, your kind of data, your integrations. Then ask what went wrong on it and what they changed afterwards. Every real project has that answer. A blank is informative.

How to check: the detail is the check. Someone who ran the project can tell you which decision they regret and why. Someone reading a case study cannot.

3. Show me one document of each kind from a finished project.

If you can ask only one question, make it this one. Ask for a fit-gap document, a cutover plan, a migration reconciliation and a configuration or decision log, from a completed project, with client details removed. Redaction is normal. Refusal is not.

What you are looking for is whether the documents show decisions being argued and recorded, or whether they are templates with the columns filled in. A fit-gap document with a reason next to every customisation was written by someone doing the job. What each of those documents should contain is described in what an ERP implementation consultant actually does; use that as your reading guide.

4. Here is one of our processes. How would you handle it?

Pick a process you privately suspect is a habit rather than a requirement, say a three-step manual approval that only exists because the old system had no approvals. Describe it as if it were sacred and ask how they would build it.

The answer you want starts with a question back: why does the business do it this way? Then a description of what the standard system does, what it would cost to customise, and what that customisation costs again at every upgrade. The answer you do not want is "we can build that". A partner who agrees to everything in the sales call will bill for everything in the project.

5. Which of our requirements would you push back on, and which would you refuse?

Send the requirements list in advance and ask them to come back with it sorted into three piles: legal or tax requirements that must be met exactly, operational needs that can be met several ways, and preferences. Then ask which items they would argue against.

How to check: a partner who returns the list untouched, or sorts everything into "must have", will not protect you from your own wish list.

6. Who owns the code, the configuration and the environment?

Ask where custom modules live, whether the repository is in your name, who holds the admin credentials for staging and production, and what you walk away with if the relationship ends after three months. The right answer is that everything is in accounts you control, in writing, from day one.

How to check: ask to see the handover document they gave their last departing client. If none exists, no client has ever left cleanly.

7. What is the upgrade path for every customisation you are proposing?

For each custom piece in the proposal, ask who carries it forward when the ERP releases its next major version, how long that takes and what it costs. A partner who has thought about the second year of your system is thinking about your total cost. One who has only thought about go-live is thinking about their invoice.

8. When your estimate turns out to be wrong, who pays?

Every estimate is wrong somewhere. Ask how they handle it: what counts as a change, how a change is priced and approved, and whether there is any part of the budget they absorb. A firm that has never had to answer this question has not run many projects, or has not been honest about them.

The Answers at a Glance

Question	An answer that reassures	An answer that worries
Who does the work?	A name, a share of their time, a cover plan	"A senior consultant and two analysts"
One project like ours you ran?	Specific decisions, a regret, what changed	A firm case study, no first person
Show me a finished document	A redacted fit-gap with reasons per decision	"Our methodology is proprietary"
How would you handle this process?	"Why does the business do it that way?"	"We can build that"
What would you push back on?	A sorted list and a short argument	The list returned unchanged
Who owns what?	Your repository, your accounts, from day one	"You get the modules at the end"
Upgrade path?	A per-customisation answer with a cost	"We'll deal with that when it comes"
When the estimate is wrong?	A defined change process, a named approver	A pause, then "that rarely happens"

What a Vendor Partner Badge Tells You, and What It Does Not

Buyers often use a vendor's partner programme as a shortcut, so it is worth being precise about what a badge measures. Odoo's partner programme page, for example, lists four levels, Learning, Ready, Silver and Gold, and names the inputs that set a level as new Odoo Enterprise users per year, certified active internal resources and a minimum retention rate (Odoo, become a partner). In plain words: licence sales volume, certified headcount and whether customers stay.

Those are useful signals of commercial health and of vendor access, which matters if you need licence resale or an escalation path. They say nothing about whether the specific person assigned to you writes decisions down, tests on staging, or will tell you no. Treat the badge as a filter for vendor-access needs, not as a proxy for delivery quality, and ask the badge-holder the same eight questions as everyone else.

For the record: the author of this post does not carry a partner badge from any ERP vendor at present, and the same questions apply.

Part Two: Buy a Week Before You Buy a Project

The single most reliable evaluation step is to pay for a small, bounded piece of real work before signing the implementation contract. Call it a paid discovery, an audit, or a scoping engagement. The recommended shape:

• One flow, end to end. Pick your most important process, usually quote to cash or procure to pay, and have the partner map it from a real transaction, including the exceptions.
• A requirements list for that flow, sorted legal, operational, preference.
• A fit-gap for that flow, with a decision and a reason for every gap.
• A data note, stating what would move, what would be archived, and an honest view of the data quality they saw.
• A scoped proposal for the full implementation, built from the above.

Make the output yours in the contract, so you can hand it to a different vendor if you choose to. Then read the proposal against the discovery. If the discovery found data problems and the proposal does not mention migration risk, the proposal was written to win, not to deliver. If the proposal arrives at exactly the budget you mentioned in the first call, ask what fell out to make it fit.

What the paid test shows you that no reference call can: who turned up, how they handled your messy spreadsheet, whether their questions were about your business or their modules, and whether the documents they produced match the ones they showed you in question three.

The first week of the Odoo implementation sprint offered on this site is a discovery: process mapping, module selection and the implementation plan, written down before any build week starts. A partner who refuses a paid discovery, or who insists on the full contract before any discovery, has already answered question eight.

Part Three: Answers That Should End the Conversation

Some answers are not weaknesses to weigh against strengths. They are exits.

• "You'll meet the team after signing." You are buying a person's judgement. You have not met the person.
• "We'll customise it to match your current process exactly." The most expensive sentence in ERP: every habit you have becomes code you maintain at every upgrade.
• "We don't need a staging environment for a project this size." Changes made on the live database are experiments on your books.
• "The code lives in our repository. You get the modules at the end." That is a hostage arrangement with a nicer name.
• "We don't do discovery. We've seen it all before." Nobody has seen your data.
• A fixed price before any discovery. The price is a guess, and the guess will be recovered from you through change requests.

Decide in advance that hearing one of them ends the evaluation, so that a good presentation cannot talk you out of it in the room.

How to Use References Without Being Steered

References are chosen by the partner, so they will be happy clients. You can still get evidence out of them by asking checkable questions rather than questions about satisfaction:

• Did the people named in the proposal do the work, for the whole project?
• Did you receive a fit-gap document, a cutover plan and a migration reconciliation? Could you find them today?
• What was the first thing that failed during go-live, and how was it handled?
• Three months after go-live, how often did you need the partner for something small?

The last one is a particularly useful test: if every small question still goes back to the partner months later, the knowledge transfer did not happen.

The Evaluation Sheet

Before you sign, you should be able to tick every line:

• I have met, by name, the people who will do discovery, configuration and migration.
• The named consultant walked me through one project they personally ran, including what went wrong.
• I have seen a redacted fit-gap, cutover plan, reconciliation and decision log from a finished project.
• They asked why before saying yes to one of our workarounds, and sent our requirements back sorted, with pushback.
• Code, configuration and environments are in accounts I control, in writing.
• Every proposed customisation has an upgrade path and a cost next to it, and the change process has a named approver.
• I paid for a discovery, I own its output, and the proposal matches it rather than my budget.
• References answered the checkable questions.

An empty line is a gap in your evidence, not a mark against the partner: go back and collect it before you decide. And if your own side of the project is not settled yet, start with what to settle first in an ERP implementation.

Frequently Asked Questions

What is an ERP implementation partner?

An ERP implementation partner is the firm or individual who turns your business processes into a configured, tested ERP system and a team that can run it: discovery, fit-gap decisions, configuration, data migration, testing, training, cutover and early support. The word "partner" is also used by vendors for firms in their reseller programmes, which is a commercial status, not a description of delivery quality.

How many ERP implementation partners should I evaluate?

Enough to compare, few enough to run the paid test: for most small and mid-sized companies, two or three after the first calls, with a paid discovery from one or two of them. The discovery is the costly part of the evaluation in time, so a long list defeats it.

Is a vendor partner badge a guarantee of quality?

No. Odoo's programme, for example, sets its levels by licence sales, certified headcount and customer retention: signals of commercial health and vendor access, not of whether the person assigned to your project writes decisions down, tests on staging or pushes back on bad requirements. Ask a badge-holder the same questions as everyone else.

Can I evaluate an ERP partner without running a formal RFP?

Yes, and for smaller projects it is often the better route. A formal request for proposal compares documents. The method here compares evidence: named people, real artefacts, observed pushback, ownership in writing and a paid week of real work. Use the formal process when procurement rules require it, or when the project is large enough that the overhead is small by comparison.