Replace that Classic SharePoint Root Site

Working in a client tenant today, I noticed a new suggestion in the SharePoint Admin Center I hadn’t seen before. It’s certainly possible it’s been around for a while, but it was new to me.

The tenant where I’m working has been around since at least 2015. That means it was created with a classic SharePoint site as the root site. Back then there was no such thing as a modern SharePoint site, and Microsoft hasn’t forced us to replace what we got when we created the tenant. In the message above, they are suggesting site modernization. Interesting, I thought.

We do this modernization all the time as we help people build new Intranets or try to get more from their investment in the Microsoft 365 platform. It’s not at all unusual for an organization to have been using Microsoft 365 for years but maybe only using it for Exchange. Or maybe using one Document Library in the root site to store ALL the organization’s documents. Believe me, we’ve seen all sorts of things which would surprise you. It’s one of the reasons we’re so passionate about the Microsoft 365 Maturity Model.

The great thing about this recommendation is it actually steps you through the process. I figured it might be useful to know how it works for those of you who aren’t into the platform up to your elbows like we are.

When you click the View recommendation button, you get a nice set of suggested steps to follow to set up and configure a new modern site for the root.

Here are those steps and links. Generally, organizations will want a modern Communication Site in the root of their tenant. This site tends to be the launchpad for the organization’s Intranet. At the very least, it can be a launchpad into Team Sites where people do their work.

1. Plan the site content. This step includes understanding the goals of stakeholders and the needs of users. Learn more
2. Build the site. Create a communication site, customize the design, and add your content. Learn more
3. Prepare to launch. Set site permissions and test the site. Learn more

The process of building out the new Communication Site need not be complex, but usually you’re planning an entirely new Intranet or set of access paths for folks to get their work done. Thus, while building the new site isn’t complex (you can create a new Communication Site in about 7 seconds!), deciding how it should look, what navigation it should have, what content it should house, etc. can take some real planning. Let’s gloss over all that, shall we?

Once you have the new Communication Site – we tend to build it in a location like /sites/NEWIntranet – you’ll come back and click the Replace root site button. On the following screen, you simply provide the URL to the Communication Site you’ve just built. Note the caveats: the new site can be a Communication Site or a Team Site, but it can’t be a Hub Site or connected to a Microsoft 365 Group. This is because swapping a site into the root means fixing up a lot of links and other stuff under the covers.

Also note the existing root site will be moved to an archive location. You won’t lose the site or its contents – but it won’t be in the same spot anymore.

At this point, I’ve stopped my exploration because clicking that Save button is going to initiate what we call a “site swap”. Once it’s done, your new site will be in the root location, the old site will be in the archive location, and everything should work just great. You’ve put a whole communication plan about this is place before you click the button, right?

---

If you want more control over this process, you can do what some of us have been doing for several years now: you can use the PnP.PowerShell Invoke-PnPSiteSwap cmdlet. You still build the new site in a new location, but when it comes time to do the site swap, you simply call the cmdlet, something like this:

$tenant = "mytenant"
$adminSiteUrl = "https://$($tenant)-admin.sharepoint.com"

Connect-PnPOnline $adminSiteUrl -Interactive

Invoke-PnPSiteSwap `
    -SourceUrl "https://$($tenant).sharepoint.com/sites/Intranet" `
    -TargetUrl "https://$($tenant).sharepoint.com/" `
    -ArchiveUrl "https://$($tenant).sharepoint.com/sites/Archive"

This may appeal to you because you can specify the archive destination, but the net effect is exactly the same. Note that you can only use this cmdlet to swap a site into the root; you can’t arbitrarily swap two other sites. (You can however, rename them.)

---

It’s great to see suggestions like this coming into the admin UIs. It’ll help a lot of organizations with a support staff of one – and there are more of those than most people think!