Share via

Estimate how long the upgrade process will take and the space that you need (SharePoint Foundation 2010)

  • Article

 

Applies to: SharePoint Foundation 2010

An important part of planning your upgrade from Windows SharePoint Services 3.0 to Microsoft SharePoint Foundation 2010 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 site characteristics. The space and the length of time that you need to run an upgrade will vary greatly depending on your environment. The best way to estimate these factors is to perform a trial upgrade, 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 find potential issues (SharePoint Foundation 2010).

In this article:

  • Estimate the space that you need for the upgrade

  • Estimate how long the upgrade will take

Estimate the space that you need for the upgrade

During both the in-place upgrade and database attach upgrade approaches, the databases might expand during upgrade. Also, many transactions take place while the upgrade process runs, so you must make sure that the log files have room to expand to accommodate the changes that are occurring. You have to plan for growth in both the databases and the log files.

When planning your upgrade, make sure that your current environment follows the best practices for storage for Windows SharePoint Services 3.0 so that you have the best experience and performance during upgrade. For more information, see Physical storage recommendations (Office SharePoint Server). You should also review the best practices for SharePoint Foundation 2010 and make any adjustments needed to your upgraded environment.

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 ensure that there is room for the databases to grow up to 50 percent larger than their current sizes during either an in-place or database attach 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 find out how large your databases currently are, use Enterprise Manager in Microsoft SQL Server. In addition to database space, you also must have room for the following items:

  • The temporary databases. Ensure that you have enough database space to enable quick growth of the temporary databases. If you have insufficient space, the upgrade process might time out and the upgrade will fail.

  • The upgrade log files.

  • The transaction log files for the databases. These log files must grow quickly to accommodate the number of changes occurring in the databases.

    Note

    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 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 2005) (https://go.microsoft.com/fwlink/p/?LinkId=182619) or Expanding a Database (SQL Server 2008) (https://go.microsoft.com/fwlink/p/?LinkId=182620).

Estimate how long the upgrade will take

With your disk space estimates in hand, and some testing under your belt, 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 are described in the following table.

Content factors Hardware factors

The number of:

  • Site collections

  • Subwebs

  • Lists

  • Document versions (number and size)

  • Documents

  • Links

Plus the overall database size itself.

  • 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

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 in the "content factors" column in the table above.

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.

The upgrade approach you have chosen will also make a big difference in how long the process will take. Performing a database attach upgrade is the quickest method (however, the pre-upgrade and post-upgrade steps for this approach take longer than for in-place upgrade). An in-place upgrade takes a little more time because you are upgrading the environment in addition to the sites, but you do not have as many pre-upgrade and post-upgrade steps when you use this approach.

The best way to estimate overall time is to do a trial upgrade of a small part or all of the data, and then review the upgrade log files. The log files contain the duration for your upgrade — look for Total Elapsed Time at the bottom of the upgrade log file. Use this time to project a 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\14\LOGS.

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 pre-upgrade and post-upgrade phases will take.

For pre-upgrade steps, 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   For in-place upgrade, you must perform a full backup — not a differential backup — of your entire environment to make sure that you can recover in the remote possibility that the upgrade fails and you must rebuild your server farm. For large environments, this step can take a significant amount of time. In particular, if you are backing up to a network location, network latency issues can slow this process down.

For post-upgrade steps, consider the following factors:

Additional factors in your environment can also contribute to longer upgrade times, including 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 Windows SharePoint Services 3.0 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.

    Note

    If you have content databases that are larger than 100 GB you might want to divide them up into smaller databases before you run the upgrade. Larger databases not only take longer to upgrade, but they can make it harder to recover if the upgrade is not completed successfully.
    You can use the mergecontentdbs or the backup and restore operations in Stsadm.exe to move sites between databases. For more information, see Mergecontentdbs: Stsadm operation (Windows SharePoint Services) and Backup and restore: Stsadm operations (Windows SharePoint Services).

    If you have a very large database (more than 100 GB) that you cannot break up because most of the content is in a single site collection, you may want to reconsider your upgrade approach. A database attach upgrade approach is more difficult with very large databases, because backing up and restoring such large databases is problematic.

    Warning

    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 not succeed (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 need to do some work to meet those guidelines before you try the upgrade. Again, a trial upgrade can help you with that decision.

  • Communications requirements

    You need to notify your users and your team of the upgrade schedule, and give them time to do their tasks. For more information, see Create a communication plan (SharePoint Foundation 2010).

  • Managing system center alerts and alarms

    You need to monitor system performance during upgrade, but you will not need 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 mirroring and log shipping 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 running SQL Server and also wastes resources mirroring or shipping temporary data.

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

See Also

Other Resources

Downloadable book: Upgrading to SharePoint Foundation 2010
Resource Center: Upgrade and Migration for SharePoint Foundation 2010