Plan for performance during upgrade to SharePoint 2013

We are in the process of combining the SharePoint Server 2013 and SharePoint Server 2016 content into a single content set. We appreciate your patience while we reorganize things. See the Applies To tag at the top of each article to find out which version of SharePoint an article applies to.


Applies to: SharePoint Foundation 2013, SharePoint Server 2013

Topic Last Modified: 2016-12-16

Summary: Understand upgrade performance and how to plan for the space and time that is required to upgrade to SharePoint 2013.

An important part of planning an upgrade from SharePoint 2010 Products to SharePoint 2013 is determining how long the upgrade process will take and how much storage space will be required. Every environment is unique and includes different hardware capabilities and different database and site characteristics. The space and the length of time required to run an upgrade will vary greatly depending on your environment. The best way to estimate these factors is to perform one or more trial upgrades, and then review the space and time that it took. For more information about how to perform a trial upgrade, see Use a trial upgrade to SharePoint 2013 to find potential issues.

One of the main reasons that database upgrade and site collection upgrade are now separate actions for SharePoint 2013 is to give you more control over upgrade performance.

  • How upgrade works for SharePoint 2010 Products

    During an upgrade to SharePoint 2010 Products, when the database was upgraded, all of the site collections in that database were also upgraded. That meant that for certain steps, such as activating features or updating the Quick Launch control, the upgrade process needed to perform the step repeatedly for each site collection in a database before the database upgrade was completed.

    Upgrade process for SharePoint 2010 Products

    Upgrade process for SharePoint 2010 Products

  • How upgrade works for SharePoint 2013

    When you upgrade to SharePoint 2013, the database upgrade no longer starts these site-specific steps. Therefore, the database upgrade stage is much faster. Some tests have found that a database can be upgraded to SharePoint 2013 in two-thirds of the time that it took to upgrade the same data to SharePoint 2010 Products. These site-specific steps must still be performed. However, they are performed only when the site collection is upgraded, and then only for that site. Because each site collection is upgraded independently, you can manage the performance effect of those upgrades on your environment.

    Upgrade process for SharePoint 2013 Products

    Upgrade process for SharePoint 2013 Products

For SharePoint 2013, you can control the performance effect of site collection upgrades by controlling how many sites can be upgraded at a time. There is a site collection upgrade queue that maintains a list of site collections currently requested to be upgraded. And there are throttles on the content database and web application levels to control how many site collection upgrades can occur at a time. For more information about these controls, see Plan for site collection upgrades in SharePoint 2013 and Manage site collection upgrades to SharePoint 2013.

In addition to planning for performance during upgrade, you must also plan for the performance of your production environment after upgrade. Test your planned environment to make sure that you can support your environment by using the hardware that you have planned.

As the databases are upgraded, they expand temporarily. Also, many transactions occur while the upgrade process runs. Therefore, you must make sure that the log files have room to expand to accommodate the changes that are occurring. Therefore, you have to plan for growth in both the databases and the log files.

Because of the changes in table structures in the new version, the databases grow temporarily while the data is reorganized. This space can be recovered after upgrade, but you should make sure that there is room for the databases to grow up to 50 percent larger than their current sizes during upgrade (be aware that after upgrade, you can reduce the database again to recover much of this space).

You should also make sure that there is room on your database servers for your databases to grow over time with typical use. To check how large your databases currently are, use Enterprise Manager in SQL Server.

In addition to database space, you must also have room for the transaction log files for the databases. These log files must grow quickly to accommodate the number of changes occurring in the databases

In very large environments, there is a possibility that the default growth rate for the transaction log files (10 percent) is not enough to keep up with the upgrade process. This can cause a time-out. Again, a trial upgrade is the best way to determine whether the transaction log files can keep up with the upgrade process. If your environment is very large, or if the process timed out during a trial upgrade, consider expanding the SQL Server transaction log files beforehand to make sure that you have room for the number of transactions that must be processed. For more information about how to expand the SQL Server transaction logs, see Expanding a Database (SQL Server 2008 R2).

