Delete Microsoft 365 Tenant

原文：Delete Microsoft 365 Tenant — theDXT (Daniel Keer)

There are various reasons why you may need to delete a Microsoft 365 tenant. The most common one I run into is after a corporate merger or acquisition. In this post, I will show step-by-step how to delete a Microsoft 365 tenant.

Why You Might Want a Tenant Gone

Deleting a tenant is a destructive, hard-to-reverse operation, so it is worth being clear about the situations where it is actually the right answer:

• Merger or acquisition. The acquired company's identity, mail and devices have been migrated into the parent tenant, and the leftover directory is now a maintenance liability — stale accounts, unused licences, and an extra attack surface nobody monitors.
• Dead proof-of-concept or demo tenants. Trials created for an evaluation that ended months ago are still consuming an onmicrosoft.com name and, in some cases, still billing.
• Expired partner or sandbox tenants. Tenants created for a short engagement, where the contact at the client has moved on and nobody can obtain admin consent to clean it up properly.
• Rebranding or re-creation. Sometimes the cleanest path after a botched migration is to stand up a fresh tenant and decommission the old one entirely.

Whatever the reason, one rule applies before anything else: deleting the tenant does not cancel your subscriptions by itself. Work through the prerequisites below in order, because the deletion job will refuse to run if any of them are unmet.

What "Deleting a Tenant" Actually Means

This is not a toggle. When you confirm the deletion, Microsoft Entra ID runs a series of validation checks and then starts a background job that permanently removes the directory and everything inside it: users, groups, devices, Intune configuration, app registrations, enterprise applications, service principals, Conditional Access policies, and the directory-side relationships to Microsoft 365 services. Mail, SharePoint and Teams data belonging to those users goes away with it.

While the deletion is in progress you will see a notification, and Entra offers you the option to cancel it from that notification. That window is your only safety net. Once the job completes, there is no restore, no support ticket that brings it back, and you generally cannot re-register the same onmicrosoft.com domain name, because that namespace is owned by Microsoft rather than by you.

Billing is separate. A tenant with an active subscription can be scheduled for deletion while the subscriptions keep renewing, so if you want the invoices to stop you must cancel the subscriptions yourself, or let them expire, before or after the deletion — it is not automatic either way.

Prerequisites

These are the conditions the deletion check enforces. Completing all of them takes time and sometimes individual items get stuck, but it is possible to complete every one of them.

• All invoices are paid. Outstanding balances will block the account from being closed cleanly, and a billing hold can stall the subscription cancellation you need.
• All domains are removed other than the CompanyName.onmicrosoft.com domain name. The initial domain cannot be removed and does not need to be.
• All users are deleted and also removed from deleted users, except for one Global Admin — the account you are using to perform the deletion. Deleted users sit in a 30-day recycle bin, which is enough to fail the check.
• All app registrations and enterprise applications are deleted. Service principals and their credentials are a surprisingly common blocker, because an application with a valid secret is considered live.
• No Azure subscriptions. A tenant that owns even an empty pay-as-you-go subscription cannot be deleted until it is gone.
• All licenses are deleted and removed — including disabled or expired subscription records left behind by a trial.

Two more items that are not on Microsoft's public checklist but trip people up constantly: remove all other Global Administrators, leaving only the account doing the deletion, and make sure no directory synchronisation is still attached. A lingering Azure AD Connect instance for a tenant that no longer has servers is rare, but an unattended sync rule set can keep recreating objects you delete.

The Process

• Login to the Entra admin center.
• Click on Identity > Overview.

• Click on Manage tenants.

• Select the tenant and click Delete.

• It will check if the tenant can be deleted.
• If all checks pass you can click on Delete.

• After clicking Delete you will see a notification letting you know the tenant has been deleted.

• Once you log out that is the end.

If you try to log in again you will get errors.

That's all it takes to delete a Microsoft 365 tenant.

Understanding the Check Results

