When several systems meet an organization's key requirements, it is rarely an additional feature that determines the outcome. In such cases, the partner's people, methodology, industry experience, and ability to execute the change become more important.
The same system can yield entirely different results
Two companies can choose the same platform and still achieve completely different results. In a well-executed project, customizations are kept to a minimum, users adopt new working methods, and the solution remains manageable for future development. In a poorly executed project, data migration is delayed, integrations become more numerous than planned, and special customizations create a growing need for maintenance.
A typical example from real-world projects: two manufacturing companies, roughly similar in size, choose the same platform at approximately the same time. One goes live within a year with few customizations and can gradually take over more of the maintenance themselves. The other experiences delays, builds many custom solutions, and ends up with an integration map that becomes difficult to manage internally. Same licenses. Same product. Different partners, different decisions.
The difference often lies in the decisions made along the way: which requirements are challenged, which customizations are stopped, how data is prepared, and how the business is involved. The customer owns the decisions, but the partner's experience influences the quality of the basis for those decisions and which alternatives become visible.
After nearly 40 years in this industry, almost 30 of which have been with what we now call Dynamics 365, this is the pattern I see most clearly. I have very rarely seen a project fail because the platform was incapable. I have, however, far more often seen projects go wrong because no one dared to say no at the right time.
When system choice weighs heaviest
The system choice is still crucial for organizations with advanced production, specialized industry processes, extensive regulatory requirements, large transaction volumes, or complex international structures. In such cases, an incorrect platform choice can create limitations that cannot be resolved solely through better implementation.
For many medium-sized and larger companies, however, several established platforms can meet the basic needs. A common mistake then is to let a single feature in a demonstration weigh more heavily than how the solution will be designed, implemented, and maintained.
The Dynamics 365 platform is the same, but the solution is not
Microsoft owns and develops Dynamics 365. The underlying platform is the same regardless of the partner, but the final solution can differ significantly depending on the partner's design choices, methodology, industry solutions, and add-on products.
Therefore, ask early on what ISV solutions and proprietary add-ons the partner typically uses, who owns them, and what happens if you later wish to change partners.
You are purchasing an implementation, not just a system
In practice, the organization is purchasing a consulting team, a project methodology, and competencies in processes, solution architecture, data, integrations, training, and change management. Additionally, support and ongoing development for many years after go-live are included.
Therefore, the system and partner should be evaluated in parallel. If the partner selection comes last, the organization has already committed to conditions that the chosen partner must work within.
Five areas where the partner affects the outcome
It is in these five areas that the difference between two partners becomes measurable. None of them are visible in a demonstration.
1. Requirements, processes, and customizations
A good partner does not simply implement current working methods as they are. They distinguish between actual business requirements, historical habits, and wishes that can be resolved with standard functionality. Sometimes, the most valuable advice in the entire project is: you shouldn't build that.
2. Project governance and commercial model
The partner's way of planning, prioritizing, and escalating affects the timeline and budget. Also, examine how estimates are produced, how changes are handled, and what responsibilities are included in the price.
3. Data, integrations, and architecture
Many problems perceived as system problems are actually data or integration problems. The solution needs to be documented, understandable, and manageable without becoming dependent on a single consultant.
4. Change and adoption
Training before go-live is not enough. The partner needs to contribute to business anchoring, process ownership, and a plan for how the new working methods will actually be adopted.
5. The period after go-live
The maintenance relationship often lasts longer than the implementation. Therefore, assess support, ongoing development, documentation, and how easy it would be to switch maintenance partners.
Meet the team, not just the salesperson
Meet the project manager, solution architect, and the consultants proposed for data, integrations, and business processes. Assess their experience in similar projects and ensure they will indeed be available when the project starts.
If certain individuals are important for your choice, their roles, availability, and the terms for any replacement should be stated in the contract.
Industry knowledge and the right size matter
Product knowledge is a prerequisite. Industry knowledge allows the partner to more quickly understand processes, identify risks, and distinguish actual needs from old working methods.
The size match is also important. A larger partner offers breadth and endurance, while a smaller partner can provide greater attention and proximity. Assess capacity, continuity, finances, and reliance on individual key personnel based on your specific project.
AI broadens partner requirements
As Copilot, AI agents, and automated flows become part of the ERP and CRM environment, partners also need to be able to manage data quality, permissions, security, and control over automated actions.
Therefore, it is not enough to know who can configure the business system. You need to understand where the partner's expertise in Power Platform, data, integrations, and AI ends, and how other specialist competencies are secured.
This is also where the difference between partners grows rapidly. Ask who sets the authorization model when an agent acts in the system, how you ensure data quality and traceability, what happens when an automated action goes wrong, and who owns the agents and flows being built.
AI makes poor data quality more expensive, not less visible. A partner who cannot describe their governance model for agents, data ownership, and automated flows is not ready to build them for you.
How to test the partner in practice
Ask five questions. Listen as much to how the answer is given as to what is said.
- “Which three reference customers are most similar to us in industry, size, and complexity – and can we speak with them without your presence?” Good answer: names immediately. Weak answer: references in other industries, or always with the salesperson present.
- “Describe a project that went wrong. What did you do about it?” Good answer: a concrete mistake and a concrete action. Weak answer: “the customer wasn't ready.”
- “Which people will we get, how much of their time, and is it in the contract?” Good answer: names, percentages, and willingness to put it in writing. Weak answer: “we will assign the right expertise.”
- “Give examples of requirements you have advised a customer not to build.” Good answer: several examples, with justification. Weak answer: the partner builds everything the customer asks for.
- “What does maintenance look like in year three, and what is required for us to be able to change partners?” Good answer: documentation, ownership, and a clear exit path. Weak answer: evasiveness, or dependence on a single consultant.
Conclusion: when systems are equivalent, the partner becomes the real choice
A well-chosen system is a prerequisite, but the platform does not create business value on its own. The result is shaped by the people who challenge requirements, make design decisions together with the business, implement the change, and develop the solution after go-live.
When several systems meet your most important requirements, you should therefore give at least equal weight to the partner's team, experience, methodology, commitment, and ability to say no to unnecessary complexity.
Compare partners and build a shortlist