By 365vanguard · 8 July 2026
The software won’t fail you. The partner might.
Microsoft Dynamics 365 Business Central is mature, stable, and well-documented. The product works. What varies enormously — and determines whether your project succeeds or becomes an expensive lesson — is the partner who configures it, integrates it, and supports it after go-live.
This isn’t a generic “10 tips for choosing a partner” post. This is the list of questions we wish every prospect asked us before signing — and the answers that separate partners who deliver from partners who sell.
Why This Decision Is Worth More Time Than You’re Giving It
Switching partners mid-implementation costs more than you think. Not just in money — in momentum, in trust from your team, in data migration delays, in months of lost progress. We’ve taken over projects from partners who:
- Promised a senior consultant and staffed a junior. The client didn’t know enough to check names on LinkedIn.
- Quoted fixed-fee and then invoiced every design decision as “out of scope.” The contract was vague by design.
- Delivered a system where basic processes — purchasing approvals, month-end close — required workarounds. The partner had never actually implemented a manufacturing company before.
- Disappeared after go-live. Support tickets went to a generic queue. Nobody answered.
All four of these were avoidable with the right questions during selection. Here they are.
Section A: The Twelve Questions
1. How many Business Central implementations has your firm delivered in the last 24 months?
Why it matters: Volume matters, but specificity matters more. A partner who says “hundreds” is guessing or inflating. A partner who says “fourteen” can probably name them.
What a good answer sounds like:
“Fourteen full-cycle implementations. Seven in manufacturing, four in distribution and wholesale, three in professional services. The smallest was a 12-user company. The largest was an 85-user multi-entity deployment across three countries.”
What a bad answer sounds like:
“We’ve done a lot — probably a couple hundred over the years. We work with companies of all sizes.”
If they can’t give you a specific number, they don’t track their projects. If they don’t track their projects, they don’t learn from them.
2. Can I speak to two reference clients with a profile similar to mine?
Why it matters: Every partner has happy clients. The question is whether those clients look anything like your business — same industry, same size, same complexity.
What a good answer sounds like:
“Let me give you three names. One is a 40-person manufacturing company similar to yours — I’ll send over the finance lead’s direct number. The other two are larger but same industry. All three agreed to take calls.”
What a bad answer sounds like:
“Most of our references are confidential — NDAs, you know how it is. But we can show you a case study.”
If references are “confidential,” there aren’t any. Every successful project produces at least one happy client willing to take a 15-minute call.
3. Who exactly will work on my project? Can I meet them before signing?
Why it matters: The person selling you the project is rarely the person delivering it. Ask for names, LinkedIn profiles, and years of Business Central experience. Meet the project manager and the lead consultant before you commit.
What a good answer sounds like:
“Your project manager will be [name] — here’s their LinkedIn. They’ve managed 9 BC implementations. Your lead functional consultant is [name] — they’re certified in manufacturing and finance. Let’s set up a call with both of them this week.”
What a bad answer sounds like:
“We build the team after the contract is signed, based on availability. All our consultants are senior.”
Translation: you’ll get whoever isn’t busy. And “all senior” usually means “some are, some are three months in.”
4. How many concurrent projects will my lead consultant be running?
Why it matters: A consultant running four active implementations simultaneously is context-switching constantly. Your project gets 25% of their brain. The ones where they need to answer “how many other projects” with a number higher than three are probably stretched.
What a good answer sounds like:
“At most two active implementations at a time — and they’re usually staggered so one is in testing while the other is in design.”
What a bad answer sounds like:
“Our consultants are very efficient — they can handle multiple projects at once.”
Efficient means burned out by month six.
5. What is your implementation methodology? Walk me through the phases.
Why it matters: If a partner can’t describe their methodology without PowerPoint, they don’t have one. You want a repeatable process, not improvisation.
What a good answer sounds like:
“We follow an eight-phase agile approach: Initiation, Requirements, Solution Design, Build & Configure (sprints), Data Migration (parallel track), Testing & UAT, Training, and Go-Live with hypercare. Each phase has defined deliverables and sign-offs. Want to see a sample project plan we used for a company your size?”
What a bad answer sounds like:
“Every project is different — we adapt our approach to the client’s needs.”
“Adapt” means “we’ll figure it out as we go.” You wouldn’t accept this from a builder constructing your house. Don’t accept it from a partner building your ERP.
6. How do you handle data migration — specifically, data cleansing?
Why it matters: Data migration is 20–30% of any serious implementation, and it’s where most projects go sideways. If the partner doesn’t bring up data cleansing in the first conversation themselves, that’s a red flag.
What a good answer sounds like:
“We provide data templates for you to populate. We do a profiling pass on your data first — duplicates, missing fields, inconsistent formats. You own the cleansing; we guide you through it. We run a minimum of two migration dry runs before go-live, and we reconcile against your legacy trial balance after each one.”
What a bad answer sounds like:
“Yes, we do the data migration. We’ll pull it from your old system.”
No mention of cleansing, dry runs, reconciliation, or who owns what. You’ll discover corrupted records on go-live day.
7. How transparent are your costs — and what triggers a change request?
Why it matters: “Out of scope” is the most expensive phrase in ERP. You need a written definition of scope and a clear change request process before you sign anything.
What a good answer sounds like:
“Here’s our fixed-fee proposal with line items for each phase. Things that are included: configuration of standard BC features, data migration from your legacy system (two dry runs), standard training sessions, and 30 days of post-go-live hypercare. Things that trigger a change request: custom AL development beyond what’s specified, integrations to systems not listed in the scope, and additional training sessions. Our change request process is: document the change, estimate the impact on cost and timeline, get your written approval, proceed.”
What a bad answer sounds like:
“We’re very flexible — we work within budget and sort things out as they come up.”
“Sort things out” means you’ll get invoices you didn’t expect for work you didn’t approve.
8. What’s your fixed-fee vs time-and-materials pricing model — and why?
Why it matters: Both models work, but they work differently. Fixed-fee gives you cost certainty but tempts the partner to rush. Time and materials gives flexibility but no cap. A good partner explains the tradeoffs honestly.
Real numbers for context:
| Scope | Typical Partner Fee |
|---|---|
| Lightweight (finance core, clean data) | €8,000–15,000 |
| Standard (finance + supply chain, integration) | €18,000–40,000 |
| Complex (multi-entity, manufacturing, custom dev) | €45,000–90,000+ |
What a good answer sounds like:
“We typically use a hybrid: fixed fee per defined phase, time and materials for change requests and post-go-live enhancements. Here’s why — fixed fee per phase protects you from budget overruns on the defined scope. Time and materials for changes is honest: neither of us can predict exactly what you’ll want three months in.”
9. How do you handle Business Central’s twice-yearly update waves?
Why it matters: Microsoft releases two major updates per year. Every extension, integration, and customization needs to be tested against the new version. A partner who ignores this is a partner whose system breaks in April and October.
What a good answer sounds like:
“We track Microsoft’s release schedule. For our support clients, we test their environment in a sandbox before each wave, identify breaking changes, and apply fixes before the update is forced. This is included in our support agreement — not an extra charge.”
What a bad answer sounds like:
“The updates are automatic — Business Central handles them. Our extensions are built to be upgrade-proof.”
Nothing is upgrade-proof. Every extension needs testing. A partner who claims otherwise hasn’t been doing this long enough.
10. What happens after go-live? Describe your support model.
Why it matters: Go-live is the beginning, not the end. You’ll need help for months afterwards — training new hires, tweaking configurations, fixing things you didn’t catch in UAT.
What a good answer sounds like:
“We include 30 days of hypercare in the implementation fee — priority support with a dedicated consultant. After that, support is available as prepaid blocks (typically 20–50 hours), an annual retainer, or ad-hoc. Average response time: same business day for critical issues, 24 hours for standard tickets. You have a named support contact, not a ticket queue.”
What a bad answer sounds like:
“We’re always here for our clients — just reach out if you need anything.”
No structure, no SLA, no named contact. You’ll reach out and hear nothing.
11. Will you push back when our requests don’t make sense?
Why it matters: This is the most revealing question. A great partner says yes and gives you examples. A bad partner says they always do what the client wants. You don’t want a yes-person building your ERP.
What a good answer sounds like:
“Absolutely. We had a client who wanted to customize the entire GL posting process because their old system did it differently. We pushed back and showed them how BC’s standard posting groups handled the same scenarios — cleaner, with less maintenance. They agreed. Saved them €12,000 in custom development and years of upgrade headaches.”
What a bad answer sounds like:
“We always do what the client wants. You’re the expert on your business.”
No. You’re the expert on your business; they’re the expert on Business Central. The whole point of hiring a partner is that they know things you don’t. A partner who never says no is outsourcing every decision to you — and invoicing you for the consequences.
12. Show me an example of AL code you’ve written for a client.
Why it matters: Code quality is the difference between an extension that survives five upgrade waves and one that breaks at the next release. If you’re not technical, send it to someone who is. But at minimum, asking the question signals that you care about what’s under the hood.
What a good answer sounds like:
“Here’s a GitHub repo with sanitized examples of our extension patterns — event-based architecture, no code in standard objects, upgrade-safe design.”
What a bad answer sounds like:
“Our code is proprietary — we can’t share it.”
Every partner says this. The good ones have sanitized examples they’re happy to show.
Section B: The Red Flags Checklist
Before signing any contract, check for these:
- They can’t give a specific project count. If they don’t know how many implementations they’ve done, they don’t track their work.
- The person selling isn’t the person delivering. Salespeople who won’t introduce the delivery team are hiding something — usually a junior staff with no Business Central experience.
- No data migration discussion. If data cleansing, dry runs, and reconciliation aren’t mentioned in the first or second conversation, they’re not in the plan.
- “We never go over budget.” Nobody never goes over budget. Clients change scope, discover bad data, add integrations. An honest partner explains how scope changes work; a dishonest one pretends it never happens.
- No post-go-live support structure. “We’ll support you” without an SLA, a named contact, and a defined process is not support — it’s a wish.
- They haven’t asked about your industry. If they’re pitching a solution without understanding whether you’re a manufacturer, distributor, or retailer, they’re selling software, not solving problems.
- High consultant turnover. Ask what their turnover rate is. If consultants leave every 12–18 months, you’ll lose the person who knows your system.
- Vague answers on pricing. “It depends” is fair once or twice. “It depends” to every pricing question means they’re planning to figure out the price after you’re committed.
Section C: The Weighted Scorecard
When you’re comparing 3–4 partners, run them through a structured scorecard. Assign each a score from 1–5 in every category, multiply by the weight, and total. The numbers will tell you more than your gut.
| Criteria | Weight | Why It Matters |
|---|---|---|
| Project experience in your industry | 25% | The single strongest predictor of success |
| Pricing transparency & scope clarity | 20% | Surprises kill projects |
| Implementation methodology (documented) | 20% | Process beats improvisation — every time |
| Consultant quality (meet the team) | 15% | The people matter more than the brand |
| Post-go-live support structure | 10% | Year 1 is as important as go-live week |
| References & reputation | 10% | Past clients are your best source of truth |
Weighted scores are useful, but here’s a simpler test: after each partner conversation, ask yourself “did I learn something?” A great partner teaches you about your own business during the sales process. A salesperson doesn’t.
Section D: What Nobody Tells You About Switching Partners
You’re not locked in. Many businesses stay with an underperforming partner because they think switching is harder than it is.
How it actually works:
- Your new partner reviews your current BC environment — configurations, extensions, integrations, data structure.
- They identify what’s working (keep it) and what’s not (fix or replace it).
- A handover is coordinated: the outgoing partner exports documentation, the new partner sets up admin access, and a cutover date is agreed.
- Support moves to the new partner. Development continues from your current state. No data loss, no re-implementation.
The hardest part is usually the conversation with your current partner. After that, it’s a process — one that a competent new partner has done before.
Signs it’s time to switch:
- Support takes days, not hours
- You’re still on NAV with no upgrade plan (or a vague one)
- Your partner hasn’t suggested an improvement in six months
- You dread opening a support ticket because you know it means 3 follow-up emails
- Your partner’s consultants keep rotating — you’re training their new hires on your own system
How We Approach It
We’re a Business Central partner and LS Retail Gold Partner. Our implementation process follows the eight-phase agile approach we’ve documented. You’d know your project manager and lead consultant by name before signing. Our pricing is fixed per phase with clear scope boundaries. Your data migration includes profiling, cleansing guidance, two dry runs, and reconciliation.
We also occasionally tell prospects “you might not need Business Central yet” — and we’ve said “that feature you’re asking for — don’t build it. Here’s a simpler way.” The best partnerships start with an honest conversation, not a sales pitch.
If you’re evaluating partners and want to talk through what matters for your specific business, book a discovery call. No obligation — just a real conversation with someone who knows the product and the process.
Not sure if you're ERP-ready?
Take our 2-minute ERP Readiness Scorecard — no signup needed.
Take the scorecard →Get BC insights in your inbox
Practical tips — no spam, ever.
Thanks! Check your inbox.
Something went wrong. Please try again.