Determine upgrade approach (SharePoint Server 2010)

Artykuł
07/22/2014

Applies to: SharePoint Server 2010

Before you run any process to upgrade from Microsoft Office SharePoint Server 2007 to Microsoft SharePoint Server 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 Server 2010) to understand exactly which upgrade situations are valid and lead to successful upgrades.

Note

To perform an upgrade, you must have installed Office SharePoint Server 2007 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 Server 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 Server 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.

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 Server 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 Server 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 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 Server 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 (Office SharePoint Server 2007). The following are two options for upgrading from a 32-bit to a 64-bit edition of SQL Server: You can back up the whole set of databases for the farm, perform the upgrade, and then restore the databases. (This option is supported and recommended because you will have a full backup, and after you restore the databases, you do not have to change anything within SharePoint Server 2010). You can move the SQL Server databases that you want to upgrade to a different 64-bit edition of SQL Server. You must add the different 64-bit edition, and then run a command to the computers running SharePoint Server 2010 to point them to the new 64-bit edition of SQL Server. (This option is supported but not recommended because it requires more work in SharePoint Server 2010 when, for example, the databases change location). 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 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 (Office SharePoint Server 2007).
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 Server 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 Office SharePoint Server 2007, the upgrade process often timed out because of the time needed to execute a process, but this is rarely the case with SharePoint Server 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 Server 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 Office SharePoint Server 2007, there was a default warning at 9,000 site collections and a hard limit at 15,000 site collections. In SharePoint Server 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 site collection limits, see SharePoint Server 2010 capacity management: Software boundaries and limits. For more information about moving site collections to a new database, see Move site collections to a new database (split a content database) (Office SharePoint Server 2007).
Upgrading from SharePoint Portal Server 2003?	Use a database attach upgrade method to upgrade to Microsoft Office SharePoint Server 2007, and then upgrade to SharePoint Server 2010. For more information about this upgrade process, see Upgrade from SharePoint Portal Server 2003 to SharePoint Server 2010.
Upgrading from Windows SharePoint Services 3.0?	Use the database attach upgrade approach to attach and upgrade the content databases from Windows SharePoint Services 3.0 to SharePoint Server 2010. This process upgrades the data in the content databases, but does not transfer any farm settings.
Upgrading Microsoft Office Forms Server 2007 to SharePoint Server 2010	Office Forms Server 2007 is no longer available for purchase. However, the capabilities of Office Forms Server 2007 have been integrated into SharePoint Server 2010. If you want to use forms, you must upgrade to SharePoint Server 2010 by using a database attach upgrade method. For more information, see Perform a database attach upgrade to SharePoint Server 2010 and Plan to upgrade form templates during an upgrade to SharePoint Server 2010. Note Before you upgrade Office Forms Server 2007, ensure that you have installed The 2007 Microsoft Office Servers Service Pack 2 (SP2) (https://go.microsoft.com/fwlink/p/?LinkId=192132).
Changing languages?	You have two choices, depending on whether a single site or your entire environment is changing languages: To change the language for a specific site, upgrade in the same language, and then install the new language pack and change to that language. Warning You must have the appropriate language packs installed to upgrade any sites based on a localized site definition. If you do not have the new language pack, the sites will not be accessible. Wait for the new language packs to be released before attempting to upgrade those sites. Also, you must have any language packs you used for Office SharePoint Server 2007 installed before you can perform an in-place upgrade. To change the installation language for your servers, use the database migration approach to migrate your data from the old version and language to the new version and language.
Using internationalized domain names?	Although Office SharePoint Server 2007 supported internationalized domain names (IDNs), SharePoint Server 2010 does not. If you currently use IDNs with Office SharePoint Server 2007 and you plan to upgrade or migrate to SharePoint Server 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 Server 2010).

Udostępnij za pośrednictwem

Determine upgrade approach (SharePoint Server 2010)

Choose an upgrade approach

Special cases

See Also

Other Resources

Dodatkowe zasoby