How to choose the right partner for Dynamics 365 Finance & Supply Chain Management

Short answer: don't start with the partner's track record, but with what you are replacing. A group changing from AX 2012 places completely different demands on the vendor than one leaving SAP or consolidating five different systems. The field of partners with real capacity is small, so the emphasis in the evaluation is on the people in the team, how the delivery is organised across countries, and who will manage the solution once the project is finished.

This guide is written by d365 Guide. We do not implement Dynamics 365, and we do not sell licenses. We exist to help buyers compare partners on a level playing field.

This guide specifically concerns Finance & Supply Chain Management. For the selection process in general, regardless of the application, please see our guide on how to find the right Dynamics 365 partner in the Nordics.

What distinguishes this procurement

Finance & Supply Chain Management is Microsoft's enterprise branch, with roots in Axapta and later AX. The system is built for groups with multiple legal entities, complex supply chains, and operations in several countries. This is evident in everything: project size, time consumption, number of people involved, and how few vendors can actually deliver.

A couple of order-of-magnitude estimates, based on d365 Guide's assessment of the Nordic market: Projects typically start at around EUR 450,000 and run for several years, from feasibility study to stable operation. We estimate that there are around one hundred customer groups in the Nordics running the system or its predecessors, and that approximately fifty new deals are added each year. d365 Guide has identified more actors with F&SCM competence, but for larger Nordic multi-company or international end-to-end programs, we estimate that the group with sufficient capacity is about ten. These figures are our market assessment, updated in September 2026, not official Microsoft statistics.

This has a rarely stated consequence: pure new sales deals are uncommon. Many partners instead seek to enter existing customers through consultant secondment, by offering a better support agreement, or by taking over further development, and then expand the engagement country by country.

For you as a buyer, this means two things. Competition for your project is less than you think, which weakens your negotiating position. And the partner you choose will likely remain with you for many years, as changing vendors in the midst of an installation of this size is costly and risky. The evaluation therefore needs to be sharper, not milder, than for a smaller procurement.

A terminological point that affects scope

Finance and Supply Chain Management are two separate applications licensed individually, even though the market and most partners refer to them as one system. Clarify early on which modules you actually need, as this affects both licensing costs and the required team expertise. The same applies to adjacent applications such as Project Operations and Human Resources, which often creep into the scope during the feasibility study.

Step 1: Start with what you are replacing

This is the most important distinction, and the one most often overlooked. The requirements list will be roughly the same regardless of the starting point, but the work to be done differs fundamentally, and thus also which partner is suitable.

If you are leaving AX 2012 or AX 2009

This is the most common starting point in the Nordics. AX 2012 has been outside Microsoft's mainstream support for several years, and most who are still running it have postponed the decision for good reason: the system works, it is heavily customised, and it is deeply integrated into the business.

For AX 2012 R2 and R3, there is a Microsoft-supported upgrade path to Finance and Operations that can carry over both data and code. However, this does not mean that everything should be moved unchanged. A central part of the feasibility study is to determine what should be upgraded, what should be rebuilt, and which old customisations and processes should be left behind. AX 2009 does not follow the same supported upgrade path and should therefore be assessed as a migration scenario with different prerequisites.

What you should look for is a partner who has made exactly this journey multiple times, and who can demonstrate how they go about determining which old customisations should be included. A common and costly mistake is to rebuild everything that existed, for fear that someone will miss something.

Also note that long experience with AX is not automatically the same as deep experience with today's Finance and Supply Chain Management. The platform, extension model, operation, and update model have changed. Therefore, evaluate how many modern implementations, upgrades, and go-lives the person has actually performed, not just the number of years in AX.

If you are leaving SAP, IFS, or another major ERP

Here there is no legacy code to contend with, which sounds simpler than it is. The work instead shifts to process design and translating the business's concepts into a new structure. Chart of accounts, product data, customer structure, and inventory logic rarely look as you are used to, and the organisation will experience this.

The partner here needs to have experience in leading this type of translation, not just in configuring the system. Specifically, ask how they work with the business's key users during the design phase, and how much of that time will be spent by your team.

If you are consolidating multiple systems in a group

Then it's not a project, it's a program. The question becomes what should be the common core template and what each company can decide for itself, and that is a governance issue as much as a technical one.

