Can You Move Microsoft 365 Away from Your Current Provider?

A business appoints a new IT provider. The owner expects the process to be straightforward: stop paying the old supplier, buy Microsoft 365 from the new one, and carry on using email. The new IT provider then asks questions the business cannot answer.

What is your tenant ID? Who is the Global Administrator? Is the domain federated? Who supplies the licences? Is the tenant dedicated to your organisation? Can the subscriptions be transferred? Is email filtering bundled? Where is DNS hosted? Is Microsoft 365 backed up?

These are not bureaucratic questions. The answers determine which of four materially different exit routes applies — and which sequence of steps will avoid service disruption.

Changing Microsoft 365 provider can mean a simple licensing change, a subscription transfer, an authentication change or a full tenant migration. These are not the same project.

What your Microsoft 365 provider may actually control

A business may believe it owns its Microsoft 365 environment because it pays the invoice, owns the domain, staff use the email addresses and Outlook is installed on its computers. None of these things confirms tenant ownership.

Microsoft 365 can be supplied through Microsoft directly, through a Cloud Solution Provider (CSP), through an IT support company, through a telecoms company, through a domain or hosting provider, or through a bundled business-services package. Each arrangement may give the provider different levels of control.

The four common exit scenarios

Most provider changes fall into one of four categories. Identifying which applies before any work begins determines the plan, the cost and the risk.

Same-tenant change versus tenant migration

Where a business genuinely controls its own tenant, a provider change often does not require migration at all. Existing identities, mailboxes, SharePoint, OneDrive, Teams and security configuration all remain. The work involves licences, authentication, delegated access and security services — significant, but not a full data migration.

Retaining the tenant is normally simpler, but only where the business genuinely controls it and the provider supports the release. Where the provider controls the tenant — or where the domain is attached to a provider-managed or shared environment — a migration may be the only option.

CSP-to-CSP subscription transfers

Where a business purchases Microsoft 365 through a Cloud Solution Provider, it may be possible to transfer eligible subscriptions to a new CSP rather than cancelling and repurchasing. However, Microsoft's current rules require the participation and approval of both the source and target partners.

Not every subscription type is eligible for transfer. New Commerce Experience (NCE) subscriptions in particular have specific restrictions on mid-term transfers. Subscriptions that cannot be transferred must be allowed to expire or be cancelled subject to any applicable cancellation terms, and replacement licences purchased from the new provider. Any existing contractual obligations to the outgoing provider do not disappear simply because a transfer request has been submitted.

A subscription transfer is a commercial and billing change. It does not migrate tenant data, change administrator access, remove federation or alter delegated administration. These must be addressed separately.

Administrator access and tenant ownership

Before any provider exit can proceed safely, the business must confirm that it has independent access to its own tenant — access that does not depend on the outgoing provider remaining cooperative.

Common problems discovered during this audit include: the Global Administrator account belonging to a former employee or previous IT provider; the only administrator account being a delegated account controlled by the outgoing provider; the emergency access account never having been created; and MFA not configured on administrator accounts.

Authentication, passwords and MFA

The impact of a provider change on user sign-in depends entirely on the authentication model in use. A simple licence replacement in a tenant using Microsoft-managed authentication may be completely invisible to users. A defederation — moving from provider-controlled sign-in to Microsoft-managed authentication — affects every user's sign-in method, password state and MFA registration.

In a federated arrangement, user passwords may be held by the provider's identity system rather than by Microsoft. After defederation, users may need to set new passwords and re-register MFA. Security Defaults or Conditional Access policies need to be reviewed and configured. Existing Microsoft Authenticator registrations may or may not remain valid depending on the specifics of the defederation process. Service accounts, application sign-ins and mobile device connections must also be reviewed.

Licences and billing

Licence management during a provider exit requires careful sequencing. The critical principle is that replacement licences must be assigned and confirmed as working before the old licences are removed. Removing licences before assigning replacements strips users of access to Exchange Online, SharePoint, OneDrive, Teams and other services.

Where a subscription transfer is possible, the timing must be coordinated between the source and target providers to avoid a gap. Where subscriptions cannot transfer and must be replaced, the business typically needs to run both sets of licences in parallel for a controlled period, with the old licences removed only after the new ones are confirmed as functioning.

Domain and DNS

Changing Microsoft 365 provider does not automatically require changing the domain registrar or the DNS host. The domain can remain with the same registrar. DNS can remain with the same provider. The domain name itself stays the same. A provider exit is not automatically a domain move.

However, a tenant-to-tenant migration typically requires the domain to be temporarily removed from the existing tenant and added to the new one, because Microsoft does not allow the same custom domain to be attached to two tenants simultaneously. During this period, email delivery using the custom domain is unavailable unless carefully managed. All DNS records — MX, SPF, DKIM, DMARC, Autodiscover, verification records, website records and any records supporting third-party applications or remote access — should be documented before any changes are made.

