Choosing a Business Central partner: questions that predict success

Choosing the wrong Microsoft Dynamics 365 Business Central partner is one of the most expensive mistakes a business can make. Not because the software will fail you, but because the people delivering it will. This guide gives you a structured question set to pressure-test any Business Central implementation partner before you sign.

Every partner looks the same until the project starts

The proposals tend to read well. Confident timelines. Familiar logos. Reassuring references to Microsoft accreditations. By the time you’re comparing two or three shortlisted partners, you’re often working with documents that look almost identical.

The problem surfaces later. During discovery, when the scoping assumptions turn out to be wildly optimistic. During data migration, when nobody has a clear plan for what moves across and what doesn’t. Or in the three months after go-live, when your finance team is raising issues and the partner’s support model turns out to be a shared inbox with a two-day response time.

ERP regret is real and it’s expensive. It shows up as cost overruns, extended timelines, demoralised teams, and management information you still can’t trust six months after switching on. The good news is that most of these problems are predictable and preventable—if you ask the right questions at the right time.

The questions below are grouped by risk area. Use them as a due diligence framework when evaluating your shortlist. A strong partner will answer them clearly and specifically. Vague answers, deflection, or a pitch for customisation you didn’t ask for are all worth noting.

1. Discovery and scoping

How a partner approaches the initial scoping phase tells you almost everything about how they’ll run the whole project.

Ask:

• What does your discovery process look like, and who leads it?
• How do you document requirements, and how do those requirements flow into the statement of work?
• What assumptions are you making about our current processes? Where do you expect the most complexity?
• How do you handle requirements that emerge after the SOW is signed?

✔ What good looks like: A structured discovery process led by an experienced consultant, not a sales engineer. A clear methodology for turning requirements into documented scope. Honest answers about where projects like yours tend to get complicated.

⚠ Red flag: A partner who rushes to demo before asking in-depth questions about your processes, or who produces a statement of work in days without meaningful engagement.

2. Process design versus customisation

One of the most consequential conversations you’ll have with a Business Central partner is about customisation. Specifically: how much, when, and who decides.

Ask:

• What’s your approach when a client’s current process doesn’t match standard Business Central functionality?
• How do you challenge legacy processes versus adapting the software to fit them?
• Can you walk us through your extension and customisation policy?
• What percentage of your implementations go live with significant customisation?

✔ What good looks like: A partner who starts by challenging the process, not reaching for the development team. Customisation should be a considered, documented decision—not a default response to any friction point.

⚠ Red flag: “We always customise to fit your business.” Over-customisation drives cost, complexity, and dependency. It also makes every future upgrade harder.

3. Data migration

Data migration is consistently where Business Central projects run over time and budget. A credible partner will have a clear, tested methodology and won’t gloss over the hard questions.

Ask:

• What data migration methodology do you use, and what does each phase look like?
• How do you handle data cleansing and validation before migration?
• What’s your approach to reconciliation after go-live? How do we confirm the numbers are right?
• What data won’t migrate cleanly, and how do we manage that?
• How do you maintain audit trail integrity across the transition?

✔ What good looks like: A phased migration process with formal sign-off gates. A clear position on data cleansing responsibilities. A reconciliation plan that gives your finance team confidence before cutover.

⚠ Red flag: Vague answers about “doing a data dump” or an assumption that your data is in better shape than it probably is.

4. Integrations

Most small and mid-sized organisations need Business Central to connect with something else—payroll, banking, a CRM, a warehouse management system. Integration failures are a common source of go-live delays.

Ask:

• Which integrations does our project require, and how do you approach each one?
• How do you test end-to-end processes across integrated systems before go-live?
• What happens if an integration doesn’t work as planned? How is that handled commercially?
• Do you build integrations in-house, or do you use third-party tools or ISV solutions?

✔ What good looks like: Named integration experience. A clear testing plan covering the full process, not just individual systems. Transparency about who is responsible when something sits between two platforms.

