Estimate how long the upgrade process will take and the amount of space needed (Office SharePoint Server)
Applies To: Office SharePoint Server 2007
This Office product will reach end of support on October 10, 2017. To stay supported, you will need to upgrade. For more information, see , Resources to help you upgrade your Office 2007 servers and clients.
Topic Last Modified: 2016-11-14
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. For example, sites based on Microsoft® Windows® SharePoint® Services 2.0 can be upgraded much faster than personal or portal sites based on Microsoft Office SharePoint Portal Server 2003; this is because the upgrade process for Windows SharePoint Services 2.0 sites has fewer steps than the upgrade process for SharePoint Portal Server 2003 personal or portal sites. 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 (Office SharePoint Server).
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 Office SharePoint Server: 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. For example, one internal portal site here at Microsoft included a root portal site in SharePoint Portal Server 2003 that had 400 gigabytes (GB) of data in its database. The IT group estimated that 1.2 terabytes (TB) of database space was needed to run the gradual upgrade process. 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.
If you are using shared services, you also need to have space for approximately two times your indexes. This is because, during a gradual upgrade with shared services, you will be indexing twice — from both the previous version and the new version.
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.
The search indexes. In a gradual upgrade, you may have two search crawls running at the same time.
For more information about how disk space is used during a gradual upgrade, see How the upgrade process works (Office SharePoint Server).
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 or a lot of personalized sites, 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).
Post-upgrade steps:
Verifying sites and making changes or reverting to template Allow enough time for users to validate their sites after the upgrade. This may take several days. For more information, see Review upgraded sites (Office SharePoint Server).
Creating the Shared Services Provider (SSP) This step only applies during a database migration (in either an in-place or a gradual upgrade, the SSP is created as part of the upgrade process). Creating an SSP can take from 10 to 20 minutes; however, if you need to contact a database administrator to pre-create the databases for you, you might need a day or two of lead time.
Importing profiles after upgrade This step can take several hours to a day for large organizations (for example, more than 1,000 profiles).
Running a people crawl For large organizations, this step can take more than 24 hours.
Running a search crawl on all content For large sites, this step can take more than 24 hours.
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 2003 and 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. However, content databases containing portal sites are often much larger than that (for example, 200 GB). If you have a portal site with many large areas, it cannot be split up in SharePoint Portal Server 2003 and you must upgrade it all at the same time.
Note
If you have content databases that are larger than 100 GB but comprise team sites or MySites rather than portal sites, 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.
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).
Warning
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.
Download this book
This topic is included in the following downloadable book for easier reading and printing:
See the full list of available books at Downloadable content for Office SharePoint Server 2007.