With your disk space estimates in hand, and some testing done, you can now calculate a rough estimate of how long the actual upgrade process will take. Upgrade times vary widely among environments. The performance for an upgrade depends greatly on the hardware being used, the complexity of the sites, and the particular characteristics of your implementation. For example, if you have many large document libraries, these may take longer to upgrade than a simpler site.

Factors that influence performance for upgrade are described in the following list.

  • Environment factors  The following factors can affect the performance for both database and site collection upgrade:

    • Simultaneous upgrades

    • SQL Server disk input/output per second

    • SQL Server database to disk layout

    • SQL Server temporary database optimizations

    • SQL Server CPU and memory characteristics

    • Web server CPU and memory characteristics

    • Network bandwidth and latency

  • Database factors  The following factors can affect the performance of database upgrade. The number of:

    • Site collections

    • Subwebs

    • Lists

    • Rowspan within lists

    • Document versions (number and size)

    • Documents

    • Links

    Plus the overall database size itself.

  • Site collection factors  The following factors can affect the performance of site collection upgrade. The number of:

    • Subwebs

    • Lists

    • Activated upgrading features

    • Document versions (number and size)

    • Documents

    • Links

How your data is structured can affect how long it takes to upgrade it. For example, 10,000 lists with 10 items each will have a longer upgrade time than 10 lists with 10,000 items. The actions required to upgrade the list infrastructure must be performed for each list, regardless of the number of items. Therefore, more lists equals more actions. The same goes for most of the items under database factors or site collection factors.

The structure of your hardware can also have a big effect on performance. Generally, the database server performance is more important than web server performance, but underpowered hardware or connectivity issues at either tier can significantly affect upgrade performance. Web servers have a significant part to play in database upgrade performance, mainly by issuing the commands to make data and structural changes in the databases. The database servers have to process those changes and work with a large set of data for every command. Web server performance becomes a bigger issue during site collection upgrade, when the upgrade process iterates several actions for each site collection (which might occur for multiple site collections at a time). Site collection upgrade also affects the database server as each action must occur in SQL Server.

The best way to estimate overall time is to do a trial upgrade of the data, and then review the upgrade log files. The log files contain the duration for an upgrade — look for Total Elapsed Time at the bottom of the upgrade log file. Use this time to estimate the duration for your full set of content. You can also use the log files to check your progress during the upgrade process. The upgrade.log file is located at %COMMONPROGRAMFILES%\Microsoft Shared\web server extensions\15\LOGS.

To determine durations from the logs, examine:

  • The times spent in each upgrade sequence per log.

  • The times spent per upgrade action instance per log.

  • The minimum, maximum, and average times.

Make sure that you separate out the database upgrade times from time that is spent upgrading site collections for accurate planning. Perform multiple trial upgrades to guarantee more accurate data. Then collate the data from multiple tests to determine likely performance per sequence, action, and database. You can use the Get-SPUpgradeActions cmdlet in Windows PowerShell to see how many actions occur for the farm. For more information, see Get-SPUpgradeActions.

The estimate you arrive at based on your trial upgrade is for the actual upgrade process for the data. It does not include all of the steps that you have to perform before and after this step, which can take more time than the upgrade of the data itself. When estimating how long the upgrade will take, in addition to the time that is required for data to be processed, you must also estimate how long the activities during the upgrade phases will take.

Consider the following factors:

  • Creating custom elements   Upgrading Web Parts or re-doing custom templates to take advantage of new features will take some time. The process of creating custom elements should begin early, during the evaluation phase of your project.

  • Backing up the databases   You must perform a full backup — not a differential backup — of your databases for a database-attach upgrade. For large environments, this step can take significant time. In particular, if you are backing up to a network location, network latency issues can slow this process down.

  • Creating service applications and configuring services   Creating service applications and configuring services does not take long. However, if you must contact a database administrator to create the databases for you before you create service applications, you might need a day or two of lead time.

  • Running a search crawl on all content   For large sites, this step can take more than 24 hours. Unless you run a crawl, searches cannot return results because the index is not upgraded.

  • Verifying the environment after upgrade   For large environments, it can take a while to verify the environment and check the site collections to make sure that they are in a good state before you allow users access to them. For more information, see Verify database upgrades in SharePoint 2013.

