Published 2025-09-18 by TechNet Team
For years, your SharePoint Online tenant URL was permanent. Whatever you picked when you set up Microsoft 365 - that was it. Forever. Even if your company rebranded, merged, or realized that "contoso2019temp" was a terrible choice for a domain name.
Microsoft has finally changed that. Through their Private Preview program, organizations can now rename their SharePoint Online tenant URLs.
Sounds great, right? Maybe. But before you submit that nomination form, you need to understand what you are actually signing up for.
Why This Exists
The tenant rename capability addresses real business needs:
- Rebranding - Your company changed its name and the old URL no longer makes sense
- Mergers and acquisitions - You acquired a company and want unified branding
- Divestitures - You are spinning off a division that needs its own identity
- Mistakes - Someone set up the tenant years ago with a name that never should have stuck
These are legitimate reasons. The problem is not the "why." It is the "how."
The Process
Here is what a tenant rename actually involves:
1. Register for the program
Submit a nomination at Microsoft's SPO Rename Nomination page. This is still a Private Preview, which means Microsoft reviews requests and does not approve everyone.
2. Add your new domain
You need to add the new domain through a specific link - not the normal admin center process. The domain must be in the format newdomain.onmicrosoft.com and must be available.
3. Validate the domain
Standard domain validation process. Nothing unusual here.
4. Schedule the rename
Using PowerShell (SharePoint Online Management Shell version 16.0.21314.0 or later), you schedule the rename. The commands are straightforward:
Connect-SPOService -Url https://contoso-admin.sharepoint.com
Start-SPOTenantRename -DomainName "newname" -ScheduledDateTime "2025-10-15T10:00:00"The scheduled time must be in UTC, at least 24 hours in the future, and no more than 30 days out.
5. Wait and monitor
Use Get-SPOTenantRenameStatus to track progress. The actual processing time is... unknown. Microsoft does not commit to a specific duration.
The Problems Nobody Mentions First
Here is where it gets complicated.
Redirects do not fix everything
Yes, Microsoft sets up redirects from your old URLs to your new ones. But redirects do not work universally across all applications and integrations. If you have:
- Custom applications that reference SharePoint URLs
- Power Automate flows with hardcoded paths
- Third-party integrations
- Embedded links in documents, emails, or external systems
- Bookmarks and saved links across your organization
Some of these will break. Some will redirect. Some will behave unpredictably. You will not know which is which until after the rename.
The admin URL stays the same
Your SharePoint admin URL does not change with the tenant rename. This means any scripts or automation that reference the admin URL need to be aware of the mismatch. It is manageable, but it adds complexity.
Seven pages of documented impacts
Microsoft's own documentation includes seven pages of known impacts across multiple categories. Seven pages. That is not a minor list of caveats - that is a substantial catalog of things that might not work as expected.
Limited support during preview
This is still a Private Preview feature. Support is limited. If something goes wrong, you may not get the rapid response you would expect for a production system issue.
Unknown duration
Microsoft does not tell you how long the rename process takes. For a small tenant, it might be quick. For a large, complex environment with years of content? Nobody knows until you try it.
Should You Do It?
For small, simple tenants with minimal customization: maybe. The risk is lower when there is less to break.
For large, complex tenants with custom applications, extensive integrations, and years of accumulated content: think very carefully.
Questions to ask yourself:
- How critical is SharePoint to daily operations?
- How many integrations reference SharePoint URLs directly?
- How tolerant is your organization of disruption during the transition?
- Do you have the resources to audit, test, and remediate issues?
- Is the rename truly necessary, or just preferred?
Alternatives to Consider
Before committing to a tenant rename, consider:
Education - Sometimes stakeholders push for a rename without understanding the risks. A clear explanation of what is involved might change priorities.
Partial migration - If only certain users or departments need a different URL, migrating them to a separate tenant might be less disruptive than renaming the whole thing.
Living with it - URLs are often less visible to end users than leadership assumes. Most people access SharePoint through apps, links, and search - not by typing URLs.
Vanity domains - In some cases, you can use vanity domains or custom branding to achieve the visual result without changing the underlying tenant URL.
If You Decide to Proceed
Go in with your eyes open:
- Document every integration, custom app, and automation that touches SharePoint
- Test in a non-production environment if possible
- Plan for a remediation period after the rename
- Communicate extensively with users about what to expect
- Have rollback conversations with Microsoft before you start
- Schedule the rename during a low-activity period
The Bottom Line
SharePoint Online tenant rename is a real capability that solves a real problem. But it is not a simple checkbox operation. It is a significant infrastructure change with documented limitations and unknown edge cases.
For some organizations, it is worth the risk. For others, the cure might be worse than the disease.
Make sure you know which one you are before you submit that nomination form.
Need help evaluating whether a SharePoint tenant rename makes sense for your organization? TechNet New England provides Microsoft 365 consulting and migration services. Contact us to discuss your specific situation.