Choosing a Delivery Partner to Own Your Business-Critical Systems

What does it mean for a partner to own your business systems?

A project partner delivers a scope and leaves. An ownership partner stays accountable for the system after go live: it knows why each design decision was made, it finds out about a failure before your users do, it keeps the platform current as Microsoft ships release waves, and it tells you plainly what is worth building next and what is not. For an organisation without an internal IT function there is nobody else to hold that knowledge, so the choice of partner is effectively the choice of who runs a part of the business.

Ownership does not mean the partner owns the assets. The tenant, the data, the source and the documentation stay yours, and the partner holds delegated rights to operate them. Everything on this checklist follows from that one distinction. If you have already been let down once and are choosing again, read this alongside choosing a Dynamics 365 partner after a failure, which covers the evaluation from the position of a buyer who has been burned.

Which evaluation criteria actually predict the outcome?

Feature demonstrations predict very little, because every competent partner can configure the same platform. What predicts outcome is how a partner behaves before the contract, and what the contract says about ownership, acceptance, support and exit. Score each shortlisted partner against the seven criteria below, in writing, and ask for evidence rather than assurances.

Why should discovery be paid and fixed in scope before any fixed price?

A fixed price given before discovery is a price for the assumptions of the partner, not for your requirements. The gap between the two becomes change requests, and change requests are where trust breaks down. A paid discovery with a fixed scope and a fixed output changes the incentive: the partner is paid to find the difficult parts early rather than to win the deal and discover them later.

The output should be something you can take to any partner: the processes in scope, the data and its sources, the integrations with their owners, the recommended platform with the reasons, a phased plan, the risks, and a costed estimate for the build. If a partner will not discover first, or offers discovery only as an unpaid pre-sales exercise, treat the resulting price as a guess.

Who will actually do the work, and how do you meet them?

Ask to meet the delivery lead and at least one of the engineers before you sign, and ask them technical questions about your situation rather than letting the account manager answer. A partner that owns systems well can tell you who holds context on your estate today, who covers when that person is away, and how knowledge is written down so it does not leave with an individual.

Put the named lead in the contract, with a clause on how a replacement is agreed. Continuity matters more for an ownership engagement than for a project, because the value of the relationship is the context the team accumulates.

What should you own at the end: architecture, source, environments and admin?

Everything that would let another competent partner take over without the current one. On Dynamics 365 and the Power Platform that means the following, all in your own Microsoft tenant and organisation.

• At least two people inside your organisation holding Global Administrator and Power Platform Administrator, and System Administrator in each Dataverse environment, with the partner working on delegated accounts you can revoke.
• Development, test and production environments created in your tenant, with managed solutions deployed to test and production rather than changes made directly in production.
• Solution source, plug-in code, PCF controls and pipelines in a repository in your own Azure DevOps or GitHub organisation.
• Application users and service principals for integrations registered in your Entra ID, with secrets or certificates you can rotate.
• The written architecture, the runbooks and a record of design decisions, delivered as documents you hold.
• For a custom CRM, the source repository, the hosting subscription, the database and its backups, and the deployment scripts, all under your accounts.

How should acceptance criteria be written before build?

Each requirement gets criteria a tester can pass or fail without asking the person who wrote it: the starting data, the action, the expected result, and who is allowed to do it. "Sales managers can see their team pipeline" is not a criterion. "A user with the Sales Manager role sees open opportunities owned by members of their business unit, and cannot see those of another business unit" is.

Agree the criteria before development starts, sign them, and tie payment milestones to them. This protects both sides: the partner knows what done means, and you are never asked to accept a release on the basis of a demonstration. Non-functional criteria belong on the same list, including data migration reconciliation, performance on realistic data volumes, and the documentation that must exist at go live.

What should a documented support model contain?

A support model is a set of written commitments, not a phone number. It should define severity levels in terms of your business, the response expectation for each severity, who raises and who receives an incident, how failures are detected, which engineers hold context on your estate, and a regular review where you check that incidents are going down rather than just being closed.

Response targets are a commercial term and should be agreed in the contract against your own severity definitions, so be wary of any partner who quotes a headline number before understanding your estate. Our managed Power Platform support page sets out how Solzet structures support tiers, monitoring inside your tenant, runbooks and moving an existing estate into support, and the same model applies outside the Netherlands.

