Switching Dynamics 365 Partners Without Losing Your System

Who owns your Dynamics 365 system when the partner holds the admin accounts?

You do, in almost every case. A Dynamics 365 environment lives in your Microsoft 365 tenant, and the tenant belongs to the organization that holds it, not to whoever was given the administrator password. What can genuinely be stuck on the partner side is narrower than most buyers fear, and it is worth separating the two before anyone panics or negotiates from a weak position.

The exception is a system built in the partner's own tenant or Azure subscription. That is a migration into your tenant rather than a handover, and the export step below becomes urgent rather than routine.

What should you secure before you tell your partner you are leaving?

Access and billing, quietly, and nothing that looks like an exit. A partner that learns of a switch while it holds the only administrator accounts has leverage it did not earn. Adding your own administrators is ordinary hygiene that no reasonable partner will question.

The mechanics of moving tenant administration, Power Platform administration and integration identities are set out step by step in the vendor takeover checklist on our rescue and takeover page, so they are not repeated here. What matters for a planned switch is timing: do the first two boxes of that checklist before notice, and the rest at notice.

• Microsoft Entra admin center, Roles and administrators: list who holds Global Administrator, Privileged Role Administrator and User Administrator, and add your own people.
• Microsoft 365 admin center, Settings, Partner relationships: record which partners hold reseller and delegated admin roles, and which roles those are. Leave them in place until notice.
• Power Platform admin center: record environment owners and admins for every environment, not only production, and confirm your people hold System Administrator in each.
• Microsoft 365 admin center, Billing, Your products: record every subscription, whether it was bought direct or through a partner, its status and its renewal date.
• Your DNS: confirm your organization, not the partner, controls the domain registrar and DNS for every verified domain in the tenant. It is also what proves ownership to Microsoft if access is ever lost.

What is the safe order for switching Dynamics 365 partners?

Nine steps, in this order. The order matters more than the speed: each step removes a way the next one could be blocked. Where a system is working, this can be run calmly alongside business as usual; where it is broken, the first two steps become the emergency version described further down.

• 1. Establish independent Global Administrator access. Before anyone mentions leaving, confirm that at least two people employed by your organization hold Global Administrator in Microsoft Entra ID, and create two cloud only emergency access accounts on your .onmicrosoft.com domain whose credentials are held by you. Note every account the partner holds and which roles it has, but do not remove anything yet.
• 2. Take ownership of Power Platform, Dataverse and billing administration. Give your own people Power Platform Administrator, System Administrator in every environment including sandboxes and developer environments, and a billing administrator role. Make sure billing notifications and renewal notices reach a mailbox you control, so a lapsing subscription cannot happen silently.
• 3. Take a full export while cooperation is still easy. Export every unmanaged solution from the development environment, back up production, export configuration and reference data, every flow outside a solution, plug-in assemblies, PCF and web resource source, and the source repositories and pipelines. Confirm the exports import into a clean sandbox you own.
• 4. Inventory every integration and credential the partner controls. List each integration, the identity it runs as, the app registration and secret or certificate behind it with expiry dates, the connection references your flows use, and any Azure resources, repositories or third party licences that sit in the partner subscription or account rather than yours.
• 5. Read the contract before giving notice. Check the notice period, who owns the custom code, what exit or transition assistance the partner owes and on what terms, the handover deliverables, and whether the licensing agreement has a separate term. Take legal advice on anything that affects ownership.
• 6. Give notice and rotate the credentials. Give notice in writing, ask for the handover deliverables and a short knowledge transfer session, and on the same day reduce the partner accounts and delegated admin roles to what the parallel period needs, rotating any shared secrets the partner has seen.
• 7. Move the CSP or subscription relationship deliberately. Transfer the subscriptions to the new partner or to a direct relationship with Microsoft, timed against renewal dates and term commitments. Only the billing channel changes; the tenant, environments and data stay where they are.
• 8. Run old and new arrangements in parallel through one release cycle. Keep the outgoing partner available for questions while the new team ships one complete release through a pipeline and repositories you own, from development to production, so every gap in the handover is found while someone can still answer it.
• 9. Close the old access. Remove the remaining partner accounts and delegated admin relationships, transfer ownership of any flows, apps and app registrations still tied to partner identities, rotate the last secrets, and record the final state of access in writing.

What do you need to export, and what cannot be exported?

The trap is the managed solution. Production normally runs managed solutions, and a managed solution cannot be exported from the environment it is installed in, let alone turned back into something editable. The editable version lives in the development environment where it was built, or as unpacked source in a repository. If that development environment or repository belongs to the partner, it is the single most important thing to get before notice. Our comparison of Power Platform CLI and manual export and import covers how to unpack a solution into source control you own.

Which integrations and credentials does the partner control?

This is the part that fails weeks after the switch rather than on the day. Every interface authenticates as something, and connections never carry their credentials in an export. Write the inventory as a table with one row per integration and a named owner on your side for each.

• Dataverse application users and the Entra app registrations behind them: owners, client secrets, certificates and expiry dates.
• Connection references and the connections behind them: which account each connection signs in as. A connection created by a partner consultant runs as that consultant.
• Azure resources: Functions, Logic Apps, Service Bus, Key Vault and storage. If they sit in a partner Azure subscription they must be moved or redeployed into a subscription you own.
• Server side synchronization mailboxes, SharePoint and Teams integration settings, and any service accounts used for them.
• Power Pages: custom domain, certificates, identity provider registrations and the site configuration.
• Third party and ISV components: who holds the licence, whether it is tied to the partner, and what happens to it at the end of the contract.
• Anything shared by message or password manager during the project: every secret the partner has seen gets rotated at notice.

