10 questions to help you pick the right consulting partner.
You can choose the right ERP and still end up with the wrong implementation. The difference often comes down to your Business Central implementation partner: how well they scope requirements, manage data and integrations, guide adoption, and support you after go-live.
If you’re choosing an ERP partner, polished demos, certifications, and client logos may help narrow the field, but they don’t show how a Business Central consulting team will identify hidden complexity, set realistic expectations, or stay accountable when the plan needs to change.
Why the Partner Is More Important Than the Platform
If you’ve decided on Business Central, the biggest variable is no longer the platform; it is the quality of the implementation.
Adding scope once the project is underway is the leading cause of budget overruns. A recent study found that more than a quarter of organizations exceeded their ERP budgets and roughly a quarter ran past schedule.
Many of those added costs could have been identified before the project started. A thorough partner should uncover integrations, inventory or manufacturing complexity, data-migration responsibilities, and customization needs during discovery – long before they become change orders and delays.
10 Questions Every Business Central Partner Should Be Able to Answer
Ask every partner the same 10 questions, then compare the evidence behind their answers. The table shows what a strong response includes and the warning signs that deserve a follow-up.
| Question | What a Good Answer Sounds Like | Red Flag |
| How many Business Central go-lives have you led in the last two years, and in my industry? | A specific number of Business Central go-lives completed in the past two years, including examples that match your industry, company size, modules, and operating complexity, such as migrating from Dynamics GP. The partner can explain outcomes and provide references you may contact. | The partner relies on NAV or Dynamics GP history, client logos, or company-wide totals without demonstrating recent Business Central results. References are vague, unavailable, or unrelated to your project profile. |
| How did you arrive at this estimate, and what is excluded? | A line-by-line explanation tied to discovery findings, with documented assumptions, exclusions, buyer responsibilities, dependencies, and likely cost triggers. The partner explains what a Business Central implementation costs, what would require a change order, and how it would affect schedule and budget. | You receive a single price with little scope logic, no written exclusions, and unclear buyer responsibilities. Important items such as integrations, data cleanup, testing, training, or support are deferred until after signing. |
| How did you grade my inventory, manufacturing, and integration complexity? | A process-by-process assessment covering locations, item volume, lot or serial tracking, bills of material, production steps, planning, warehouse requirements, and every integration. The findings clearly influence architecture, staffing, timeline, testing, and contingency. | Discovery stays at the surface—for example, asking only whether you hold inventory or manufacture products. Answers don’t change the estimate, project plan, integration design, or testing effort. |
| Who owns data migration, and how much history are we moving? | Named owners for extraction, cleanup, mapping, validation, reconciliation, and approval. The partner recommends a history range based on what users must search, report on, audit, or compare after go-live. | The default recommendation is to move everything, without discussing data quality, reporting needs, retention rules, reconciliation, or the added effort. Ownership remains ambiguous until migration begins. |
| Who will actually be on my delivery team? | Named consultants with defined roles, availability, relevant Business Central credentials, and experience with similar work. The people introduced are expected to participate in discovery, configuration, migration, testing, training, and launch. | Senior specialists lead the sales process, but the delivery team is unnamed, unavailable for interviews, or assigned later. Roles, capacity, credentials, and use of subcontractors remain unclear. |
| What is your change-order process? | A written process that documents the requested change, business reason, options, cost and schedule impact, approval threshold, decision owner, and updated plan before work begins. | Changes are handled through meetings, email, or informal approval with no documented impact analysis. |
| What happens after go-live? | A named support owner, operating hours, response targets by severity, escalation path, included services, and a documented handoff from the project team. The partner explains how urgent issues, user questions, optimization, and work outside the agreement are handled. | Support is described vaguely or treated as a separate decision after go-live. Response targets, escalation, coverage hours, handoff ownership, and included services are absent from the agreement. |
| How do you handle Microsoft’s twice-yearly updates? | A repeatable release-wave process that reviews upcoming changes, tests extensions and integrations in a sandbox, assesses security and critical workflows, communicates risks, and completes remediation before production rollout. | The partner says Microsoft handles updates and cannot describe customer-specific testing. There is no sandbox plan, extension or integration review, risk communication, or named owner for remediation. |
| Can we adopt standard processes, and where do you recommend customizing? | A standard-first recommendation that maps the requirement to native functionality, process change, or a proven Microsoft AppSource app before proposing custom code. Any customization includes a clear business case, maintenance owner, upgrade impact, and expected return. | The partner agrees to every customization request without testing standard functionality or process changes first. Long-term maintenance, upgrade effects, ownership, and measurable value are not discussed. |
| Can I speak to a customer who had a project go wrong? | A candid reference involving a real setback. The partner explains when the issue surfaced, how options and impacts were communicated, who made decisions, how recovery was managed, and what changed in its delivery process afterward. | Every reference is presented as flawless, difficult projects are off-limits, or the partner blames the customer without explaining its own decisions and lessons learned. |
Credentials: What’s Important and What Isn’t
Credentials can help you narrow the partner field, but they don’t validate delivery capability or replace relevant references, transparent scoping, and confidence in the team assigned to your project. Documented experience is especially important for specialized work such as manufacturing, multi-entity deployments, integrations, or legacy migrations.
Start with Microsoft’s Solutions Partner designation for Business Applications and Business Central specialization. These credentials show organizational investment in Microsoft skills and customer success.
What to Look for in Ongoing Support
If you expect to rely on your partner after go-live, make support part of the selection process—not an afterthought. Look for a partner with a dedicated Business Central support team, clear response targets, and the technical experience to support your environment, no matter how complex.
Ask who handles the first call, what support is included, when extra work becomes billable, and how urgent or unresolved issues are escalated. Microsoft’s support model commonly routes technical issues through a customer’s designated partner, so choose one you trust to troubleshoot effectively.
Fixed Fee or Time and Materials?
The right model depends on how clearly the work is defined before delivery begins.
A fixed-fee implementation works best when the scope is narrow, standardized, and supported by explicit assumptions and exclusions. It can improve budget predictability, but only for the work included in the agreement. Changes to requirements, integrations, data, or responsibilities can still create additional costs.
The Sherpa Program for Business Central is one example of this model: $23,500 plus licensing for core financials, with a typical six-to-eight-week timeline and a 12-month support plan that includes 20 hours of break/fix support.
Time and materials can be a better fit when the project involves multiple entities, complex integrations, manufacturing requirements, or evolving decisions. It gives the team flexibility to learn and adjust, but you’ll need close visibility into priorities, hours, progress, and forecasted spend.
Either model can fail when scope and governance are weak. Compare the assumptions behind the price, including the change-order process before signing.
Compare Business Central Proposals on Equal Terms
Before you compare prices, make sure you’re comparing the same project. Put the proposals side by side and check the entities, processes, integrations, migration history, training, testing, and support included in each. If one estimate is much lower, ask what is missing, not just what makes it cheaper.
At this stage, you should know what each partner can prove, which questions remain unanswered, and where each proposal shifts risk back to your team. Use that evidence to align internal stakeholders on scope, total cost, delivery approach, and the tradeoffs you are willing to accept.
Turn Evidence Into the Right Partner Decision
The most expensive implementation mistakes are often committed before kickoff, when unclear scope, ownership, or support is accepted in the rush to move forward. Resolve those gaps while you still have leverage to challenge assumptions, compare partners, and walk away.
As you work through partner selection, read JourneyTeam’s ERP Buyer’s Guide and pair it with the questions we outlined here. You’ll have a practical framework to turn unanswered questions into firm selection criteria before you sign.