⚠ Red flag: Enthusiasm about integrations with no specifics, or a pattern of using change requests to price integration work that should have been scoped upfront.

5. Testing and cutover

The weeks immediately before go-live are high-pressure. A well-prepared partner will have a rehearsal plan and a fallback position. An underprepared one will be improvising.

Ask:

• What testing phases does your implementation methodology include?
• Do you run a parallel period or a dress rehearsal cutover? How is that structured?
• What’s your rollback plan if something goes wrong on go-live day?
• Who from your team is on-site or available during cutover?

✔ What good looks like: A named cutover plan, a tested rollback position, and experienced staff present during the critical window. Confidence without overconfidence.

⚠ Red flag: No clear parallel run or rehearsal. Cutover handed entirely to the client. A rollback plan that amounts to “we’ll deal with it if we need to.”

6. Security and permissions

This is often underprepared and the consequences show up in audit findings or control weaknesses that are expensive to fix retrospectively.

Ask:

• How do you approach role design and permissions configuration?
• How do you ensure segregation of duties in the finance function?
• What’s your process for reviewing and signing off the permissions model before go-live?
• Who is responsible for ongoing permissions management post go-live?

✔ What good looks like: A structured approach to role design, with finance and IT aligned on who approves what. Segregation of duties treated as a non-negotiable, not an afterthought.

⚠ Red flag: Permissions copied from a previous implementation without review. No clear process for sign-off before go-live.

7. Change management and training

Technology rarely fails ERP projects. People do. Adoption risk is real, and it’s the partner’s job to help you manage it.

Ask:

• What change management support do you provide, and how is it structured?
• Who delivers training, and how is it tailored to different user groups?
• How do you measure whether users are actually adopting the system?
• What training resources are available to us after go-live?

✔ What good looks like: A change management plan that starts before training, not the week before go-live. Role-specific training, not a single generic walkthrough. Ongoing resources your team can access independently.

⚠ Red flag: Training treated as a delivery checkbox rather than a programme outcome. No post-go-live learning support.

8. Project governance

Clear governance is what prevents scope creep, resolves disagreements, and keeps a project on track when things get complicated.

Ask:

• What does your RACI model look like for a project like ours?
• How often does your steering group meet, and who attends?
• How do you manage scope changes? What triggers a change request versus being handled within scope?
• If there’s a disagreement between our team and yours, how is it escalated and resolved?

✔ What good looks like: A documented governance structure with named roles on both sides. A clear and fair change control process. Escalation paths that don’t require a formal dispute to work.

⚠ Red flag: Governance described loosely or entirely dependent on the client managing their own scope. A change control process that feels designed to generate additional revenue rather than manage risk.

9. Support after go-live

The go-live date isn’t the end of the engagement—it’s the beginning of the operational phase. How your partner behaves in the six months after switch-on is what determines whether you’d recommend them.

Ask:

• What does your hypercare period include, and how long does it run?

  (Note: Hypercare is the intensive, hands-on support window immediately after go-live — typically two to four weeks — when your partner stays close to help resolve issues quickly before stepping back to standard support.)

• What are your SLAs for support issues by severity? Who do we contact and how?
• How do you manage Microsoft release waves and updates? What’s our involvement?
• How is ongoing support staffed? Will we have named contacts?

✔ What good looks like: A structured hypercare period with named support staff. Clear SLAs. A proactive approach to managing updates rather than leaving it to you.

⚠ Red flag: Support handed off to a generic helpdesk on day one. No named contacts. SLAs that don’t differentiate between a cosmetic issue and a finance function outage.

10. Commercial model

The commercial conversation is where misalignment tends to surface. A well-structured commercial model protects both parties. A poorly structured one creates perverse incentives.

Ask:

• Is your pricing fixed price or time and materials? What are the conditions and assumptions built into a fixed-price quote?
• What triggers a change request under your model?
• How are licences structured, and when are you expecting us to purchase them?
• What are the payment terms, and are they milestone-linked?

