// article
Choosing a Microsoft Dynamics 365 Business Central implementation partner is not mainly about comparing software demos. Business Central is the same product regardless of who implements it. The difference is how the partner discovers your processes, controls scope, migrates data, designs extensions and integrations, prepares users, manages cutover, and supports the system after go-live.
Microsoft's Dynamics 365 implementation guidance begins with business value and extends through solution architecture, data, testing, training, change management, and the transition to support. That is a useful way to evaluate a partner: ask how their delivery method handles the full lifecycle, not just configuration and licensing.
This guide gives you 12 questions to ask before signing a statement of work, plus a simple scorecard you can use to compare finalists.
A good selection process starts with your business, not a list of product features. Write down the three to five outcomes that justify the project. Examples include closing the month faster, replacing manual inventory reconciliation, supporting multiple entities, reducing order-entry rework, or retiring an unsupported legacy ERP.
Also document the boundaries that could change the project:
You do not need a finished requirements document. You need enough clarity to see whether each partner asks informed questions or simply agrees with everything.
Ask for the names and roles of the people expected to run discovery, configure Business Central, build AL extensions, migrate data, manage the plan, and support go-live. Then ask which of those people will still be present after the sale.
The strongest answer identifies a delivery lead, functional ownership, technical ownership, and project management. A weak answer describes a large company but cannot tell you who will attend your working sessions. Company size is not the same as team continuity.
“We implement ERP” is too broad. Ask about projects with similar operational complexity: multi-company finance, distribution, manufacturing, EDI, e-commerce, project accounting, a Dynamics NAV upgrade, or a QuickBooks migration.
Request a reference you are allowed to contact when the project reaches a serious buying stage. If confidentiality prevents a named case study, the partner should still be able to explain an anonymized problem, the scope, the risks, and what changed after go-live without inventing a result.
A partner should explain how it maps current processes, identifies controls, separates true requirements from preferences, and decides what should remain standard. Ask what deliverable you receive from discovery. Useful outputs include a process map, fit-gap register, integration inventory, data-migration plan, risk log, and a written scope.
Be cautious when a partner offers a fixed implementation price after one short sales call. A price can be fixed only when the assumptions and boundaries are clear enough to price.
The proposal should name deliverables, milestones, responsibilities, assumptions, exclusions, acceptance criteria, and the change-control process. It should also say who owns data cleansing, user acceptance testing, training attendance, and sign-off.
Ask the partner to show you a redacted example of a statement of work. You are looking for specificity, not a particular template. “Configure finance” is vague. A list of the companies, posting groups, dimensions, approval flows, reports, migration objects, and test responsibilities is much more useful.
Business Central can be extended with configuration, workflows, Microsoft or third-party apps, and custom AL extensions. A good partner should be able to explain the trade-offs.
Ask how custom code is tested, versioned, documented, deployed, and kept safe through Business Central updates. “We can customize anything” is not a strategy.
Ask for a table-level migration plan: master records, open transactions, opening balances, dimensions, inventory quantities and costs, attachments, and historical transactions. The plan should identify the source, transformation rules, owner, rehearsal count, validation method, and reconciliation sign-off for each object.
Do not assume every year of transaction history belongs in the new ERP. Sometimes a validated opening position plus a secure read-only archive is safer and less expensive. The partner should help you make that decision explicitly.
An integration is not complete when one test order reaches Business Central. Ask about authentication, retry behavior, duplicate prevention, error queues, monitoring, alert ownership, reconciliation, and support escalation.
For each API, EDI flow, bank connection, e-commerce platform, or warehouse system, someone must know how to detect a failure and recover without corrupting data. If the proposal names only endpoints and field mappings, the operational design is incomplete.
Ask which test cycles are included and who owns each one. A credible plan normally covers configuration testing, extension and integration testing, migrated-data validation, end-to-end scenarios, permissions, user acceptance testing, and a cutover rehearsal.
The cutover plan should include tasks, owners, timing, go/no-go criteria, reconciliation, rollback decisions, and the first days of support. “We will migrate over the weekend” is not enough.
Generic product training rarely prepares people for the processes your project configured. Ask whether training is role-based and built around your data, approvals, exceptions, and month-end procedures. Confirm whether recordings, job aids, and administrator handoff are included.
Also ask how late process changes are handled. Training often exposes missing decisions. The partner should have a way to triage them without destabilizing go-live.
Every ERP project discovers something new. The question is whether changes are visible and controlled. Ask what triggers a change request, who estimates it, what information you receive, and who can approve it.
A useful change order explains the reason, deliverable, price, schedule impact, and what happens if you decline. Avoid arrangements where the first sign of scope growth is a larger invoice.
Ask what hypercare includes, how long it lasts, where users submit issues, what response targets apply, and who owns unresolved problems. Confirm how work moves from implementation into ongoing support and how larger improvements are separated from break/fix work.
If the implementation team disappears at go-live, the support team needs a formal handoff with architecture, configuration, extension, integration, and known-issue documentation.
Microsoft partner credentials can be useful signals, but ask precisely what a company holds. Microsoft's Solutions Partner for Business Applications designation evaluates an organization across performance, skilling, and customer success. Microsoft certifications validate knowledge for particular individuals. A Cloud Solution Provider relationship concerns licensing and the support relationship.
These signals answer different questions. None replaces checking the actual delivery team, project method, references, scope discipline, and support model. Ask the partner to distinguish membership, CSP status, individual certifications, organizational designations, and specializations rather than presenting them as interchangeable badges.
Score every finalist against the same evidence:
Require written evidence for high scores. A polished demo should not outweigh a vague statement of work.
Most Business Central discovery, configuration, development, testing, and support can be delivered remotely. Onsite time is most valuable when a physical process must be observed, a cross-functional workshop needs faster decisions, a cutover has operational complexity, or hands-on training materially improves adoption.
If you are comparing Business Central partners in Southern California, proximity can make those sessions easier, but it should not replace delivery quality. Ask each partner to explain what it would do onsite, what it would do remotely, and why.
Bitta Apps is a Corona-based, remote-first Microsoft Dynamics 365 Business Central partner serving North American organizations. Our work covers implementation, AL development, integrations, Microsoft CSP licensing, and ongoing support. Onsite discovery, workshops, cutover support, and training are available by arrangement when being in the room improves the outcome.
We put the delivery team into discovery, define the scope and assumptions in writing, and provide a fixed-price proposal within five business days after discovery when the work is defined well enough to price. Our pricing guide explains the structure before you request a proposal.
If you are comparing partners now, use the 12 questions above with every finalist. Then send us your requirements. A senior team member will reply within one business day.