A partner who is to deliver this needs to be able to describe their template and rollout model concretely: how the template is managed, how deviations are handled, how local requirements in different countries are incorporated, and what a second and third country actually costs compared to the first. Ask for figures from a previous customer, not a principal description.

If you think Business Central has become too small

This is the starting point where we most often see the wrong conclusion. The shortcomings are often in a few processes, in integrations that were never completed, or in the system being configured for a business you later outgrew.

An upgrade solves this, but at a completely different cost and complexity than addressing what is actually causing the problem. The partner you ask usually has an interest in the answer. Therefore, ensure the analysis is done by someone who benefits equally from both outcomes, or do it internally.

If the conclusion is that you stay, then the partner choice at that level should be reviewed. We cover this in the guide on how to find the right Dynamics 365 partner in the Nordics.

Step 2: Decide if it is a project or a program

An F&SCM implementation in one company and a rollout across eight companies in five countries are not the same thing. Yet, they are often procured in the same way, and deviations only become apparent when the second country is about to go live.

Clarify before you go out to tender:

• How many legal entities and countries are covered, and in what order?
• What should be common and what can differ between companies?
• Who at your organisation owns the template after the first go-live?
• Should the partner deliver for all countries, or can you use local resources in some?

The answers determine what type of vendor is reasonable. A partner without its own presence outside the Nordics can still deliver a rollout, but it must be clear how, and with whom they collaborate.

Step 3: Build a longlist without unnecessarily narrowing the field

It is often said that F&SCM requires one of the global system integrators. This is not true for Nordic conditions. The largest players have deep resources and global reach, but there are also mid-sized Nordic partners with a long F&SCM history and a significantly higher proportion of senior consultants in their teams.

What really filters is not the company's size but three things:

• The number of go-lives on Finance and Operations in the last twenty-four months. Not the total number of customers, and not the AX history.
• Whether they have delivered something similar to your starting point, i.e., the same type of change from the same type of system.
• Whether they can staff you with senior people without depleting another ongoing project.

Four to six candidates is a reasonable starting point. More will be difficult to evaluate with the required depth, and fewer will give you no comparison at all.

Step 4: Evaluate the team, not the company

In a project of this size, you are not buying the vendor; you are buying an architect team. The difference between two partners in the same price range almost always lies in the people.

The Solution Architect

The project's most important role. The architect connects the group's financial structure – i.e., group accounting, intercompany pricing, and shared functions – with the operational flows. Request CVs, ask which of the person's recent projects went into production, and speak with the architect themselves before signing an agreement.

The division of finance and supply chain

It is unusual for the same consultant to be strong in both advanced financial modelling and heavy logistics or production. Therefore, evaluate the team as a whole, and request CVs for those who will set up the modules you actually depend on. If you have advanced warehouse management, production, or global purchasing logistics, there should be names associated with each such area.

Project Manager and Change Manager

The Project Manager should have driven at least one implementation of comparable size all the way to stable operation, not just to go-live. Change management is not a soft issue in this system: F&SCM is perceived as complex by those who will work in it daily, and adoption determines whether the investment yields results.

Step 5: Review the delivery model

Almost all larger partners combine consultants in the Nordics with resources in other countries. This is not a problem in itself, and a delivery fully staffed with Nordic senior consultants will be very expensive without necessarily being better.

What matters is where the line is drawn in the project. Analysis, design, and the decisions that shape the solution should be close to the business and in a language where nuances are not lost. Configuration, development, data cleansing, and testing work well when placed with an established centre in another country.

Ask directly how the team is composed, in which time zones it operates, and who writes the specifications that developers then build from. It is in that handover that expensive misunderstandings arise.

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

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

1. How many go-lives have you had on Finance and Operations in the last two years?

This is the single most informative question in the entire evaluation, and the one most often answered vaguely.

Good answers contain:

• A number, with customers that can be named and preferably contacted.
• A distinction between new implementations, rollouts to additional countries, and inherited support engagements.

Warning signs:

• The answer shifts to the total number of customers or the company's AX history.
• References are several years old.

2. Who will be our solution architect, and can we meet them now?

The architect is the person whose decisions you will live with for ten years. Meeting them only at startup is too late.

Good answers contain:

• A name, a CV, and a meeting without a salesperson in the room.
• Information on how much of their time will be dedicated to you, and what else they are doing.

