Choosing a Dynamics 365 Partner After One Has Already Failed You

Why did the last partner selection fail to predict delivery?

Most failed Dynamics 365 projects were chosen through a process that measured the wrong things. A polished demo shows what the product can do, not what this team will build. A Microsoft partner designation measures the firm's commercial performance and certifications held somewhere in the company, not the people assigned to you. Reference calls are chosen by the partner. And the pre-sales architect who won the workshop is often not the person who turns up in week three.

A second selection has one advantage over the first: you now know exactly how failure looked in your organisation. Write it down before you speak to anyone. Was it unmanaged changes pushed straight into production, a team that silently rotated, a design nobody challenged, an integration nobody owned, or a contract that made leaving expensive? Each of those failure modes maps to one of the checks below, and the candidates should be tested hardest on the one that hurt you. Our guide to choosing a D365 partner for a mid-market manufacturing project explains in detail why badges and day rates predict so little; this page is the generic checklist for the buyer who has already paid for that lesson.

What is the checklist for choosing a Dynamics 365 partner after a failure?

Seven checks, each one designed so that a weak partner cannot pass it with a presentation. Use the table as the spine of your evaluation and score every shortlisted partner against the same rows.

Why run a paid pilot on your real environment instead of watching a demo?

A demo is rehearsed on a clean tenant with data designed to look good. Your environment is the opposite: layered customisations, half-documented plugins, integrations with real failure modes and data that does not match the documentation. The only way to see how a partner behaves in that reality is to pay them to work in it for a short, bounded period.

Keep the pilot small enough that it cannot become a sunk-cost trap, and real enough that it cannot be faked. Pay for it, so the partner puts senior people on it and so you owe them nothing afterwards. The most useful pilot for a buyer coming out of a failure is often an assessment of the system you already have, because it produces something you keep whichever partner you choose. That is exactly the shape of our Dynamics 365 health check and technical audit: an independent read of the environment with a prioritised remediation roadmap you can hand to anyone.

• Scope: one real backlog item, one broken flow or integration, or a read-only assessment of the current solution. Not a proof of concept of features the product already has.
• Environment: a sandbox copy of production (the Power Platform admin centre can copy an environment) with sensitive data handled under your policies, accessed through guest accounts you create and can revoke.
• Deliverable: code and solutions in your repository, and written findings, not a slide deck held by the partner.
• What you are really watching: the questions they ask in the first days, whether they tell you something unwelcome, how estimates hold against your actual system, and whether the people on the pilot are the people in the proposal.

How do you write named senior consultants into the contract?

If your last project was sold by seniors and delivered by whoever was on the bench, fix it in the contract rather than in the relationship. A named-personnel clause turns "our senior team" into obligations you can enforce.

The broader vetting questions for any Dynamics 365 supplier, such as whether the person on the call is the person who will do the work and what happens to the knowledge when the engagement ends, are set out on our staff augmentation and subcontracting page. Use them in the first call; use the clauses below in the contract.

• A schedule listing the key individuals by name and role, with the share of their time committed to your project.
• Substitution only with your written consent, a replacement of equivalent seniority that you can interview first, and overlap time for the handover paid by the partner rather than by you.
• A right to request removal of an individual from the project for performance reasons.
• Disclosure of any subcontracted delivery before signature. Subcontracting is normal and often good; finding out about it in month four is the warning sign.

What ALM and source-control evidence should a partner show from a live client?

Every partner will describe a good application lifecycle process. Ask to see one that is running. A partner with real ALM can open a current client's pipeline in a screen share, with the client's name redacted, in a few minutes. A partner without it will offer to send a document.

What a sound setup contains, from separate environments to managed solutions and Solution Checker in the pipeline, is described in the ALM section of our manufacturing partner selection guide. Here the point is the evidence, not the theory:

• A repository with unpacked solution source and a commit history showing small, regular, reviewed changes rather than occasional bulk exports.
• Pull requests with review comments from someone other than the author.
• A pipeline run history showing managed solution imports into test and production, including a failed run and how it was fixed.
• Environment variables and connection references used for configuration that changes between environments, instead of hard-coded values.
• An honest answer to "what is still deployed manually on that project, and why?"

Why should a partner put in writing where it disagrees with you?

Many failed implementations were built exactly as specified. The partner accepted every requirement, customised every gap and never said that the requirement itself was the problem. The partner you want next is one that will tell you, in writing, where your plan will cost more than it returns.

