CTS – Your Technology Partner

Preparing for a SharePoint 2013 Upgrade: Planning for a Trial Upgrade – Part 4

Written by Craig Butler on April 4, 2013

Janice Uwujaren

You have decided to upgrade to SharePoint 2013 and have a strategy in place. Now what? It’s time to put your strategy to the test and perform a “dress rehearsal” before the actual performance in the form of one or more trial upgrades. However, before moving on with the trial upgrade, it is important to know the answers to a few key questions.

Should you virtualize your test farm?

The answer to this question will depend on what works best for your environment. With virtualization, you will not need to make an investment in new hardware and it’s relatively easy to stand-up. While virtualization is the cheaper way to go, you will have to account for differences in performance metrics between both farms if you are using physical hardware for your production environment and your test environment is virtual. Generally, physical hardware tends to have better performance metrics.

Should you update your SharePoint 2010 web application from classic-mode authentication to claims-based before trial upgrade?

Microsoft highly recommends that classic authentication be migrated to claims mode before an upgrade. SharePoint 2013 supports classic mode or legacy authentication mode. However, if you want to use classic mode in SharePoint 2013, then consider using Windows PowerShell to configure a web application with classic authentication. Otherwise, change the authentication method to claims before you backup or restore your database.

The Test-SPContentDatabase Windows PowerShell cmdlet and the database-attach method will reveal any conflicts between authentication modes in a SharePoint 2010 content database and SharePoint 2013 web application. DO NOT perform the upgrade to claims authentication with the database-attach upgrade. It can become difficult to troubleshoot failures that occur during the upgrade process. Therefore, you should perform the claims upgrade first, and then do the database-attach. Verify that all external sources and web services are working correctly after the claims upgrade.

What pre-checks and clean up can you perform in your SharePoint 2010 farm before performing the trial upgrade?

According to Microsoft, when preparing to perform a trial upgrade, you should analyze and perform checks in the following areas:

· Install SharePoint 2010 Service Pack 1 or later or it could cause your un-customized workflows to lock after upgrade

· Complete or terminate all “in progress” workflows to prevent locking of workflow tasks in 2013

· Check the authentication mode of all content databases and web applications prior to database-attach.

o Upgrade all classic authentication modes to claims-based. The Windows PowerShell Convert-SPWebApplicationcmdlet in SharePoint 2013 converts classic-mode web applications to claims-based web applications. For more information, visit http://technet.microsoft.com/en-us/library/gg251985(v=office.15).aspx

· Check if you are using existing Web Analytics features, Power Broadcast Sites and PWA Templates in your SharePoint 2010 farm. If you are using Web Analytics or Power Broadcast Sites on any SharePoint 2010 content databases, turn these off, as SharePoint 2013 does not support these features. Analytics processing is now part of the Search service. Upgrade PWA templates to 15-mode before using in SharePoint 2013

· Document the passphrase for your Secure Store Service Application. You will need to use this in the new environment. If you have forgotten your passphrase then refresh the key and then back up the database

· Identify all unique settings from the Web.config files for each web application so that you can transfer these settings to the new SharePoint 2013 servers

· Check to see if all visual upgrades in SharePoint 2010 are now in 14-mode. You can use PowerShell to perform visual upgrade on all remaining sites using the following cmdlet: Get-SPSite | ForEach-Object {$VisualUpgradeWebs()}. Microsoft suggests that you take care of the visual upgrade while your data is still in the 14 farm, so that you can address issues, rollback if necessary and avoid problems during the content database upgrade.

· Check to see if your environment contains any out-of-date SPSites and SPWeb and correct with stsadm -o DeleteSite [-force [-gradualdelete], stsadm -o DeleteWeb [-force], and/ or have end users delete unused and evaluate under-used sites and webs

· Check to see if your environment has any unnecessary document versions, templates, features, and web parts. You can get your end users involved with this process

· If your content database has too many site collections, consider distributing your site collections across multiple content databases before performing the upgrade. SP2013 significantly limits the number of site collections in a content database from warning level of 9000 and limit at 15000 to warning level of 2000 and limit at 5000.

· Use stsadm -o ForceDeleteList or stsadm -o VariationsFixupTool to correct any data issues in the environment:

How can you identify all customizations in your SharePoint 2010 farm?

The first step to upgrading customizations is to know what they are, what they do, and if you should upgrade them to the new farm. Customizations you want to identify include:

· Admin-Deployed InfoPath Forms

· Custom assemblies

· Custom features and solutions

· Custom master pages

· Custom scripts

· Custom site definitions

· Custom style sheets such as CSS and images

· Custom web parts

· Custom web services

· Fab 40 Templates

· Managed Paths

· Manually-deployed features/files/changes

· MSI-deployed components – you will need to reach out to vendors to find out about SharePoint 2013 support or SharePoint 2013 version

· Server Controls

· Web.config changes (such as security)

· Workflows

Below are several methods for identifying customizations in your production environment:

· The Stsadm –o enumallwebs command with the includefeatures and includewebparts parameters provides a listing of all installed features and web parts in your farm. Use the Upgrade Planning Worksheetto document your customizations, and other information about the sites, such as large lists

· Directory comparison tools like WinDiffexamine differences between your production and test farms

· Web config filesfor your SharePoint 2010 product can be used to identify and verify modifications to your environment

· The SharePoint Diagnostic Tool(SPDiag) gathers pertinent information about deployed components in your SharePoint 2010 farm

· A listing of identified customizations through manual observation including differentiating between third-party and in-house customizations

After using one, more, or all of the methods above to identify customizations in your farm, evaluate each for upgrade. Below are some considerations:

1. Are they server-side or client-side customizations?

2. Do the customizations reside in the content database?

3. Are they visual, data structure or non-visual customizations?

4. Are they completely custom code?

5. Did you implement the customizations correctly in your SharePoint 2013 farm?

6. Should you fix or upgrade any customizations before the upgrade?

What impacts should you look for when testing customizations in your trial upgrade?

Master pages, themes, web pages, web parts, style sheets, scripts, and user interface controls will have a visual impact during the upgrade process. This means that they mostly likely will not affect the database upgrade, but may affect the site collection upgrade. Through observation, you should assess the look, feel, and behavior of these customizations. For example, are there any missing or broken web parts? Microsoft recommends that you test these types of customizations in both 14 and 15 modes using the Site Collection Evaluation Upgrade.

Content types, list types, web templates, and site definitions are data structure elements that will have the most impact when performing database upgrades if there are any conflicts or missing templates or definitions. Test 2010 content databases against their target content web applications in SharePoint 2013 using the Test-SPContentDatabaseWindows Powershell cmdlet prior to mounting or attaching SharePoint 2010 Content Database to SharePoint 2013 Web Application. This will help you to identify any errors.

Web Services, Windows Services, HTTP Handler, and HTTP Module are most likely not to play well in the SharePoint 2013 environment. Any issues with these customizations may require removal or replacement. Lastly, with third-party customizations, be prepared to engage with the vendors throughout the trial upgrade process to address any compatibility issues and/or obtain SharePoint 2013 updates.


Replicating your SharePoint 2010 production farm to resemble your SharePoint 2013 test farm will be a tedious process whether you decide to use physical hardware or virtualize. Some may be tempted to shortcut the process by skipping checks or not copying all databases since this is only a trial upgrade. However, this will not represent an accurate depiction of the “true” upgrade process, which defeats the overall purpose of a trial upgrade. Performing the necessary due diligence will keep major problems at bay and prevent unintended consequences.