For site collection upgrade, consider the following factors:

Additional factors in your environment can also contribute to longer upgrade times. They include the following:

  • Very large document libraries   A document library with more than 250,000 documents all in the root of the document library (instead of in folders) will take a long time to upgrade, and the upgrade might not be successful. Following the guidelines for using folders to break up large document libraries can help you manage the library size. For example, if you rearrange the same document library so that the 250,000 documents are divided into 125 folders, it should upgrade more easily.

  • Very large databases   Databases larger than 100 GB can take a long time to upgrade.

    If you have content databases that are larger than 100 GB and include mixed site types (such as My Sites and team sites together with published sites), we recommend that you divide them up into smaller databases that contain a consistent type of data before you run the upgrade.

    My Sites are available only with SharePoint Server, not SharePoint Foundation.

    You can use the Move-SPSite Windows PowerShell cmdlet to move sites between databases. For more information, see Move-SPSite.

    Be sure that you are following the capacity planning guidelines from the previous and new versions before you attempt the upgrade. If you have exceeded the guidelines for best performance, the upgrade process might take longer, or it might fail (for example, the process might time out repeatedly on the same large document library). If your deployment does not meet the recommended capacity guidelines, consider whether you have to do some work to meet those guidelines before you try the upgrade. Again, a trial upgrade can help you with that decision.

  • Wide lists (lists with many columns)

    Wide lists are lists with more columns than fit in a single rowspan in the content database. These lists can take longer to process during upgrade, or might not upgrade. For more information, see Clean up an environment before an upgrade to SharePoint 2013.

  • Sites with many subwebs

    Site collections that contain hundreds or thousands of subwebs will take much longer to process during site collection upgrade. For example, a site collection with thousands of subwebs might take many hours instead of many minutes, or longer, to upgrade.

  • Communications requirements

    You have to notify the users and your team of the upgrade schedule, and give them time to do their tasks. For more information, see Create a communication plan for the upgrade to SharePoint 2013.

  • Managing system center alerts and alarms

    You have to monitor system performance during upgrade, but you will not have to monitor specific features. Pause any unnecessary alarms and alerts from Microsoft Systems Center Operations Manager or Microsoft Operations Manager, and then turn them on again after upgrade.

  • Turning SQL Server mirroring and log shipping (or AlwaysOn Availability Groups) on/off

    You should turn off mirroring and log shipping before you upgrade, and then turn them on again after you are sure that your environment is running correctly after the upgrade. We recommend that you do not run mirroring or log shipping during upgrade, because this creates additional load on the servers that are running SQL Server and also wastes resources mirroring or shipping temporary data.

    This also applies to AlwaysOn Availability Groups in SQL Server 2012.

Test the upgrade process to discover how long it may take, then create a schedule for the upgrade operations and test that to determine your timeline. You should include the time that that is required to do the pre-upgrade and post-upgrade steps in your operations timeline: If it takes 5 hours to back up your databases, you must include that time in your timeline. Also include buffer time in case you have to restore or recover — you should determine both your planned outage (realistic case) and your emergency outage (worst case) timelines.

After you complete an upgrade, the environment will likely experience some lag in performance as it works through the changes. Make sure that you confirm the actual performance against your expected performance after upgrade to make sure that your new farm is performing within acceptable bounds. Check SQL Server responsiveness: is the disk queue length too long? Are CPU and memory usage too high? Also look for web and application server responsiveness: is the number of requests per second (RPS) acceptable? What about page load time (initial and secondary page requests). Review your overall environment performance and make adjustments as needed.