Determine upgrade approach (SharePoint Foundation 2010)
Applies to: SharePoint Foundation 2010
Before you run any process to upgrade from Windows SharePoint Services 3.0 to Microsoft SharePoint Foundation 2010, you have to determine which upgrade approach to take. Use the information in this article to help compare the pros and cons for each approach and to review information about special cases that might influence your approach. In addition to the information in this article, be sure to read Review supported and unsupported upgrade paths (SharePoint Foundation 2010) to understand exactly which upgrade situations are valid and lead to successful upgrades.
Note
To perform an upgrade, you must have installed Windows SharePoint Services 3.0 with Service Pack 2 (SP2).
In this article:
Choose an upgrade approach
Special cases
Choose an upgrade approach
There are two basic approaches to upgrade: in-place and database attach. In addition, there are various techniques you can use to combine aspects of these basic approaches to mitigate downtime or potentially improve performance.
The following table compares the in-place and database attach approaches.
| Approach | Description | Pros | Cons |
|---|---|---|---|
In-place upgrade |
You can install SharePoint Foundation 2010 on the same hardware. You can also upgrade the content and settings in the server farm as part of a single process. |
Farm-wide settings are preserved and upgraded. Customizations are available in the environment after the upgrade, although manual steps may be required to upgrade or rework them. |
Servers and farms are offline while the upgrade is in progress. The upgrade proceeds continuously. Consequently, you must allocate enough time for all content to be upgraded in sequence. |
Database attach upgrade |
You can upgrade the content for the environment on a separate farm. The result is that you do not upgrade any of the services or farm settings. You can upgrade the databases in any order and upgrade several databases at the same time. While each database is being upgraded, the content in that database is not available to users. |
You can upgrade multiple content databases at the same time, which results in faster upgrade times overall than an in-place upgrade. You can use a database attach upgrade to combine multiple farms into one farm. |
The server and farm settings are not upgraded. You must manually transfer settings that you want to preserve from the old farm to the new farm. Any customizations must also be transferred to the new farm manually. Any missing customizations may cause unintended losses of functionality or user experience issues. Copying databases over a network takes time and bandwidth. You must plan for that. You need direct access to the database servers. |
For more information about how in-place and database attach upgrades work, see Upgrade process overview (SharePoint Foundation 2010).
The following table lists the downtime mitigation techniques that you can use during upgrade to reduce the amount of time that users cannot access their content or to potentially increase upgrade performance.
| Technique | Description | Pros | Cons |
|---|---|---|---|
Parallel upgrade |
You can attach and upgrade multiple databases at a time to speed up the upgrade process overall. The maximum number of parallel upgrades depends on your hardware. This technique works for either in-place or database attach upgrades. |
Faster upgrade times for your overall environment. |
This is a manual process that requires additional steps and monitoring. |
Hybrid approach 1: Database attach with read-only databases |
Lets you continue to provide read-only access to content during the upgrade process. For this approach, you set the databases to read-only while the upgrade is in progress on another farm. This method reduces perceived downtime for your users. |
The existing farm can continue to host non-upgraded sites (in read-only mode) while you upgrade the content. As a result, there is minimal downtime for users. You can upgrade multiple content databases at the same time, which results in faster upgrade times overall than an in-place upgrade. You can upgrade hardware in addition to software. |
The server and farm settings are not upgraded. You must manually transfer settings that you want to preserve from the old farm to the new farm. Any customizations must also be transferred and upgraded manually. Any missing customizations may cause unintended losses of functionality or user experience issues. Copying databases over a network takes time and bandwidth. You must plan for that. You need direct access to the database servers. |
Hybrid approach 2: In-place upgrade with detached databases |
Lets you take advantage of an in-place upgrade's ability to upgrade content and settings, while adding the speed of a database attach upgrade. For this approach, you use an in-place upgrade to upgrade the farm and settings, and to detach and upgrade multiple databases in parallel (on the same farm or a separate farm). |
Farmwide settings can be preserved and upgraded. Customizations are available in the environment after upgrade, although manual steps may be required to upgrade or rework them. You can upgrade multiple content databases at the same time, which results in faster upgrade times overall than an in-place upgrade. |
Copying databases over a network takes time and bandwidth. You must plan for that. You need direct access to the database servers. |
Be aware that you can also combine these techniques. For example, you can set your original farm to read-only mode, create a copy of the farm and upgrade it without the content databases, use parallel upgrade to rapidly upgrade all the user content, and then finally switch users to the new farm after upgrade is completed. For more information about these downtime mitigation techniques work, see Upgrade process overview (SharePoint Foundation 2010).
Another option to consider if you are facing an overly long outage window is to use Alternate Access Mapping URL Redirection with a database attach approach, so that you temporarily redirect users to an existing farm while you upgrade the content on a new farm. This is an advanced method and should not be used unless other downtime mitigation techniques are not sufficient. For more information, see Using AAM URL redirection as part of the upgrade process (SharePoint Foundation 2010) (white paper).
Special cases
You might have other requirements or additional goals that you want to achieve when you perform an upgrade. The following table lists special cases and describes which upgrade approach is appropriate for each case.
| Case | Upgrade approach |
|---|---|
Upgrading a stand-alone installation with Windows Internal Database? |
If you are running Windows SharePoint Services 3.0 on a stand-alone server with Windows Internal Database, your database will be migrated to SQL Server Express as part of the in-place upgrade process. If your database is larger than 4 GB, you must configure Remote BLOB Storage to store some of the data. For more information, see Upgrade a stand-alone installation by using RBS (in-place) (SharePoint Foundation 2010). |
Upgrading from a 32-bit to a 64-bit edition of SQL Server? |
If you are running a 32-bit edition of SQL Server, you must migrate to a 64-bit edition. We recommend that you perform this migration before you upgrade to SharePoint Foundation 2010 to ensure best performance benefits. Ensure that you perform only one kind of upgrade or migration at a time to avoid upgrade failure. For more information, see Migrate an existing server farm to a 64-bit environment (Windows SharePoint Services 3.0). The following are two options for upgrading from a 32-bit to a 64-bit edition of SQL Server:
Note If you upgrade a SQL Server version — for example, from SQL Server 2005 SP2 to SQL Server 2008 — you can perform this upgrade before, during, or after you upgrade from a 32-bit to a 64-bit edition of SQL Server. |
Upgrading from Windows Server 2003 to Windows Server 2008? |
Upgrade the operating system before you attempt to upgrade to SharePoint Foundation 2010. If you are running Windows SharePoint Services 3.0, you must perform specific steps to upgrade to Windows Server 2008. For more information, see Upgrading to Windows Server 2008 for Windows SharePoint Services 3.0 with SP1. |
Upgrading from a 32-bit operating system to a 64-bit operating system? |
If you are using a 32-bit operating system, you must migrate to a 64-bit operating system before you upgrade. For more information, see Migrate an existing server farm to a 64-bit environment (Windows SharePoint Services 3.0). |
Upgrading an environment that uses forms-based authentication? |
Additional steps are required to upgrade when you are using forms-based authentication. For more information, see Configure forms-based authentication for a claims-based Web application (SharePoint Foundation 2010). |
Upgrading very large databases? |
In general, very large databases — particularly databases that have a large number or large size of document versions inside them — take longer to upgrade than smaller databases. However, the complexity of the data determines how long it takes to upgrade, not the size of the database itself. If the upgrade process times out, it is usually because of connection issues. In Windows SharePoint Services 3.0, the upgrade process often timed out because of the time needed to execute a process, but this is rarely the case with SharePoint Foundation 2010. For more information about how long upgrade might take for your environment, see Estimate how long the upgrade process will take and the space that you need (SharePoint Foundation 2010). |
Upgrading databases with a large number of site collections? |
If you have 5,000 or more site collections in a database, consider breaking them out into multiple databases. In Windows SharePoint Services 3.0, there was a default warning at 9,000 site collections and a hard limit at 15,000 site collections. In SharePoint Foundation 2010, these values change to 2,000 site collections for the warning and 5,000 site collections for the limit. To avoid errors during upgrade or broken sites after upgrade, we recommend that you move some site collections into separate databases. If you have multiple content databases, you can also speed up your upgrade process by upgrading multiple databases in parallel. For more information about moving site collections to a new database, see Move site collections to a new database (split a content database) (Windows SharePoint Services 3.0). |
Upgrading from Windows SharePoint Services 2.0? |
Use a database attach upgrade method to upgrade to Windows SharePoint Services 3.0, and then upgrade to SharePoint Foundation 2010. For more information about this upgrade process, see Upgrade from Windows SharePoint Services 2.0 to SharePoint Foundation 2010. |
Changing languages? |
You have two choices, depending on whether a single site or your entire environment is changing languages:
|
Using internationalized domain names? |
Although Windows SharePoint Services 3.0 supported internationalized domain names (IDNs), SharePoint Foundation 2010 does not. If you currently use IDNs with Windows SharePoint Services 3.0 and you plan to upgrade or migrate to SharePoint Foundation 2010, you must stop using IDNs, delete any IDN settings, and set up a non-IDN environment before doing so. For more information, see Plan for multilingual sites (SharePoint Foundation 2010). |
See Also
Other Resources
Downloadable book: Upgrading to SharePoint Foundation 2010
Resource Center: Upgrade and Migration for SharePoint Foundation 2010