Has anyone renamed a Microsoft 365 tenant with lots of integrations?

November 13, 2026 4 answers
Asked by sable.understudy

We're considering a tenant rename in a Microsoft 365 environment with SharePoint, Intune, enterprise apps and custom automation. A full migration to a new tenant looks like a much bigger project.

What should we check before changing the name, and where might the old name still show up?

Answers

plainly curious

First, pin down which name needs to change. The organization display name, the SharePoint hostname and the onmicrosoft.com domain are separate things. Changing one doesn't automatically make every trace of the others disappear.

You can add a new onmicrosoft.com domain and make it the default, but the original domain remains. If the goal is to remove the old name completely, check whether that limitation rules out a rename before spending time on the project.

sable.understudy:

The old name being visible is the concern, so knowing where it remains matters more than just changing the admin display name.

Reply to this answer
thimble-tracking_7

I'd start with the places people actually see the old name. A custom domain can cover email and sign-in, while the display name can be changed separately. The original onmicrosoft.com name may mostly be an admin concern.

If the SharePoint and OneDrive addresses are the real problem, scope that change on its own rather than treating every possible rename as mandatory. There may be user-facing sync changes to deal with too.

Reply to this answer
OopsAllCommas

The bit I'd worry about is hardcoded SharePoint addresses. Inventory Power Automate flows, custom apps, scripts and any integrations that store site URLs. Test them after the hostname change instead of assuming an old link redirect will make every connector happy.

Also check sync clients, shared links and anything built on Loop. Set aside time for users to reconnect or troubleshoot OneDrive if needed, and verify Microsoft's current requirements and redirect behavior before scheduling the change.

Fidgett:

Good call on testing flows separately. A link working in a browser doesn't prove an automation using the old address will work.

Reply to this answer
72m+backplane_5

I'd be cautious about jumping straight to a new tenant. That's a migration of identities, data and integrations, not just a cleaner name. But a rename isn't automatically painless either. The reported outcomes range from smooth changes with a few fixes to serious disruption.

Compare both options against the actual requirement. If keeping the original onmicrosoft.com domain is unacceptable, a new tenant may be worth evaluating. Otherwise, inventory dependencies, test the proposed changes and plan a support route before committing.

Reply to this answer

Add your answer

Answers are reviewed before publication.

Related Discussions