Choosing an ERP implementation partner
An ERP implementation partner is the firm that configures your ERP system, connects it and puts it into use. The system sets the limit of what is possible; the partner decides how much of that you actually get.
Which parties exist
What stays yours
How to test before signing
What does an ERP implementation partner do?
The partner translates your processes into the system: configuration, integration with the software you already run, moving your data across, training your people and staying with you past go-live. What a given firm actually does varies widely, and that variation rarely appears in the quote.
Two companies on the same system can end up with entirely different results.
The system sets the limit of what is possible. Within that limit the partner decides how much you see of it: which processes were genuinely thought through, how quickly problems get resolved, and how much knowledge is left behind when the project ends.
Which kinds of firms can implement your ERP?
There are five kinds. All of them call themselves a partner, but their interests differ. That interest is not an accusation, it is the reason their advice differs.
What they do and where their interest sits
| Role | What they do | Where their interest sits |
|---|---|---|
| Software vendor | Builds and maintains the system itself. Sells licences and sometimes supplies its own consultants. | More users on their own system. Rarely the party that has to explain your configuration years later. |
| Vendor-certified partner | Implements the system on the vendor’s behalf, certified on that one product. | Revenue on hours and on licences. The system is fixed, so advice covers the how, never the whether. |
| Independent implementation firm | Implements without vendor ties, often across several systems. | Revenue on hours. Can advise across systems, but is still the party doing the building. |
| Contractors or your own team | Supplies specialists who work inside your organisation under your direction. | Keeping people billable. Control and risk stay with you. |
| Client-side adviser | Tests choices, guards the scope and judges progress. Does no building. | No stake in the system or the vendor, and therefore able to organise dissent. |
We sit in that last category ourselves. ERP Company does no building and holds no partnership with software vendors, so we have no stake in which system you choose. That is exactly why we can describe the other four plainly.
What does the partner take on, and what stays yours?
Most conflicts in an implementation are not about technology but about this split. Six subjects that go wrong the moment nobody has said out loud who owns them.
What the partner does and what stays yours
| Subject | The partner | You |
|---|---|---|
| Process decisions | Shows what the system supports as standard and what needs adapting. | Decides which process changes and which exception is dropped. This is not an IT decision. |
| Data quality | Supplies the migration tooling and the structure the system demands. | Owns the content. Dirty data stays dirty after migration. |
| Testing | Checks that what was built works as agreed. | Checks that it works the way your people work. Only you know the exceptions. |
| Training | Trains key users on the system. | Makes sure that knowledge survives someone leaving. Otherwise you buy the training twice. |
| Deciding under pressure | Reports the problem and sketches the options. | Chooses between delay, a leaner scope or extra work. Leave this to the partner and it is always extra work. |
| Support after go-live | Resolves incidents and makes changes within the agreement. | Keeps track of what was adapted and why. Without that record, custom work grows unnoticed. |
How do you test a partner before you sign?
Comparing quotes tells you little, because every firm writes that it has experience in your sector. These six tests do separate them, because they measure behaviour instead of promises.
Measuring behaviour pays off, because it rarely goes wrong on technology. In the 2026 ERP Report by Panorama Consulting, almost a quarter of organisations reported going over schedule, and the most common cause was organisational: decision-making, resistance to change and process redesign.
Ask for the team by name
A proposal names roles, not people. Ask who the consultant will be, how many days a week they are available, and which other projects they are booked on at the same time.
A firm that will not name people has not settled the staffing yet.
Run the demonstration on your own scenario
Bring your own orders, your own exceptions and your own month-end close. Ask the consultant to say out loud where the standard stops and adaptation begins.
A canned demonstration tests the salesperson, not the partner.
Ask about a project that went badly
Ask what went wrong, when they noticed, and what they changed structurally afterwards. Keep asking until you hear the decision they took at the time.
A firm that can only name successes has done little or learned little.
Speak to references without the partner present
Do not ask whether they were satisfied. Ask which moment was the most uncomfortable, how long an open issue typically stayed open, and whether the same people stayed until after go-live.
A reference the partner arranges and attends carries no information.
Agree the escalation route in advance
Agree who decides when schedule, scope and budget squeeze at once. Add within what period that conversation happens and who sits at the table.
An escalation route invented during the escalation always costs time.
Make knowledge transfer a deliverable, not a promise
Name which documentation, configuration decisions and support tasks are handed over, to whom, and when. Attach a formal acceptance to it.
Without an acceptance moment you stay dependent on the firm that built it.
How do you recognise the fit beforehand?
The conversations before the signature already hold a lot of information, provided you know what to watch.
Good signs
- They ask about your processes before they start on the system
- They point out themselves what the system cannot do as standard
- They name the team in the proposal
- They ask for your own data for the demonstration
Reason to keep asking
Everything is possible
Every question gets a yes. That rarely means it works as standard, and often means the bill arrives later as custom work.
The discount expires this month
Time pressure on the signature is a sales technique, not a project argument. A partner who takes your project seriously wants you able to defend the choice.
The team changes after the sale
The people at the sales table are not the people who turn up. Ask before signing who actually starts and how long they stay.
Frequently asked questions
- What is an ERP implementation partner?
An ERP implementation partner is the firm that configures your ERP system, connects it and puts it into use. They translate your processes into the system and support your people past go-live.
The system sets what is possible, the partner sets what you actually get. That distinction explains why two companies on the same system can end up somewhere very different.
- What is the difference between a vendor and an implementation partner?
The vendor builds and sells the software. The implementation partner puts that software to work in your organisation. Sometimes they are the same firm, more often not.
The difference counts when something goes wrong. A partner tied to the vendor looks for the answer inside that product, and that is not always the cheapest route for you.
- How do you choose the right ERP implementation partner?
Judge the partner separately from the system, and test on staffing, sector experience and behaviour under pressure rather than on the quote.
The hardest test is the reference you arrange yourself, without the partner present. That is where you hear how long problems stayed open and whether the same people stayed.
- Can you run an ERP implementation without a partner?
You can, if you have the knowledge and the people, and the system stays close to standard. In practice the limiting factor is availability, not knowledge.
A middle course often works better: your own people do the work, with guidance at the moments where it tends to go wrong. The knowledge then stays in house.
- When do you switch to a different partner?
When the same problems keep returning, the team keeps changing, or agreements are structurally revised without anyone taking a decision about it.
Switching costs time and knowledge, so it is rarely the first step. Start with an independent test of what is actually stuck: sometimes the constraint sits in the brief, not in the partner.
Further reading
This page describes the field and the tests. The articles below go deeper into the criteria themselves and into the independence of the parties around you.
- Choosing an implementation partner: seven criteria
- What independent advice is, and what it is not
- Why a neutral view changes the outcome
- Keeping control without partner ties
Have a partner choice reviewed
We assess candidates from your side of the table and review choices already made. Because we do not implement ourselves and hold no vendor ties, we have no stake in which firm it becomes.
Where we help
- Testing candidates before you sign
- Reviewing the contract and the escalation terms
- A second opinion when a project stalls