Using Invoke-SPOSiteSwap to Swap in a New Root Site in Office 365
Things we used to think of as miracles happen almost every week in Office 365. The latest thing that impressed me is the ability to swap an existing site into the root site of your tenant using the Invoke-SPOSiteSwap PowerShell cmdlet.
The Sympraxis tenant has been around since practically the old BPOS days, so the root site originally was effectively a SharePoint 2010 -style site. (Remember when we could decide whether we wanted the 13 or 14 experience? Meet the old modern – same as the new modern…)
The cmdlet is pretty simple. You just provide the SourceUrl, the TargetUrl, and the ArchiveUrl – where you’d like the old site to be moved.
Invoke-SPOSiteSwap
-SourceUrl <string>
-TargetUrl <string>
-ArchiveUrl <string> In my case, it looked like this:
Invoke-SPOSiteSwap
-SourceUrl https://sympraxis.sharepoint.com/sites/Intranet
-TargetUrl https://sympraxis.sharepoint.com
-ArchiveUrl https://sympraxis.sharepoint.com/sites/Archive Making the swap is actually pretty painless, but there are some constraints. Neither the source or target site can be:
- Connected to an Office 365 Group
- Be a Hub Site, or
- Be associated with a Hub Site
I found the documentation to be a little unclear on this, so I’ve already made some suggestions about how to make it clearer in a pull request.
When I first tried to run the cmdlet, I got the error:
Invoke-SPOSiteSwap : The site https://sympraxis.sharepoint.com/sites/Intranet cannot be used with this cmdlet because it's a hub site At line:1 char:1 + Invoke-SPOSiteSwap -SourceUrl https://sympraxis.sharepoint.com/sites/ ... + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo : NotSpecified: (:) [Invoke-SPOSiteSwap], ServerException + FullyQualifiedErrorId : Microsoft.SharePoint.Client.ServerException,Microsoft.Online.SharePoint.PowerShell.SwapSiteMy Intranet site was a Hub Site, so I needed to:
- Dissociate the sites associated with Intranet
- Demote Intranet from being a Hub Site
- Do the swap
- Promote Intranet to a Hub Site again
- Re-associate the sites which were associated with it before
Invoke-SPOSiteSwap is rolling out from smaller to larger tenants now. If you’re in a “large” tenant (by seats), you should have it by October – if all goes according to plan. You also need to have the SharePoint Admin PowerShell version 16.0.8812.1200 or later.
All in all, another great tool to add to out toolkit. It is useful in a case like mine, but also consider the case where you want to launch an entirely new Intranet look and feel. You could build out the root site as much as possible, then swap it in when you are ready! You do need to think things through, especially with respect to search indexing, links in things like Words docs (just don’t do this!), etc. As with many things, the technical part is now easy, but it doesn’t mean you get off the hook on thinking things through.
Be sure to check out my follow up post: Using Invoke-SPOSiteSwap to Swap in a New Root Site in Office 365 – Follow Up
References
- Invoke-SPOSiteSwap
- SharePoint Online Site Swap Feature Rolling Out by Tony Redmond (@12Knocksinna)
- Video from Todd Baginski (@toddbaginski)
Marc, Been waiting for this, thanks. I’m assuming any inks using absolute urls won’t get updated?
@matthew:
I didn’t experiment with the many things which might not work right in all this. I expect that they are able to fix up many things, but we each manage to add stuff to our sites which might need some tweaking post-swap.
M.
Very useful, thanks for sharing! And good to know it works with the root URL.
… and that it lets you re-associate sites to the hub once at the root.
Hi, do you know if after swap root Communication Site can be set as a Hub Site?
@Piotr:
Absolutely. That’s one of the things I did after I did my swap in this post.
M.
Marc, found an interesting bug working with a client doing a site swap.
If they have Nintex on the site pre-swap, you have to remove the forms and workflows from the site, then remove the Nintex apps from the sites, do the site swap, then ensure there are no ghost files of Nintex in your lists/libraries after the switch.
After you’ve verified you’re all good, then you can re-install the Nintex Apps to your site and then re-add your forms/workflows to the list/library.
If you don’t follow those steps, you’ll never get your Nintex stuff working on a site with a site swap.
@Trace:
I guess that’s not too surprising. Clearly, the more vanilla the site you want to swap in is, the more likely it will work.
M.
Hi Marc,
Since Msft says this doesn’t work at all with publishing sites, do you know if there’s anyway to convert a publishing source site so it can be swapped?
@webbrewers:
The intention for Invoke-SPOSiteSwap is to swap a Communication Site into the root site of the tenant. One of the restrictions they put on it is the case where the root site uses publishing features.
M.
Hi Marc?
And the document library, will the files be replaced or the swap will retain the old ones?
VP
@Vasco:
The entire site is swapped in, so all content goes along with it.
M.
Hi Marc, hoping you see this since this post is pretty old. If we use this cmdlet to swap a communication site to make it our root site, do we also need to do the same for the search center that is tied to the existing root site?
@Nate:
No, modern search happens right where you search: an overlay on the page contains the results. There’s no longer a search center per se.
M.