Copy-SPSite to Change URL

We wanted to take a moment to share this in case it saves somebody from taking the long winding road of sadness that we embarked on yesterday.

There’s quite a bit of chatter online (and from fairly reputable sources in the SharePoint community) about a new PowerShell cmdlet in SharePoint 2013 called Copy-SPSite.

Basically, the only way to “repath” ie. change the URL of a Site Collection in SharePoint is to backup the site, delete it and then restore it to the new URL. You must delete the original before restoring to the new URL because the IDs in the database will be identical and if the original site is not removed you will wind up with a conflict.

Copy-SPSite is being proposed as an alternative because you can specify a new target URL and a target content DB. With this method you can have both the original and new site running, and once you are satisfied that everything has migrated properly remove the old site. The cmdlet changes the IDs so that both sites can exist concurrently. This is great because it reduces the risk of blowing away data and hoping that it will be properly restored.

Here was our experience:

  1. Using the cmdlet it completed without error and we could see the new site collection in Central Admin. The problem was that we would get a “404 not found” error when trying to access the site collection and in Central Admin although it was listed we couldn’t view or modify any of its properties. No amount of IISRESETs would get it to come alive.
  2. Further digging (thanks Colin) revealed that to be successful in most cases you had to specify a target database so that the original and copy were not in the same database. Running the cmdlet with this configuration produced what appeared to be a good copy of the site, but the cmdlet seem to hang and never actually finish. Inspecting the two sites revealed that the original and copy were off by about 1KB and digging into the storage analytics it appears it was stuck on something in the recycling bin.

So What:

In the end we wound up deleting the copies (using a big stick because SharePoint didn’t think they actually existed) and using the traditional backup, delete restore method. Although this sounds promising and eliminates the need to destroy content before we know for sure it can be restored it doesn’t deliver as advertised. We would highly recommend sticking with the way we’ve done it traditionally.

A big thanks to Colin for his help yesterday.