How to Choose the Right D365 Partner for Your Mid-Market Manufacturing Project

The badge on the website tells you almost nothing

Microsoft's Solutions Partner designation for Business Applications is scored largely on the partner's own commercial performance: net new revenue, customer adds, deployment growth, certifications held somewhere in the organization. That tells you how well a firm sells and how many people it employs. It tells you nothing about whether the two consultants assigned to your plant have ever configured a Field Service incident type or debugged a dual-write failure at two in the morning.

That gap is where mid-market manufacturing projects lose money: the evaluation measures the firm, and the delivery is done by three or four people you have not met. The questions below close it, and you can judge the answers without being a Dynamics architect.

Ask who is on the team, by name, before you sign

The pre-sales architect who impressed everyone in the workshop is frequently not the person who shows up in week three. Ask for named CVs of the delivery team, the certifications those individuals hold rather than the ones the company holds, one thing each shipped in the last year, and what proportion of their week is yours.

Size cuts both ways. A 400-hour Customer Engagement project is staffing noise inside a global integrator; at a fifteen-person independent it is a top-three priority. Only one of them answers the phone in week nine.

Make them describe their ALM in detail

This is the single most reliable technical filter, and it takes ten minutes. Ask how a change gets from a developer's machine into your production environment.

A good answer contains most of these: separate dev, test and production environments; work done in an unmanaged solution in dev under one publisher and prefix; solution segmentation, so a two-field change ships two fields rather than the entire Account table; solutions unpacked into source control; a pipeline (Azure DevOps with the Power Platform Build Tools, GitHub Actions, or Power Platform Pipelines) importing as managed into test and production; Solution Checker in that pipeline; and reference data moved with the Configuration Migration tool rather than typed in twice.

If the answer is "we export from dev and import into production", you are being offered unmanaged customizations sitting directly in production. It works for a year. You discover the cost in year two, when a component cannot be updated by any solution and the layer cannot be removed without breaking a live form.

For manufacturing, ask about the Field Service model specifically

Customer Engagement in a manufacturer usually means assets, warranty and technicians, so ask them to sketch that model out loud. What you want to hear: customer assets in a hierarchy, so a sub-assembly sits under a machine which sits under a line; functional locations for site structure; incident types carrying their own service tasks, products, services and estimated duration; agreements that generate preventive maintenance work orders on one schedule and invoice on another; bookable resources with characteristics and territories; requirement groups for a job needing two technicians and a lift.

A partner who reaches for incident types and agreements unprompted has run preventive maintenance at a plant. One who proposes a custom "maintenance request" table with a status field has done sales CRM and is about to rebuild Field Service badly, with none of the scheduling engine attached. That distinction tells you more than any reference call, and it is the pattern behind much of the remediation work in our manufacturing practice.

Offline is the question that separates the two kinds of partner

Technicians work in basement plant rooms and on sites with no coverage, so ask how the mobile app behaves there. The answer should involve Field Service mobile offline profiles: which tables are included, what filters keep the payload small enough to sync on a phone over a weak connection, and what happens when a technician completes nine work orders offline and returns to find a parent record changed. Partners who have only delivered office-based CRM do not know offline profiles exist, and you learn that after go-live, from the technicians.

ERP integration: ask what happens when it fails

Most proposals describe the happy path. The choice is between dual-write, virtual tables and middleware, and each has a distinct failure mode. Dual-write is bidirectional and near real time, which also couples the write paths of two systems: a mapping gap or a required field on one side can block a transaction on the other. Business Central integrates with Dataverse through table couplings and synchronization jobs that quietly accumulate errors. Virtual tables are fine for read-mostly reference data and wrong for anything a plug-in must transact against.

So ask the operational questions instead of the architectural one. Who is alerted when an overnight sync job fails, and through what channel. What is the rollback when the initial load writes forty thousand malformed customer records. How are number series and key mismatches reconciled. A partner with production experience answers these immediately, because they have been woken up by them, and you can see how that layer looks in practice in our field service implementation for a European manufacturer.

Licensing: ask whether they resell

A partner who resells your licences has an incentive that shows up in their design, usually as seats. Test it: tell them two hundred shop-floor operators need to record scrap and downtime reasons on a tablet. If the answer is two hundred Dynamics 365 Customer Engagement licences, the margin is shaping the architecture. Operators capturing scrap need a Power Apps application on Dataverse licensed on that basis, not full CE seats, and the same goes for a warehouse team that only ever completes a form.

Ask each shortlisted partner to model the five-year licence cost of their proposed architecture and say where they make their margin. "On licences" is not disqualifying; not saying is.

Commercial shape and the exit

Fixed price across an undefined scope is either padded heavily or the opening move in a change-order argument. What works for mid-market manufacturing is a paid, fixed-price discovery producing a data model, backlog and estimate you own outright, then iterative delivery against that backlog.

Then ask about the end before you start. Is the solution source in your repository and your tenant. What is in the handover package. Will they train an internal owner, and what does month thirteen cost. A partner unwilling to put source and documentation in your hands is selling a dependency rather than a system.

Four things that should end the conversation

• A demo with no data model behind it, where every question about how records relate is answered with "we can configure that".
• "We will customize it" as the response to every gap. Standard-first is what keeps you upgradeable.
• A proposal with no environment or release strategy at all.
• Subcontracting that only surfaces when you ask directly. Subcontracted delivery is normal and often good; concealing it is the signal.

None of this requires you to evaluate code. It requires asking how work reaches production, how the domain is modelled, and what happens when something breaks at night. If you want an independent read on a shortlist, or on a project already underway, that is what our services are shaped around.