What contract clauses should you check before giving notice?

Read the services agreement and the licensing agreement separately; they are often different documents with different terms. We are not lawyers, and anything touching ownership of the custom work deserves legal advice, but these are the clauses that decide how smooth the exit is.

• Termination: the notice period, whether you can terminate for convenience or only for cause, and what counts as notice.
• Intellectual property: whether custom work is assigned to you or only licensed, and which pre-existing partner components or accelerators are excluded from that.
• Exit or transition assistance: whether the partner must support a handover, for how long, and on what commercial basis.
• Handover deliverables: source code, documentation, credentials, the environment list and data return, named explicitly rather than implied.
• Warranty and defects: if the partner broke workflows, document the defects and raise them under the warranty before notice, not after it.
• Licensing term: renewal dates and commitment terms on the subscriptions, which follow Microsoft rules rather than partner policy.
• Outstanding invoices: whether a payment dispute lets the partner suspend services or subscriptions it controls.

How do you move the CSP or subscription relationship without an outage?

Treat it as a billing change, because that is what it is. The tenant, the environments and the data do not move when a CSP relationship moves; only the seller of record changes. In practice the new partner sends a reseller relationship request that your Global Administrator accepts, and the subscriptions are transferred between partners under Microsoft's commerce rules. Alternatively you buy direct from Microsoft and let the partner subscriptions end at their term, reassigning licences as the new ones arrive. Either way, time it against renewal dates so nothing auto renews with the partner you are leaving, and never let a subscription lapse to force the issue.

How partner margins work, what a CSP partner should do for the margin, and the question to ask about subscriptions when you stop working with a partner are covered in our Dynamics 365 licensing and procurement guide. Solzet does not resell licences, so we have no margin in which channel you choose.

What if your Dynamics 365 partner has gone silent and holds the only admin accounts?

Then you run the emergency version: the first two steps above, without the partner, starting today. If anyone in your organization still holds Global Administrator, the rest is within your own control: reset or block the partner accounts, remove their delegated admin roles under Partner relationships, and follow the vendor takeover checklist.

If nobody inside your organization holds Global Administrator, Microsoft can restore administrative access to the organization that owns the tenant. The admin center support route needs an admin, so start from the Microsoft business support phone numbers for your country. Microsoft verifies ownership before it changes anything, typically by asking you to prove control of a domain verified in the tenant, for example by publishing a DNS record it specifies, and to show you are authorized to act for the organization. That is why control of your DNS matters so much.

• Gather before you call: the tenant domain names, company registration details, recent invoices or proof of purchase, and a named authorized contact.
• Do not delete the partner or departed user accounts on day one. Flows, connections and app registrations they own can stop working; reassign ownership first, then block sign in.
• Once access is back, add two emergency access accounts that you hold, and rotate every secret the partner could have seen.
• If the system was built in the partner tenant rather than yours, Microsoft cannot hand it to you; it becomes a legal and migration question, and your own data exports decide what can be rebuilt.

What if nobody can reach the Power Platform admin center and the subscription is lapsing?

Recover an administrator first, as above, then read the facts in your own tenant rather than guessing. Microsoft 365 subscriptions that are not renewed move through expired, disabled and deleted stages, with users and then administrators progressively losing access before data is deleted. The length of each stage depends on the subscription and how it was bought, so read the status and dates shown in your admin center rather than relying on a number from anywhere else, this page included.

• Microsoft 365 admin center, Billing, Your products: the status and end date of each subscription, and whether it was bought through a partner.
• Microsoft 365 admin center, Billing, Billing notifications: point notifications at a mailbox you control, not at the person who left.
• Power Platform admin center: environment state, and the capacity and licensing views that show whether licences and Dataverse capacity still cover the environments.
• If a CSP partner has stopped paying or answering, you can buy the subscriptions you need directly from Microsoft in the Microsoft 365 admin center and assign them before the partner ones lapse; a tenant can hold subscriptions from more than one channel.
• Take a manual environment backup and export the data the business cannot lose while access still exists.
• The departed billing contact: if their account still exists, a Global Administrator can reassign their roles and ownerships. Do not delete it before checking what runs as it.

Should you switch partners, or fix what you have first?

Get the facts before the decision. If the partner broke your workflows, raised rates beyond what you can justify, or you simply no longer trust the answers you get about your own system, an independent Dynamics 365 health check tells you what state the system is actually in, which defects are the partner's to fix under the contract, and what a new partner would inherit. That evidence strengthens the notice if you leave and the conversation if you stay.

A switch is also the moment to ask whether the platform still fits. 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. If per user licensing is the real problem rather than the partner, a custom-built CRM on React, Node.js, PostgreSQL and .NET is the alternative, and it is worth deciding that before you migrate a CSP relationship you might not need.

How does Solzet take over from an outgoing Dynamics 365 partner?

As the incoming partner, we run this sequence with your IT people: the access list, the export and its test import into a sandbox you own, the integration and credential inventory, and the parallel release. Where the system is failing rather than working, the Dynamics 365 rescue and takeover service starts with stabilization instead, and the rescue services guide sets out what you can do with no budget at all.

Solzet covers Dynamics 365 Customer Engagement (Sales, Customer Service, Field Service, Customer Insights) and the Power Platform, with 8+ years of CRM delivery from Yerevan, Armenia. We do not take over Dynamics 365 Finance, Business Central, NAV or Finance and Operations systems, and we will say so on the first call rather than after it.