In order to change a Managed Path for a site collection we need to backup and restore that site collection to the new Managed Path.
I attempted to backup and restore a site collection today, with the goal of changing the managed path from:
After mounting the 2010 version Content DB in from the 2010 Production farm, into the 2013 farm, and attempting to run the PowerShell to backup and then restore the site collection, I ran into an error:
Restore-SPSite : <nativehr>0x80070003</nativehr><nativestack></nativestack>.
Once I ran the Visual Site Collection upgrade and brought the site collection up to 2013, I could run my script to backup/restore and get the managed path changed.
I found this which explained some things for me:
While the below comment from that thread doesn’t address the exact scenario, it may also be helpful for us to know:
I am wondering if anyone noticed but on SharePoint 2013 we have lost a lot of the flexibility in the restore process?
On SharePoint 2010 you could and still can restore from one SP20120 server to a another SP2010 server with a different cumulative update/version, once the destination server (where you trying to restore to) does not have a cumulative update that is pre that of which is installed on the source server. In summary site collection backups would restore to SharePoint servers which has equal or above cumulative updates.
Example of this…
You could.. 1. Backup a site collection from Server A with December 2010 CU and then restore to Server B running July 2011 CU.
2. Backup a site collection from Server A with SharePoint Foundation December 2010 CU and then restore to Server B running SharePoint Server December 2010 CU. (Foundation –> Server)
3. Backup a site collection from Server A with December 2010 CU and then restore to Server B running December 2010 CU. (Identical servers)
You could not… Backup a site collection from Server A with July 2011 CU and then restore to Server B running December 2010 CU.
Example 1 & 2 above are no longer available on SharePoint 2013
Moral of the story seems to be that you better make sure your major version and CU levels are on par before you attempt changing the managed path like this. By running the Visual Site Collection upgrade everything got brought into SP 2013 mode and the process could complete.
The PowerShell used was:
#Get the from Site Collection URL $fromURL = "https://go.site.com/site/siteA" #Get the to Site Collection URL $toURL = "https://go.site.com/department/siteA #Get DB Reference $Database = Get-SPContentdatabase "org_SiteAContentDB1" #Location to the backup file directory to store Site Collection backup files $backupPath = "d:topSharePointBackupsorg_SiteAContentDB1.bak" #Backing up Site Collection prior to moving Write-Host "Backing Up Site Collection…." Backup-SPSite $fromURL -Path $backupPath -force #Removing Site Collection from old managed path Write-Host "Removing Site Collection from old managed path location…" Remove-SPSite -Identity $fromURL -Confirm:$false #Restoring Site Collection to new Managed Path Write-Host "Restoring Site Collection to new managed path location…" Restore-SPSite -Identity $toURL -Path $backupPath -Confirm:$false #Remove backup files from the backup directory Remove-Item $backupPath