When the validation runs, it presents one line per prerequisite with a pass or fail state. Reading those lines carefully saves a lot of guessing, because they map directly onto the list above: each failing row names the category of leftover object — users, deleted users, domains, applications, subscriptions or licence assignments — and clearing it and re-running the check is the whole workflow.

Two practical notes about the check itself. First, it is not instant if your directory is large; the validation can take a few minutes to enumerate everything. Second, the results are a snapshot, not a live monitor — if you delete a group while the check is running, re-run the check to confirm the row has cleared.

What You Will See Afterwards

After the deletion starts and you sign out, signing back in is where the finality becomes obvious. Authentication against the deleted tenant fails outright — you get an error rather than a graceful "no access" message, because there is no directory left to authenticate against. Bookmarked URLs for the tenant's admin centers will redirect to a generic error or to the sign-in page for whatever other tenant your account belongs to.

If you have other tenants in your Manage tenants list, they are entirely unaffected. Tenant deletion is scoped to the directory you selected, and the account you used will simply see one fewer entry the next time you open the tenant picker.

Common Blockers and How to Clear Them

• Deleted users still present. Go to Users > Deleted users, select each one and choose Delete permanently. Bulk-select and clear the whole list in one pass.
• Enterprise applications you cannot delete. Some applications are managed by Microsoft or are provisioned by a service such as an MDM connector. Disable them first, remove their owners and credentials, then delete. If an app refuses, check whether it is a Microsoft first-party service principal that is simply reporting a subscription you have not cancelled yet.
• Custom domains that will not remove. A domain that still holds users or groups as their UPN or mail address cannot be removed. Delete or rename the objects that reference it, then remove the domain.
• An Azure subscription you forgot about. Check the Azure portal with an account that has access to every subscription, not just the one you are logged into by default. An old "hidden" subscription under a departed employee's account is a classic cause of a permanently failing check.
• Licences that reappear. A subscription in a disabled or expired state can still count. Remove the licence assignment objects and cancel the parent subscription outright rather than waiting for expiry.
• Other Global Administrators. Remove all secondary global admin accounts so that only the deleting account holds the role.

In my experience the check will pass on the third or fourth attempt rather than the first, and the failures are almost always one of the items above rather than something genuinely mysterious.

Do You Really Need to Delete It?

Deletion is permanent, so it is worth pausing on the alternatives. If the only problem is cost, cancelling the subscriptions and removing the licence assignments leaves a dormant directory that costs nothing and takes minutes to reactivate — though it does keep the onmicrosoft.com name reserved. If the problem is that the tenant is untidy but might still be needed for historical mail or eDiscovery, exporting what you need first and then leaving the tenant disabled is a safer sequence than a hard delete.

Two governance habits make either path easier. Before you decommission anything, take a full record of the directory — users, groups, application owners, licence assignments, and the Conditional Access policy set. Migrating any remaining workload to a clean target is far simpler when the design follows a documented pattern rather than whatever grew organically, which is the same reasoning behind keeping other directory processes orderly, for example Control Microsoft 365 Group Creation. And keep an audit trail of who signed off, because the tenant is gone for good: Microsoft 365 Audit Logging is where that trail should live while the tenant still exists.

Key Takeaways

• Only a Global Administrator can delete a tenant, and the tenant checks a strict list of prerequisites before it will proceed.
• Subscriptions are not cancelled by deletion. Cancel them first unless you want the billing to continue.
• Deleted users must be purged permanently, not merely deleted.
• There is a short cancel window after the deletion starts. After that, it is irreversible.
• Clear the blockers one category at a time and re-run the check; expect a few iterations.

For more details on deleting a Microsoft 365 tenant, you can read the Microsoft documentation here. If the tenant you are decommissioning is the same one that hosts your identity configuration, it is worth reviewing Azure AD Connect 2.0 Won't Start first, so nothing unexpected happens to the surviving directory mid-task.