Share via

Upgrade SharePoint 2010 site collections to SharePoint 2013 mode

  • Article

Migrating content from SharePoint 2010 to SharePoint 2013 normally performed as a two step process.

In this post I’ll present high level steps to upgrade site collections those were migrated from a SharePoint 2010 environment. According to official documentation, site collection upgrade is a responsibility of particular site collections administrators. But this will be handled by farm administrator using scheduled scripts to make the farm consistent.

By the way, site collection administrators will see a notification stating that their site collections are ready to be upgraded to 2013 mode. Furthermore if we create a new site collection, it will be created in 2013 mode by default. To avoid this we can restrict our web application to use only 2010 mode until farm administrator starts the site collection upgrade. To learn more you can refer to this post

1. Deploy upgraded farm solutions

Although we’ve already deployed server side customizations during content database migration, it’s important to remember that those solutions were designed for SharePoint 2010 environment. Hence they were deployed to the 14 hive instead of 15 hive. Upgrading those solutions is beneficial due to following reasons

  • Redesign solutions to include new features of SharePoint 2013
  • Include new features of .Net framework 4.5
  • Review and refactor the code base
  • User experience to suit new SharePoint 2013

After the upgrade, we’ll retract existing farm solutions and deploy upgraded solutions. 

We could’ve deployed upgraded solutions when we migrate content databases as a one time task. But most of the time users will find it difficult to cope up with the change. So we will minimize the impact by gradually executing each parts of the upgrade when users are comfortable.

2. Backup content databases

We’ll backup content databases prior to the site upgrade. This is because site upgrade action is irreversible. If something goes wrong the backup will come to the rescue. It is the best practice to make the database read only until the backup completes.

4. Export list of site collections to a text file

It is possible to upgrade all site collections in a content database using single PowerShell statement. But if we have large site collections in our content databases, that operation might not fit in to our maintenance window. Hence we will export list of site collections to a text file and break that list in to parts for the upgrade.

$backupPath = "D:\Upgrade\"

$contentDB = Read-Host 'Content Database'

$filePath = $backupPath + $contentDB + ".txt"

Get-SPSite -Limit All  -ContentDatabase $contentDB | select url | Format-Table –AutoSize | Out-String -Width 4000 > $filePath

5. Test site collections for errors and warnings

Let’s assume that we will upgrade only 50 sites per job. Before  the upgrade we will test site collections using following PowerShell statements. We will input only selected site urls to text file (e.g.: sites.txt)

$sitesFile = "D:\Upgrade\sites.txt"

$sites = Get-Content $sitesFile
foreach ($site in $sites) {
    Test-SPSite -Identity $site 
}

If there are errors we can use Repair-SPSite command to fix those errors

6. Upgrade site collections

Then we can schedule selected sites for the upgrade. This avoids the hassle of manual site upgrade.

$sitesFile = "D:\Upgrade\sites.txt"

$sites = Get-Content $sitesFile
foreach ($site in $sites) {

    Upgrade-SPSite $site -VersionUpgrade -QueueOnly

}

This will queue selected sites for the upgrade. To check the upgrade status we can use following PowerShell statements

$sitesFile = "D:\Upgrade\sites.txt"

$firstElement = Get-Content $sitesFile -totalcount 1
$firstSite = Get-SPSite $firstElement
$cd = $firstSite.ContentDatabase
Get-SPSiteUpgradeSessionInfo -ContentDatabase $cd -ShowInProgress -ShowCompleted -ShowFailed |ft

We have to do the above for all content databases in that particular web application.