 So Jeff says, good evening. Hey, it's morning somewhere. I'm searching for a way to create an alternate site collection, which will eventually replace the current main site collection of my client. So currently, companyname.sharepoint.com is the default SharePoint site. The site is sort of jacked in the way that it was, it's ripped, it's buffed, it's jacked in the way that it was originally created, and rather than reverse fix it, I think creating a new site would be best. Google and BingFu has been exhausted and not finding the best way to execute this operation. I'd like to create companyname. Underscore a.sharepoint.com and an optimized setup and once approved by client, move existing documents over then nuke the original. Appreciate any insights or directions on this. Well, I'll start by saying companya.sharepoint.com is buying a new tenant. Yeah. So I think this is a classic case and the links I dropped in were oriented around site swap, root site swap. That's the way to not incur additional expenses. I also threw a link to the page diagnostics tool in there because any root site swap now requires a clean bill of health from the page diagnostics tool. And I know you were on this one too, Sharon. Super duper easy to do. I think the only caveat I would add on that is that when you do a root site swap, it automatically marks the outgoing site as an archived. It changes the URL to an archive site. So just be forewarned that you really are kind of nuking it. Can you recover from that? I'm asking, because I don't know. Can you recover from that if it's an archive state? Like use a migration tool to move stuff if you had to? You still, if you click on it, it'll still like, you can get to stuff, but the problem is, is that what I have found, and I'm still waiting for this to get fixed, is it doesn't recover. Like, so let's say for example, you have slash site slash site one, and you make that the root site, that slash site slash site one, that name that was there gets taken and never gets given back. So it changes it to an archive state, but you never like reclaim the original site structure name. That's also another thing that I've turned in is kind of a hanging issue for doing it. So if you're gonna swap the root site, you can't have any hub associations with it before you swap it. So you have to unhub everything. You have to, like Sean said, make sure it passes all the diagnostics that's clean and know that when you swap it out, that it's for all intents and purposes, it's kind of trashed. As of now at least. I think the technology part will be straightforward and doable, but it's the change management piece when people have lost all of their favorites and links to documents or other site assets have gone away. That will be the hard part and the part that you'll need to reconcile before you do anything like this. Good point. Yeah, if you're really smart, you probably do maybe plan ahead, maybe migrate things you need. Communicate, communicate, communicate. Yeah. Details. Yeah. But then they have to pay attention to, that's the other piece of it, right? Cool. Not everybody's good at that paying attention thing. Plan, plan, plan, plan, plan, plan, plan. This is overrated. Yeah. Where's your sense of adventure? Come on. Throw caution to the wind. See what happens. Live a little. That's exactly the attitude I want to hear when I'm moving sites. Especially hiring a third party consultant to come in and do it. Exactly. This guy clearly has my best day, cheers and heart. That's right. It's the spice of life, people. Come on.