Email security and backup

Some providers bundle email security services — spam filtering, mail gateways, Proofpoint integration, URL rewriting, attachment scanning, archiving, continuity or DMARC monitoring — alongside the Microsoft 365 licence. These services are not part of the Microsoft subscription and do not transfer automatically. They may disappear when the contract with the outgoing provider is cancelled.

Backup is equally easy to overlook. Microsoft 365 does not include a comprehensive backup by default. Where a third-party backup solution is in use, the backup connectors are typically authenticated through an administrator account. If that account belongs to the outgoing provider, backup access may fail once the delegated relationship is removed. Backup authentication must be reviewed and, where necessary, migrated to a new account before the exit.

Choosing the correct exit route

Provider exit checklist

1. 1Identify the tenant — ID, display name, onmicrosoft.com domain and custom domains
2. 2Verify Global Administrator access independent of the outgoing provider
3. 3Confirm the current provider relationship — CSP, delegated admin, GDAP
4. 4Confirm authentication type — Microsoft-managed or federated
5. 5Inventory users, groups, licences and active services
6. 6Record licence types, quantities and contract renewal or cancellation dates
7. 7Identify all email-security products and how they are connected
8. 8Export and document all DNS records before any changes
9. 9Confirm backup coverage, test a restore, and check backup authentication
10. 10Decide whether the tenant can and should remain — same-tenant or migration
11. 11Confirm the supported provider exit process — use official documentation only
12. 12Arrange replacement licences or confirmed subscription transfer with dates
13. 13Prepare user communications covering sign-in changes, password resets and timeline
14. 14Define rollback — what happens if each step fails and how service is restored
15. 15Test critical services — email, Teams, SharePoint, SMTP devices, remote workers
16. 16Cancel old services only after written sign-off that all checks have passed

Common mistakes

• Assuming every provider exit is a defederation — many are not
• Treating a licence transfer and a tenant migration as the same thing
• Cancelling the existing licences before replacement licences are confirmed and working
• Having no independent administrator account before the exit begins
• Using unofficial PowerShell scripts or online guides instead of the provider's supported process
• Overlooking contractual notice periods and cancellation terms
• Failing to document bundled security services before they disappear
• Forgetting that backup connectors may be authenticated through the outgoing provider account
• Moving the domain registrar or DNS host unnecessarily during an already complex change
• Failing to check SMTP devices, scanners and applications that send email
• Assuming Teams data and channels migrate automatically — Teams migration tooling has significant limitations
• Not testing remote workers and mobile devices before declaring the migration complete
• Failing to remove old delegated access and GDAP relationships after the exit
• Failing to retain audit log evidence from before and during the migration
• Assuming domain ownership is equivalent to tenant ownership

Warning signs

Pause and complete additional discovery before proceeding where:

• The tenant identity is unknown or cannot be confirmed
• Global Administrator access is unavailable or depends entirely on the outgoing provider
• Every administrator account is owned or controlled by the outgoing provider
• The federation status of the domain is unknown
• The tenant may be shared with other organisations or customers
• Replacement licences cannot be confirmed before the old ones are due to end
• Source-provider approval is required for a transfer but has not been obtained
• Email filtering and security services are undocumented
• Backups have not been tested or backup authentication is unclear
• The domain is attached to another organisation's or provider's tenant
• The proposed approach relies on an unofficial script found online
• User passwords cannot be reset safely without provider involvement
• No rollback plan or user communications plan exists

Other provider types

IT support companies and CSPs often provide Microsoft 365 in a way that gives the business straightforward tenant control. The exit may require only new licences, removal of the provider's delegated or GDAP access, and a handover of support responsibilities.

Telecoms companies may bundle Microsoft 365 with broadband, telephony, domain hosting, email security and support. Each bundled element needs to be identified and a replacement arranged before the contract ends.

Domain and hosting providers may control DNS, email provisioning, authentication and licence billing simultaneously, making the exit dependencies more complex.

Where the Global Administrator account was originally set up by a former employee, a web developer or an external consultant who is no longer reachable, ownership recovery must be addressed before any provider exit can proceed. Microsoft has processes for this, but they take time.

Practical business implications

The IT Club view

Plain-English takeaway

Most businesses can change Microsoft 365 provider, but the correct route depends on how the current service was supplied. Some can retain the same tenant and replace or transfer licences. Others need provider-supported defederation, and some require a full tenant migration. Confirm tenant ownership, administrator access, authentication, licences, security services, DNS and backup before cancelling anything.