How we answer these questions ourselves is set out on partnership and technologies.
What goes wrong after the partner is chosen: why ERP implementations fail.
The partner matters more than the software
Business Central is the same product for everyone. Two companies of identical size implementing the same modules can end up with wildly different outcomes, and the variable is almost never the software.
This is uncomfortable to write as a partner, so we will be direct about the incentive: we would rather lose a project to a better-suited firm than take one we cannot deliver well. The questions below are the ones we would want asked of us.
Four types of partner
| Type | Strength | Weakness |
|---|---|---|
| Global consultancy | Multi-country capability, formal methodology, survives staff turnover | Cost per user is disproportionate below roughly a hundred users; you rarely get their senior people |
| Established local partner | Knows local statutory rules, reachable, proportionate pricing | Capacity limits; may not have depth in your industry |
| Boutique or specialist | Deep in one industry or one module, often the best technical work | Key-person risk; a two-person firm has no bench |
| Freelancer | Cheapest, fast on narrow tasks | No continuity. Reasonable for a defined piece of work, risky for a whole implementation |
There is no universally right answer, but there is a common mismatch: mid-sized companies engaging global consultancies because the brand feels safe, then paying enterprise rates for junior consultants. If you are under a hundred users, an established local partner is usually the better economics.
Nine questions that actually separate them
Feature questions do not differentiate — every partner answers yes. These do.
About the work
- Which two projects most resemble ours, and can we speak to those clients? Not a reference list. Two specific projects and two conversations.
- Who will actually do the work? Names and roles. The people in the pitch are frequently not the people on the project, and it is fair to ask this directly.
- What in our requirements does not fit standard Business Central? A partner who says everything fits has not read the requirements. A good answer names two or three specific gaps and what they would cost.
- What would you advise us not to do? The single most revealing question. Anyone who cannot name something you should skip is selling rather than scoping.
About the risk
- What happens if the project runs over? Fixed price, time and materials, or capped. Each is defensible; vagueness is not.
- How are extensions built? They must be extensions rather than base modifications, or every twice-yearly update becomes a project. Covered in when AL customisation pays off.
- Who owns the code and configuration? If you change partner, what transfers, and in what form?
About afterwards
- What does support look like in week three after go-live? That is the hard week. Response times and named contacts, not a general commitment.
- What happens when the law changes? For any country with distinctive statutory reporting — who updates the localisation, how fast, and is it billed separately?
How to read a proposal
Comparing proposals is difficult because they are structured differently on purpose. Three things make them comparable.
Give every partner the same written scope. If each is estimating a different understanding of the project, the numbers mean nothing. This is why writing your processes down before approaching anyone pays for itself.
Ask for the breakdown, not the total. Configuration, data migration, extensions, training, support — separately. A single number hides where the risk is, and data migration is almost always the line that moves.
Compare over three years, not one. A low implementation fee with expensive support, or heavy customisation that costs at every update, changes the ranking entirely. The cost structure is broken down in what an implementation costs.
Beware the lowest bid in particular. It usually means the scope was understood differently, and the gap surfaces as change requests in month three.
Warning signs
- Everything fits standard. Nothing ever fits entirely. This answer means the requirements were not read.
- No questions about your data. Data quality is the largest single cost driver. A partner who does not ask about it will discover the problem at your expense.
- The estimate arrives within a day, without discussion. Either they have a template they will make you fit, or the number is not real.
- Pressure on timing. Discounts expiring on Friday belong in retail, not in a project that will run your finances for a decade.
- No named team. If they cannot say who will do the work, it is because they do not know yet.
- Reluctance about client references. Reasonable partners have clients willing to talk. Consistent deflection is information.
What you have to bring
The most common cause of failure is not on the partner's side, so it is only fair to state what the client owes the project.
A named person with authority. A partner cannot decide how your business should work; they can only ask. Without someone empowered to answer, every question waits a week. "The director is responsible" usually means nobody is, because the director does not have several hours a week for two months.
Your processes written down. Plain text, not diagrams. It exposes gaps you did not know about and gives every partner the same basis to quote against.
Clean master data. Duplicate customers and inconsistent item codes migrate into the new system and cost more to fix there. This work needs no contract and no budget — see the data preparation checklist.
A decision about scope. Fix what goes live first, in writing. Scope that grows during the project is the second most common reason budgets double.
Frequently asked questions
How many partners should we approach?
Three is usually right. Fewer gives no basis for comparison; more turns evaluation into a project of its own. What matters more than the number is that all three receive an identical written scope, otherwise the proposals are not comparable.
Is a global consultancy safer than a local partner?
Safer on continuity, rarely better on economics below about a hundred users. You also tend to get their junior consultants at senior rates. For a mid-sized company an established local partner with relevant references is usually the better fit.
Should we choose the lowest bid?
Not without understanding why it is lowest. Usually the scope was interpreted differently, and the gap returns as change requests in month three. Compare the breakdown line by line rather than the totals.
What if we need to change partner mid-project?
Possible, and easier if the work was done to standard: extensions rather than base modifications, documented configuration, and your ownership of the code agreed in the contract. Ask about this before signing, not when you need it.
Do we need a partner in our own country?
For the statutory layer, usually yes — local compliance is local by definition. The group template can come from anywhere. Many multi-country projects run exactly this way, with the boundary between the two written into the contract.
How long should choosing take?
Four to eight weeks from writing the scope to signing. Faster usually means the scope was thin; much slower and the requirements start drifting before work begins.