Share via

Estimate how long the upgrade process will take and the amount of space needed (Windows SharePoint Services)

  • Article

Applies To: Windows SharePoint Services 3.0

 

Topic Last Modified: 2016-05-08

In this article:

  • Estimate the amount of space needed for the upgrade

  • Estimate how long the upgrade will take

  • Related worksheet

Every environment is unique and includes different hardware capabilities and different site characteristics. The amount of space and the length of time needed to run an upgrade will vary greatly depending on your environment. The best way to estimate how much space will be needed and how long the upgrade process will take is to perform a trial upgrade pass, and then review the sizes and times. For more information about performing a trial upgrade, see Use a trial upgrade to find potential issues (Windows SharePoint Services).

Estimate the amount of space needed for the upgrade

Depending on the upgrade approach you choose, you will need different amounts of available disk space to perform your upgrade. With the in-place upgrade and database migration approaches, you need to plan for very little expansion in the databases; however, there are a lot of transactions taking place while the upgrade process runs, and so the log files will need to expand to accommodate the changes that are occurring.

With a gradual upgrade, you must have space for three sets of databases: the original databases, the temporary databases where the upgrade process takes place, and the upgraded databases. In addition, you need space for the log files and additional search indexes (if needed).

For key recommendations and best practices to help you plan and monitor your SQL Server storage requirements to support optimal performance and operation of your server farms, see Planning and Monitoring SQL Server Storage for Windows SharePoint Services: Performance Recommendations and Best Practices (white paper).

Estimate space for an in-place upgrade or a database migration

For an in-place upgrade or a database migration, you do not need to plan for a lot of extra database space. For a content database migration, you simply need to plan on having as much space available on the new hardware as is required for your current databases, plus room to expand over time. To find out how large your databases currently are, use Enterprise Manager in Microsoft SQL Server. In addition to database space, you also need to 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 do not have enough 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 taking place in the databases; be sure that you have enough disk space for these log files.

    Note

    In very large environments, there is a possibility that the default growth rate for the transaction log files (10%) is not enough to keep up with the upgrade process; this can cause a timeout. Again, a trial upgrade is the best way to determine if 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 pre-growing the SQL Server transaction log files to be sure you have room for the number of transactions that need to be processed. For more information about pre-growing the SQL Server transaction logs, see the "Expanding a Database" topic in the SQL Server 2000 or 2005 documentation.

Estimate space for a gradual upgrade

If you are following a gradual upgrade path, you need to have enough database space to accommodate an amount of data approximately three times the size of your largest site collection. To find out how large your databases currently are, use Enterprise Manager in SQL Server.

If you cannot afford to allocate this much disk space, you can reduce this overhead by upgrading sites in batches. After you have upgraded a few batches and confirmed with the sites' owners that the old versions are no longer needed, you can start cleaning up and deleting the previous version sites (after taking a backup). If you continue in this way, upgrading new batches and deleting sites from the old version, you can regulate the amount of space needed.

In addition to database space, you also need to have room for the following items:

  • The upgrade log files.

  • The transaction log files for the databases. These log files must grow quickly to accommodate the number of changes taking place in the databases; be sure that you have enough disk space for these log files.

    Note

    In very large environments, there is a possibility that the default growth rate for the transaction log files (10%) is not enough to keep up with the upgrade process; this can cause a timeout. Again, a trial upgrade is the best way to determine if 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 pre-growing the SQL Server transaction log files to be sure you have room for the number of transactions that need to be processed. For more information about pre-growing the SQL Server transaction logs, see the "Expanding a Database" topic in the SQL Server 2000 or 2005 documentation.

For more information about how disk space is used during a gradual upgrade, see How the upgrade process works (Windows SharePoint Services).

Estimate how long the upgrade will take

With your disk space estimates in hand, 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 a lot of large document libraries, these may take longer to upgrade than a simpler site.

The upgrade approach you've chosen will also make a big difference in how long the process will take. Upgrading by way of a database migration is the quickest method (keep in mind, however, that the pre-upgrade and post-upgrade steps for this approach take much longer than other approaches). A gradual upgrade is the slowest method because of the extra data copying steps involved. An in-place upgrade falls somewhere in between.

The best way to estimate overall time is to do a trial upgrade of a small portion of the data, and then review the upgrade log files. You can also use the log files to check your progress during the upgrade process. The upgrade.log file located at %COMMONPROGRAMFILES%\Microsoft Shared\web server extensions\12\LOGS contains the duration.

However, the estimate you arrive at based on your data set is for the actual upgrade process for the data; it does not include all of the steps 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 data processing, you must also estimate how long the activities during the pre-upgrade and post-upgrade phases will take.

Pre-upgrade steps:

  • Creating custom elements   Creating a site definition or new page layouts, or upgrading Web Parts, 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 — to be sure you can recover in the remote possibility that the upgrade fails and you need to 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.

  • Creating new Domain Name System (DNS) names for a gradual upgrade   The Domain Name System will take time to propagate changes across the network. For more information about pre-creating the DNS names for a gradual upgrade, see Create new domain names (gradual upgrade only) (Windows SharePoint Services).

Post-upgrade steps:

Additional factors in your environment can also contribute to longer upgrade times, including:

  • Very large document libraries   A document library with more than 250,000 documents all in the root of the document library (rather than in folders) will take a long time to upgrade, and the upgrade might not be successful. Following the 2.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. If your databases are larger than that, it is recommended that you divide them up into smaller databases before running the upgrade. Larger databases not only take longer to upgrade, but they can make it harder to recover if the upgrade does not complete successfully. There are community-supported tools available to move site collections between databases.

    Warning

    If you have a very large database (more than 100 GB) that you cannot break up (because the majority of content is in a single site collection), you may also want to reconsider your upgrade approach. A gradual upgrade approach can handle somewhat larger databases because, with a gradual approach, you can upgrade site collections individually. A database migration approach is more difficult with very large databases, simply because backing up and restoring such large databases is problematic. Of course, a gradual approach requires more space, so you need to consider your options carefully. For more information about using database migration to upgrade sites after finalizing a gradual upgrade, see article 926718, How to attach a content database backup during a gradual upgrade of a Windows SharePoint Services 2.0 farm to Windows SharePoint Services 3.0 in the Microsoft Knowledge Base (https://go.microsoft.com/fwlink/?LinkId=113886&clcid=0x409).
    Be sure you are following the capacity planning guidelines from the old 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 attempting the upgrade. Again, a trial upgrade can help you with that decision.

Worksheet

Use the Estimate database space and time for upgrade worksheet (https://go.microsoft.com/fwlink/?LinkID=798133&clcid=0x409) to determine how much disk space you need to perform the upgrade and how long the upgrade process might take.