What does a defined exit look like?

An exit clause is written while the relationship is good, because that is the only time both sides will agree to it. It should state the notice period, the handover artefacts, the period of handover assistance, and that access is returned and revoked in an orderly way.

• Current architecture document, data model and security model.
• Solution source and pipelines, already in your repository, with a note of anything not yet committed.
• An inventory of integrations, their identities, their schedules and their failure handling.
• Runbooks for every supported process and an open incident and backlog list.
• A register of licences, connectors and environment settings the system depends on.
• A handover session between the outgoing and incoming engineers.

Which reference questions surface real problems?

References are chosen by the partner, so "were you happy?" tells you nothing. Ask questions that can only be answered with a specific story.

• What went wrong on the project, and what did the partner do in the first week after it went wrong?
• Were the people who built the system the people who supported it a year later?
• Did the final cost differ from the price after discovery, and how were the differences agreed?
• If you changed partner tomorrow, could you do it with what you hold today?
• How did you find out about the last production failure, from the partner or from a user?
• Has the partner ever advised you not to build something?

What are the warning signs that a partner will not really own the system?

Most of these are visible before signature, which is why they are worth listing out. One on its own can have an explanation; two or three together usually describe the next project.

• Refusal to discover first, or a fixed price for the whole programme after a single meeting.
• No named engineers, or a team that changes between the proposal and the kick-off.
• Ownership left vague: environments, source or integration identities that would sit in the partner organisation.
• Acceptance defined only as a final round of user testing.
• Support described without severity definitions or written response expectations.
• No exit clause, or reluctance to discuss one.
• A claim to cover every system you run with equal depth.
• If you already have a partner and some of these apply, an independent Dynamics 365 health check gives you evidence before you renew. If the relationship has already failed, our rescue and takeover service covers inheriting the estate.

Can one firm own Microsoft 365, Dynamics 365, ERP, ecommerce and logistics together?

Some firms offer to, and a single logo on every contract can feel like the end of finger pointing. In practice finger pointing stops when every system has a named owner and every interface has a written contract, not when one supplier signs for everything. Depth matters more than breadth for a system the business cannot run without.

Solzet is clear about its own boundary. We own Dynamics 365 Customer Engagement (Sales, Customer Service, Field Service, Customer Insights), the Power Platform (Power Apps, Power Pages, Power Automate, Copilot Studio, Dataverse) and custom CRM built on React, Node.js, PostgreSQL and .NET. We do not provide general Microsoft 365 administration such as mail, devices and end user support, we do not implement or support Dynamics 365 Finance, Supply Chain Management, Business Central, Dynamics NAV or any other ERP, and we do not run ecommerce or logistics platforms. 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.

For the systems outside any one partner boundary, set up ownership like this.

• One named owner per system, internal or external, recorded in a simple register with a contact and an escalation route.
• One integration owner accountable for every interface end to end, so a failed sync has a single first responder. Where Dynamics 365 or Dataverse is one end, Solzet builds and supports the integration from the Power Platform side and works with whoever owns the other system.
• A written interface contract per integration: the data and fields, the direction, the frequency, the system of record for each field, the error handling, and who is alerted when it fails.
• Tenant administration held by your organisation, so no supplier controls access to the work of another supplier.
• A shared incident process in which the integration owner triages first and hands over with evidence, rather than each supplier checking only its own side.
• A regular joint review of the interface register, attended by every system owner.

How does Solzet measure up against this checklist?

We publish these criteria because we are willing to be held to them. Engagements start with a conversation with the senior consultants and full-stack developers who would do the work, not a sales layer, and the same people stay with the system after go live. We would rather scope a discovery than guess a fixed price, we build in your tenant and repositories under your administrators, response expectations are agreed in writing in the contract rather than advertised as a headline, and we write documentation so another partner could take over. Our company profile sets out who we are, where we work from and what we deliver, with 8+ years of CRM experience.

If the right answer for your CRM is not Microsoft at all, because licensing does not fit, we say so and build a custom CRM you own outright instead.