✔ What good looks like: Clear assumptions documented in the statement of work. Milestone-based payments aligned to delivery. A transparent change control process, not left to the partner’s discretion.

⚠ Red flag: Pressure to purchase licences early. Vague assumptions that leave you exposed to change requests for almost anything. Time-and-materials pricing with no ceiling or cap.

Evidence to request

Questions alone aren’t enough. Ask your shortlisted partners for:

• A sample statement of work from a comparable implementation
• A sample project plan with milestones and dependencies
• References from clients of similar size and sector, with permission to speak to the finance lead (not just the IT lead)
• An example of how they’ve managed a project that went off-track and what the outcome was

How a partner responds to these requests tells you as much as the documents themselves.

Red flags: a quick reference

If you hear any of the following during the evaluation process, probe further or reconsider:

• “Our timeline is very competitive” with no explanation of how
• “We’ll customise to fit your processes” as a default position
• Discovery delivered in days without structured workshops
• Reluctance to provide references who aren’t pre-briefed
• Governance described as “we’re pretty flexible on that”
• Support described without named contacts or SLA specifics
• Licence purchase pushed before scope is agreed

How to compare Business Central partners objectively

Once you’ve completed your question sessions, structure your comparison around these areas: discovery discipline, data migration methodology, integration experience, governance model, support structure, and commercial clarity. Weight each area by what matters most to your organisation.

A scored comparison matrix helps, but don’t let it obscure obvious qualitative signals. A partner who answers every question specifically, honestly, and without overselling is demonstrating the culture you’ll be working with for the next twelve to eighteen months.

If you’d like to talk through your partner shortlist or get an independent view on your implementation readiness, talk to a dynamics 365 partner at TSG.

Why TSG?

Choosing the right Microsoft Dynamics 365 Business Central partner is a governance decision as much as a procurement one. The questions in this guide are designed to surface how a partner actually works, not how they present. Used consistently across your shortlist, they give you a defensible basis for a decision your Board and your finance team can stand behind.

If you’d like an independent view on your readiness for a Business Central implementation or want to talk through what a well-governed project looks like, get in touch with TSG.

Frequently asked questions

What questions should we ask a Business Central partner before signing?

Focus on discovery methodology, data migration approach, integration experience, post-go-live support structure, and commercial model. Ask each partner the same set of questions and compare responses. Specific, honest answers indicate delivery quality. Vague or defensive answers are a meaningful signal.

How do we compare Business Central partners objectively, beyond price?

Score partners across discovery discipline, data methodology, governance model, support SLAs, and commercial clarity. Request comparable evidence: sample SOWs, project plans, and references from similar-sized finance leads. Weight criteria by your risk priorities, and treat qualitative signals as seriously as scored responses.

What’s the biggest reason Business Central implementations fail?

Poor discovery and scope discipline, followed by underinvestment in data migration and change management. Most failures trace back to assumptions baked in at the proposal stage that were never validated. A partner with a structured discovery process and honest scoping practice significantly reduces this risk.

Should we choose a partner with sector experience, or prioritise process expertise?

Both matter, but process expertise is harder to fake. Sector experience helps with terminology and common workflows; process expertise determines whether your implementation is governed well. Ask sector-specific questions, but weight their answers to governance, data, and support as heavily as their industry credentials.

What should post go-live support include for Business Central?

A structured hypercare period with named contacts, clear SLAs by issue severity, a proactive approach to Microsoft release management, and accessible training resources. Support that’s handed off to a generic helpdesk on day one is a common source of dissatisfaction and cost in the months following go-live.

Fixed price or time and materials: which contract model reduces ERP risk?

Fixed price provides cost certainty but only if the assumptions are well-documented and fair. Time and materials offers flexibility but requires rigorous governance to prevent scope expansion. Either model can work; what matters is the clarity of the statement of work and the integrity of the change control process behind it.