Warning signs:

• The architect is appointed after contract signing.
• The person is presented as an architect but has primarily worked in AX.

3. How do you plan data migration, and who owns it?

Data migration is a separate project within the project, and the most common reason for go-lives being postponed.

Good answers contain:

• A description of how many test migrations are planned and when the first one will occur.
• A clear division of responsibility for data quality, where a large part reasonably lies with you.

Warning signs:

• Migration is described as a technical activity late in the project.
• No distinction is made between balances, history, and master data.

4. What will be the core template and what will be local?

This question applies to all groups, even those starting in one country, because the template is set during the first implementation whether you call it that or not.

Good answers contain:

• A concrete model for what is centrally controlled and what is allowed to deviate.
• Experience figures on what a second country has cost compared to the first with a previous customer.

Warning signs:

• The question is answered in principle without examples.
• Everything must be common, without discussion about what happens when a company cannot follow the template.

5. How is the team composition across countries?

See the section on the delivery model above. The question should be asked directly and answered with figures.

Good answers contain:

• A breakdown by role and phase, not just a total percentage.
• Information on who writes the requirements that developers build from.

Warning signs:

• The proportion of local consultants is presented as high in the sales phase and decreases in the quote.
• The analysis phase is staffed predominantly with resources who do not meet the business.

6. Which add-on applications do you suggest, and who owns the relationship?

Most F&SCM solutions include third-party apps for, for example, warehouse management, EDI, tax reporting, or document management.

Good answers contain:

• A list of who the vendor is, what it costs on an ongoing basis, and with whom you have a contract.
• A discussion of what happens to the app if you change implementation partners.

Warning signs:

• The partner's own apps are presented without pricing information.
• Dependencies only become clear in contract appendices.

7. What does support look like, and who does further development?

The system is continuously updated by Microsoft, and your solution needs to keep up. Support is the phase you live in the longest, and where the total cost is determined.

Good answers contain:

• A written support model with a named account manager, response times, and pricing model.
• A plan for how regression testing is handled during Microsoft updates.
• Information on whether the support team is the same people as the project team, and how the handover is done.

Warning signs:

• The support agreement is only discussed after the project agreement is signed.
• Further development is priced only on an ongoing basis, without any form of prioritisation process.

Merits and concepts that measure something other than you think

• FastTrack for Dynamics 365 is Microsoft's customer success and advisory program for qualified projects, delivered together with the implementation partner and based on Success by Design. It is not a partner certification or partner merit in itself. Experience with FastTrack, the Implementation Portal, and go-live readiness reviews can, however, be relevant when assessing the partner's familiarity with Microsoft's implementation requirements.
• Microsoft's partner designations have been based on Solutions Partner designations since 2022. The concept of gold competency no longer exists and should not appear in current documentation.
• Sure Step has been discontinued. Microsoft's current implementation guidance is structured around Success by Design. A partner who still describes Sure Step as their current methodology says something unintentional about how often their material is reviewed.
• Certifications are tied to individuals, not to companies. The question is whether the certified individuals are the ones who will be assigned to you.
• The number of consultants in the company says nothing about how many of them are available when your project starts.

What usually goes wrong in the selection itself

• The requirements specification is made too detailed too early, which locks the solution into the old world's processes and drives customisations you will then have to maintain.
• The evaluation is weighted towards demo and presentation. All candidates in this segment demonstrate well.
• The support phase is left out of the procurement, even though it constitutes the majority of the total cost over ten years.
• No internal owner is appointed for the template, which means the partner effectively determines how the group should work.
• The timeline is set according to a business date instead of how many test migrations are actually needed.
• The decision group does not agree on why the change is being made, which only becomes apparent during the design phase when priorities clash.

A note on sources

Most of what is published in the Nordics 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.

In this segment, this weighs more heavily than in any other, as the number of vendors is small and each individual procurement is large. Read multiple sources, and ask yourself who benefits from those particular criteria carrying the most weight.

Next steps

Start by writing down three things before contacting any vendor: what you are replacing, which countries and companies are covered and in what order, and what should be resolved in two years. With these three answers in place, vendor conversations will be shorter and significantly more informative.

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

If you are also reviewing the CRM side, there are separate guides on Dynamics 365 Sales and Customer Service and Field Service.