How to choose the right partner for Dynamics 365 Business Central?

Short answer: the partner field is the broadest here among all Dynamics areas, which makes size matching the most important filtering. You should be a customer that is visible to the provider, not the smallest with a large one or the largest with a small one. Then, start by considering which system you are leaving, find out which apps are included and who owns them, and check how the partner handles Business Central's two major update cycles per year and the minor ongoing updates.

This guide is written by d365 Guide. We do not implement Dynamics 365, and we do not sell licenses. We exist to enable buyers to compare partners on the same grounds.

It specifically applies to Business Central. For the general selection process, regardless of the application, see our guide on how to find the right partner for Dynamics 365 in the Nordics.

What distinguishes this procurement

Business Central is Microsoft's ERP system for small and medium-sized companies, with roots in Navision. d365 Guide estimates that approximately five hundred new deals are added per year in the Nordics and that projects often start around EUR 27,000. This makes it the most common Dynamics implementation in the region. These figures are d365 Guide's market assessment, updated in September 2026, not official Microsoft statistics.

At the same time, the partner field is the broadest. There are dozens of Nordic partners, from companies with a few consultants to Nordic groups with hundreds. This is good news for your negotiation position and bad news for the selection, as the difference between candidates is rarely visible in the quote.

The low initial cost is the biggest pitfall of the procurement. A Business Central implementation can often be started relatively quickly, and precisely for this reason, the partner is sometimes scrutinized too lightly. The cost of a poor choice is not always visible in the project budget. It appears later in management fees, add-ons, and customizations that need to be maintained over time.

Step 1: Start with what you are replacing

The list of requirements will be roughly the same regardless of the starting point, but the work to be done differs, and thus which partner is suitable.

The starting point also affects how you should interpret an estimate. A switch from NAV might look cheap because much is familiar, but the old solution's customizations are often what takes time. A switch from a small accounting system looks expensive, but much of the cost is the company's own work on processes that did not exist before.

Step 2: Match the size

This is the single most important filtering in the Business Central segment, and the easiest one to get wrong.

If you choose a significantly larger partner than you are, you risk becoming a small customer: junior consultants, low priority in management, and a changing account manager. If you choose a very small partner, you often get senior staff and high engagement, but vulnerability if a key person leaves, and limited resilience if you grow or expand to more countries.

Ask two questions that provide quick answers:

• Where in your customer base would we fall in terms of size? A partner who answers honestly also indicates how much attention you will receive.
• How many customers does the consultant who will be assigned to us have in their management portfolio? In this segment, a consultant often handles many customers simultaneously, and that determines response times in practice.

Geography matters less than it used to, but not zero. During design and deployment, being able to meet in person is valuable.

Step 3: Standard, apps, and customizations

Business Central is extended with add-ons, not by changes to the system's core. This sounds like a technical detail but governs both cost and agility.

Three different things are usually mixed up in a quote, and they have completely different consequences:

• Configuration in standard. Normally follows through Microsoft's updates and can usually be managed by another qualified Business Central partner. This should be the main part of the solution.
• Ready-made apps from Microsoft's commercial marketplace or from an ISV. The license model can be per user, per tenant, or based on other metrics. A general ISV app can normally be used even if you switch implementation partners, but check the license agreement, support responsibility, and whether the app or agreement is tied to the current partner.
• Customizations built solely for you. Can be perfectly right, but they need to be maintained by someone with each update, and that someone is usually the one who built them.

Ask for a written breakdown of what is what, per functional area. Many partners have their own industry-specific apps, and that is often what they actually sell. This does not have to be a problem: a well-developed industry app can save a lot. But you should know that it is there, what it costs ongoingly, and what happens to it if the collaboration ends.

Step 4: Updates twice a year

Microsoft has two major update cycles for Business Central per year, with larger versions in April and October. In addition, minor updates are released continuously, usually monthly. In the cloud version, you can schedule a major update within the available update window, but you cannot opt out of the service being kept updated. This is a clear difference from older ERP systems and an area where the difference between partners becomes apparent soon after deployment.

Ask each candidate how they work with this: if they have a test environment where your solution is checked before the update takes effect, which flows are tested, whether it is included in the management agreement or billed separately, and how they inform you about new functionality that you might actually benefit from.

A partner who does not have a routine here will treat each update as an incident, and you will pay for it.

Step 5: Questions to ask, and how to interpret the answers