Ask each shortlisted partner for a short written architecture opinion on your requirements, and ask explicitly for at least one point of disagreement. Typical good disagreements: a custom table proposed where a standard Dynamics 365 capability already fits, a requirement to migrate years of history nobody will use, an integration designed as real time when a scheduled sync would do, full licences proposed for users who only complete a form, or a rebuild demanded when a remediation would work. A partner who cannot find anything to disagree with has either not read your requirements or has decided that agreement is safer for the sale. Neither is who you want holding your system.

The opinion should be in writing because verbal pushback is easy to give in a sales meeting and easy to forget in delivery. Keep it; compare delivery against it later.

Which questions expose a partner who will not push back?

Ask these in the evaluation, in front of the people who would do the work, and listen for specifics rather than reassurance. A partner used to challenging clients answers them with stories; a partner used to agreeing answers them with policies.

• Tell me about a requirement a client insisted on that you advised against. What happened?
• Which of our requirements would you remove or push to a later phase, and why?
• What in our current environment would you keep, even though our last partner built it?
• When did you last tell a client that Dynamics 365 was the wrong platform for what they wanted?
• If our sponsor asks for a change two weeks before go-live, who on your side says no, and how?
• What would make you walk away from this project?
• What are you not good at, and which parts of our scope would you not want to do?

How would a new partner take over an environment it did not build?

The first weeks of a takeover decide whether you get a second failure or a recovery. Ask each candidate to describe, concretely, what they do before changing anything. A credible answer reads the existing solution first: which solutions are managed and which customisations sit unmanaged in production, the solution layers on the components that matter, plugin and custom workflow registrations, Power Automate flows and who owns their connections, application users and service principals used by integrations, security roles and business units, and the open defects the business actually cares about. It ends with a written findings document and a prioritised plan, and it treats a rebuild as a conclusion that has to be earned by evidence, not as a starting assumption.

Our project rescue and takeover service describes how Solzet runs that first read on a failed Customer Engagement or Power Platform project.

The separate problem, getting off an incumbent partner that still holds the global admin accounts, the subscriptions or the only copy of the source, is a transition plan in its own right. It is set out step by step in our guide to switching Dynamics 365 partners safely, and it should be under way before the new partner starts rather than after.

What exit terms should you agree before the new engagement starts?

If leaving your last partner was hard, it is because exit was never agreed while everyone was still on good terms. Agree it now, with the new partner, before any work starts. The test is simple: could you give notice tomorrow and keep running your system?

• Intellectual property: the solutions, source, pipelines and documentation built for you are yours, with any reusable partner components licensed to you perpetually.
• Location: source lives in a repository in your organisation, pipelines run in your Azure DevOps or GitHub, and environments sit in your tenant.
• Accounts: administrative access is held by named people in your organisation, partner staff use individual accounts you can revoke, and no integration depends on a partner-owned account or credential.
• Documentation: an agreed standard kept current during delivery, not written at the end.
• Notice and handover: a notice period, a defined handover package and a number of paid handover days available to you or to the next partner.
• Commercial relationships: whoever resells your licences or subscriptions, the terms for moving that relationship are written down now.

Should the next partner keep you on Dynamics 365 at all?

After a failure it is worth asking whether the platform was right, not only the partner. Sometimes the answer is a better implementation of Dynamics 365. Sometimes the requirements were really a Power Apps application on Dataverse. And sometimes the business needed full control without per-user Microsoft licensing, in which case a custom-built CRM is the honest recommendation. A partner that only sells one of those options cannot give you that answer neutrally.

We recommend the right solution - whether that's Microsoft Dynamics 365, Power Platform, or a custom-built CRM. Some businesses need the Microsoft ecosystem. Others need full control without licensing. We deliver both.

Be equally clear about scope. Solzet works on Dynamics 365 Customer Engagement (Sales, Customer Service, Field Service, Customer Insights), the Power Platform and custom CRM. We do not implement Dynamics 365 Finance, Supply Chain Management, Business Central or other ERP, and a partner that tells you plainly what it does not do is easier to trust on what it does.

How can you assess Solzet against this checklist?

The same way you would assess anyone else, and we would rather be assessed properly than sold to. Solzet is a scalable senior consultancy in Yerevan, Armenia (GMT+4), with 8+ years of Dynamics 365 and Power Platform delivery, working in English, Armenian and Russian. The first call is with senior consultants who would do the work. A paid health check or a scoped first work package is available as the pilot, delivered into your repository and your tenant. We will give you a written design opinion, including where we disagree with you, and we agree exit terms before we start.

If you are weighing a nearshore team, our buyer's guide to Dynamics 365 and Power Platform experts in Yerevan includes a due-diligence checklist for that decision. Or use the form below to tell us what went wrong last time.