Customer Question: Renaming Site Collections in SharePoint 2013

As part of my day to day role as a Premier Field Engineer, I often receive questions from my customers as well as from colleagues or from their customers.  Last week I received a question that was interesting enough to warrant a blog post and broader discussion.

Note:  The instructions provided are for SharePoint 2013 but these steps are valid and will also work for SharePoint 2010.

Question from Customer

Good Morning.  I wanted to touch base with you on an issue that we are experiencing in our environment.  What we have discovered is that we are having difficulty “renaming” SharePoint 2013 sites. 

Consider the scenario where we need to take an existing SharePoint 2013 Site and rename it.  There are various blogs posts out there that suggest using Copy-SPSite to perform this operation.  What we have found is that the operation appears to work.  However, due to some customizations that we have deployed, we receive the following error:

“Error loading navigation.  The Managed Navigation term set is improperly attached to the site: (Correlation ID: removed)”

Also, what about moving sites between Web Applications within the same environment or between environments (such as from Test into Prod).  In general, what is are the best practices around renaming site collections and moving them from farm to farm?

Response to Customer

First of all, the Copy-SPSite commandlet is a upgrade and migration command that is intended to be used to make a copy of a site collection with its content being written into a user specified content database.  Typically this command is used to make copies of site collections that can be used to validate the upgrade process.   It wasn’t really intended to be used as part of day to day operations and has limitations that prevent it from being used for this purpose

Instead, the best way to accomplish your objective of renaming a SharePoint site collection is to use a combination of the following three commandlets:  Backup-SPSite, Restore-SPSite, and Remove SPSite.  Also, the same set of command can be used to accomplish your second goal of moving site collections between farms (such as from Test into Prod).


Use Backup-SPSite to make a backup copy of a given site collection.  When using this command, you should always specify the –UseSQLsnapshot if your database server supports it.   Including the –UseSQlSnapshot option ensures a valid backup for larger site collections and ensure that users activity does not affect the validity of the backup.

For more information about Backup-SPSite see


Once the backup is complete, use Restore-SPSite to create a new site collection from the backup.  The Restore-SPSite command will automatically assign a new id to the created site collection to avoid the potential of duplicate site ids.  You may specify the ContentDatabase name if you want to restore the site to a specific database and should use the HostHeadeerWebApplication parameter if you want to restore the site as a Host Named Site Collection (HNSC).

For more information about Restore-SPSite, see


Once you have verified that they restored site is functioning as expected you can delete the old site using the Remove-SPSite command.  If the site collection is very large it is highly recommended that you specify the –GradualDelete option so as not to overburden the system while the site collection is deleted.

For more information about Remove-SPSite, see


Each of the usage examples below are based upon the following:

  • Contoso has three SharePoint farms:, and
  • There is an existing site that needs to renamed to
  • A site called needs to be moved from test into prod.

Rename Existing Site

The following command can be used to rename to

Backup-SPSite `
  –Path E:\Backup\HRBackup.bak -UseSqlSnapshot
Restore-SPSite `
  –Path E:\Backup\HRBackup.bak
Remove-SPSite –GradualDelete

Move Site Collection from Test to Prod

The following command can be used to move to

From Test

Backup-SPSite `
  –Path \\BackupServer\BackupShare\ResearchBackup.bak `

From Prod

Restore-SPSite `
  –Path \\BackupServer\BackupShare\ResearchBackup.bak

Move Site Collection from path based URL in Test to Host Name Site Collection in Prod

The following command can be used to move to

From Test

Backup-SPSite `
  –Path \\BackupServer\BackupShare\ResearchBackup.bak `

From Prod

Restore-SPSite `
  –Path \\BackupServer\BackupShare\ResearchBackup.bak `

One of the great about utilizing the commands described here is that, as you can see, they can be used for essentially all of your site move and rename needs and won’t be subject to the limitations of the Copy-SPSite commands.

Hope you found this post helpful and I look forward to reading your comments.

# # # # #

Comments (5)
  1. Araya says:

    Very helpful and to-the-point article. Many thanks!

  2. Martin says:

    We need to change site url during the SP2010 to SP2013 upgrade process. What about site collection size limit for Backup-SPSite and Restore-SPSite commands? I've found recommendation to use these commands for site collections less than 15 GB. But our sites are over 100 GB? Thanks, Martin.

  3. EricA [MSFT] says:


    The site collection backup limit of 15 GB was for MOSS 2007.   There is no actual limit now.  However, the recommendation is to try to limit site collection sizes to 100 GB.  See (…/cc262787.aspx )

    "A site collection can be as large as the content database size limit for the applicable usage scenario…"

    "In general, we strongly recommend limiting the size of site collections to 100 GB for the following reasons:

    •Certain site collection actions, such as site collection backup/restore or the Windows PowerShell cmdlet Move-SPSite, cause large SQL Server operations which can affect performance or fail if other site collections are active in the same database. For more information, see Move-SPSite.

    •SharePoint site collection backup and restore is only supported for a maximum site collection size of 100 GB. For larger site collections, the complete content database must be backed up. If multiple site collections larger than 100 GB are contained in a single content database, backup and restore operations can take a long time and are at risk of failure."

    The old corruption issues for which the 15 GB was initially suggested was due to corruption that can occur if users visit a site while the site is still in the process of being restored (it results in duplicate entries in the user info table).  So as long as you use -sqlsnapshot for the backup, restore the large site collections into a content DB of their own, Prevent access to the site while it is being restored, and throw as much SQL server processing power and IO as possible you should be okay… However, I would thoroughly test so that you know exactly how long the backup/restore operation will take because a 100 GB restore is going to produce a lot of IO operations.  Also, anything that you can do to purge and prune some data would be advisable (delete old versions, delete unused out-of-date data, etc.)

  4. SJ says:

    Or if it's a managed path, you could do:

    $site = Get-SPSite http://sharepoint/sites/old-site


  5. EricA [MSFT] says:


    If you look closely at the documentation for the SPSite object at…/bb862114.aspx, you'll see the following description:

    "Changes the URL of a host-header-named site collection to a new URL"

    Clearly this implies that this method was intended for use with HNSC, your mileage with path-based sites may vary (NOTE: This may work but I did not do any testing on it.)



Comments are closed.

Skip to main content