The following questions are formulated not to have an obvious good answer. The evaluation of the answer is at least as important as the question.

1. How many Business Central customers have you deployed in the last two years, and how many resemble us?

The second part of the question is the important one. The total number of customers says little when the field is so broad.

Good answers include:

• A number, with customers in your size class and industry that can be contacted.
• A distinction between new implementations and inherited managed services.

Warning signs:

• The answer shifts to the company's history in Navision.
• All references are significantly larger or smaller than you.

2. Which apps are included, who owns them, and what are their ongoing costs?

This determines both the monthly cost and how locked in you become.

Good answers include:

• A list with the vendor, fee per user per month, and with whom you sign the contract.
• A direct statement about what happens to each app if you change partners.

Warning signs:

• The partner's own apps are presented as part of the solution without a separate price tag.
• The costs only appear in the contract appendices.

3. How much will be configuration and how much will be custom code?

See Step 3. The question determines the cost of maintenance over time.

Good answers include:

• A breakdown by functional area, in writing.
• Suggestions on where you should adapt to the standard instead of the other way around, with justification.

Warning signs:

• Everything you wish for can be built, without objections.
• The amount of custom code is presented solely as a strength.

4. Who will be our consultant, and how many customers does that person have?

In this segment, it's rarely a large team. Often, it's one or two people, and those individuals are, in practice, the entire delivery.

Good answers include:

• Name, experience, and a meeting before signing the contract.
• An honest statement about portfolio size and what happens during holidays and illness.

Warning signs:

• The consultant is assigned after contract signing.
• You have only met a salesperson after several meetings.

5. How do you handle Microsoft's updates?

See Step 4. The answer should include a routine, not a principle.

Good answers include:

• A described test routine with environment and which flows are checked.
• Information on whether it is included in the agreement or billed.

Warning signs:

• Updates are described as something Microsoft takes care of for you.
• The question has not come up with other customers.

6. What does the migration from our current system look like?

Data migration is the most common reason for a deployment delay, even in smaller projects.

Good answers include:

• Information on what is moved and what stays: balances, open items, history, and master data are handled differently.
• Number of test migrations and when the first one occurs.

Warning signs:

• All history is promised without discussion of its cost.
• Data quality is not mentioned as your responsibility at all.

7. What can we do ourselves without calling you?

In a smaller company, the answer to that question is crucial for how the system is perceived in everyday life.

Good answers include:

• A definition of what a super user in your organization can change themselves, and training for it.
• Documentation that you own and can give to someone else.

Warning signs:

• Every report and field change requires an order.
• No internal super user is planned for the project.

Merits that measure something other than you think

• Experience with Navision or NAV is not the same as experience with Business Central in the cloud. The extension model and update pace are different.
• Certifications are tied to individuals, not to companies. The question is whether the certified individuals are the ones who will be assigned to you.
• Microsoft's partner designations have been based on Solutions Partner designations since 2022. The term 'gold competency' no longer exists.
• Awards from Microsoft reflect the partner's relationship with Microsoft. They are not customer satisfaction measurements.
• The number of consultants in the company says nothing about how many are available when your project starts.

What usually goes wrong in the selection itself

• Quotes are compared on price without including apps and ongoing fees, which makes the cheapest quote the most expensive over three years.
• The requirements list describes current workflows in detail, which builds old problems into the new system.
• Maintenance is left out of the procurement and priced when you no longer have a negotiation position.
• No internal super user is appointed, making you dependent on the partner for minor things.
• Size matching is never evaluated, even though it is the factor that differentiates candidates the most.
• The decision is made without anyone who will work in the system daily having tried it.

A note on sources

Most of what is published in English about how to choose a partner for Dynamics 365 is written by partners. The material is often competent, but it is written by a party with an interest in the outcome, and the criteria therefore tend to align with their own profile.

Read several sources, and ask yourself who benefits from those specific criteria being weighed most heavily.

Next steps

Write down which system you are leaving, how many users you have, and what needs to be solved in one year. With these three answers, supplier conversations will be shorter, and the differences between candidates will be apparent earlier.

If your business is moving towards a group structure in several countries, it might be worth understanding the level above at the same time: see the guide on partner selection for Finance & Supply Chain Management. If you also need to review CRM, there are separate guides on Dynamics 365 Sales and Customer Service and Field Service.

On d365 Guide, you can compare Nordic Dynamics 365 partners by application area, industry, and size, and narrow down the field before you start booking meetings.