How the upgrade process works (Windows SharePoint Services)
Applies To: Windows SharePoint Services 3.0
Topic Last Modified: 2007-12-18
In this article:
In-place upgrade
Gradual upgrade
How URL redirects are handled during gradual upgrade
You can choose among three upgrade approaches: in-place, gradual, and database migration. An in-place upgrade is used to upgrade all Microsoft® SharePoint® sites at one time, which is best suited for single server or small deployments. A gradual upgrade allows finer control of the upgrade process by allowing one or more site collections to be upgraded at a time. Both in-place and gradual upgrades take place on the same hardware on which your previous version is installed. A database migration allows you to move your content to a new farm or new hardware.
Tip
For larger deployments, a gradual upgrade is a better option than an in-place upgrade because it enables the administrator performing the upgrade to control how many site collections to upgrade at one time. In this way, large deployments can be upgraded gradually over several weekends while continuing to host the previous version sites. This is possible because you can continue to host the sites that have not yet been upgraded on the same server as the upgraded sites.
In an in-place upgrade:
The previous version is overwritten with the new version, and the content databases are changed. Because of this, an in-place upgrade is not a reversible process — that is, you cannot roll back to the previous version.
The original sites are upgraded in place, and you cannot view the previous versions of the sites after upgrade.
All sites are unavailable to site visitors during upgrade. The period during which the sites are unavailable is the full time it takes to upgrade the entire server or server farm.
Site visitors continue to use the same URLs after upgrade.
In a gradual upgrade:
As each group of site collections is upgraded, the upgrade process copies the data in them from the original database to a new database before upgrading the data. The original data is maintained in the original database until explicitly deleted by the server administrator. Because of this, upgraded sites can be easily rolled back to the previous version if necessary.
Most sites are available to site visitors during the upgrade; only those site collections that are currently being upgraded are offline. (Note that the previous version sites are marked as updates only after they have been copied in preparation for upgrade.)
The upgrade impact is limited to only those users who need the site or sites being upgraded.
After upgrade, the original URLs point to the upgraded version of the sites. This way, users can continue to use the same URLs they used before the upgrade.
A database migration is essentially an in-place upgrade that you perform on a copy of the content. In a database migration:
You copy all databases except for the configuration database, and then add the databases to a new stand-alone or server farm installation.
When you attach the databases to the new server farm, the upgrade process runs and upgrades the data in place.
Important
Because of the downtime, and the risk that upgrade may take longer than expected or that some sites may need some rework after upgrade, it is critical that the server administrator communicate with site owners and users about what to expect during the process. For more information, see Create communication plan (Windows SharePoint Services).
In-place upgrade
An in-place upgrade takes place on the same hardware as your previous version installation. When you run an in-place upgrade, the process upgrades your entire installation in a pre-set sequence. The following steps explain what happens as the in-place upgrade process runs:
After performing all pre-upgrade steps, the server administrator installs Windows SharePoint Services 3.0 to the server running the previous version of Windows SharePoint Services and chooses In-place Upgrade.
The upgrade process runs and upgrades the configuration database and the Central Administration site.
The upgrade process runs on each virtual server and upgrades each site collection in that virtual server.
After all sites have been upgraded, the upgrade process ends.
Repeat the upgrade action on each server in a server farm environment.
The administrator confirms that upgrade is complete and then uninstalls the previous version of Windows SharePoint Services.
Gradual upgrade
Similar to an in-place upgrade, a gradual upgrade takes place on the same hardware that is used for your previous version installation. However, a gradual upgrade allows you to control when upgrade takes place for each individual site collection, and it also allows you to continue running the previous version and the new version side by side on that hardware. When you perform a gradual upgrade, the starting and ending topologies have the same configuration, similar to an in-place upgrade except for the following differences:
During and after upgrade, the front-end Web servers run both Windows SharePoint Services 2.0 and Windows SharePoint Services 3.0. Any upgraded site collections run under Windows SharePoint Services 3.0, whereas site collections that could not be upgraded or that were not selected for upgrade continue to run under Windows SharePoint Services 2.0.
Note
Scenarios in which you may not want to upgrade sites include: you may need to keep some sites in the previous version until a needed language pack is available for Windows SharePoint Services 3.0, or you may need to wait for a new custom site definition to be created.
During and after upgrade, both the Windows SharePoint Services 2.0 and the Windows SharePoint Services 3.0 databases are available. Content for upgraded sites is stored in the Windows SharePoint Services 3.0 databases; content for sites that could not be upgraded or that need to remain as they were continue to be stored in the Windows SharePoint Services 2.0 databases. Configuration databases exist for both Windows SharePoint Services 3.0 and Windows SharePoint Services 2.0.
The following figure illustrates the gradual upgrade process:
.gif "Topology in transition during upgrade")
The following steps correspond to the callout numbers in the preceding figure and explain what happens as the gradual upgrade process runs.
After performing all pre-upgrade steps, the server administrator installs Windows SharePoint Services 3.0 to the first front-end Web server in the farm and then chooses Gradual Upgrade.
Note
It is recommended that you back up your environment before running the upgrade. For more information, see Run and test a full backup in SQL Server (Windows SharePoint Services).
The upgrade process creates a Windows SharePoint Services 3.0 Web application to host SharePoint Central Administration, and the Central Administration site is created.
The upgrade process creates a new configuration database to store configuration data for Windows SharePoint Services 3.0. Configuration data from the Windows SharePoint Services 2.0 configuration database is copied into the new database.
The administrator selects a virtual server to upgrade and specifies the target Web application. The upgrade process creates the target Web application and adds any Web Parts deployed to the Windows SharePoint Services 2.0 virtual server to the new Web application.
The upgrade process creates a temporary content database for each content database that exists in the previous version. The upgrade process copies the site list from Windows SharePoint Services 2.0 into the new environment. The administrator selects the site collections to upgrade. The upgrade process copies the data for those sites into the temporary content database, and then upgrades those sites in that temporary content database. Each site is temporarily unavailable while being copied into the temporary content database.
After the content has been upgraded, the upgrade process moves the data to the Windows SharePoint Services 3.0 content database and then deletes the temporary content database.
At the end of the upgrade process, Windows SharePoint Services 2.0 and Windows SharePoint Services 3.0 are both running and available. After all sites have been upgraded, the administrator confirms that upgrade is complete. If Windows SharePoint Services 2.0 is no longer needed, the administrator uninstalls Windows SharePoint Services 2.0.
How URL redirects are handled during gradual upgrade
Two sites cannot share the same URL. Therefore, during a gradual upgrade, when you have both the old version and the new version of each site, you need two different domain URLs for each site (for example, http://company_name/sites/SiteA and http://company_name_old/sites/SiteA). During upgrade, a temporary domain URL is needed to host the original previous version sites. The new version takes over the domain URL that points to the content prior to upgrade, and user requests will be routed to their content whether or not it has been upgraded. The following process occurs during upgrade to make this redirection possible:
Before you begin the upgrade, create a temporary URL domain for your previous version sites.
When you run the upgrade, the upgrade process will ask you for the domain you specified above. The process moves the previous version site to the temporary URL domain, and the new version site takes over the original URL domain.
A redirect is created automatically for each site collection to send requests for the original URL to the old site until the site is upgraded.
After each site has been upgraded, the redirect for that site is dropped.
After all sites have been upgraded, and after you have deleted all of the old sites and completed the upgrade process, you can manually remove the temporary URL domain from the Domain Name System (DNS).
During this process, browse access to the original URL always works. However, certain client applications (such as Microsoft Office client applications) cannot use these types of redirects. Before a site is upgraded, the original URL points to the previous version; after a site has been upgraded, the original URL points to the new version.
The following table illustrates how the URLs work during gradual upgrade.
| Stage | Original site URL | Upgraded site URL | Notes |
|---|---|---|---|
Before upgrade |
http://company_name /sites/SiteA |
n/a |
The server administrator creates http://company_name_old for use during gradual upgrade. |
During upgrade |
http://company_name_old /sites/SiteA |
http://company_name /sites/SiteA |
Requests for http://company_name/sites /SiteA are redirected to http://company_name_old /sites/SiteA until it is upgraded. |
After upgrade |
http://company_name_old /sites/SiteA (until deleted) |
http://company_name /sites/SiteA |
The redirect is removed after upgrade is complete and the results are validated. |
Be aware that this URL redirection can cause hard-coded links within sites or documents to break. For example, Microsoft Office InfoPath® forms sometimes contain hard-coded links to a data location (such as a specific SharePoint list, Web service, or XML file). Because the link is hard-coded, it cannot be automatically updated to point to the temporary URL used for sites that have not yet been upgraded during a gradual upgrade. Use a trial upgrade to identify such issues before you begin your official upgrade process. That way, you can identify any sites that need to be upgraded quickly so that they can use the original URL again, and you can avoid the support calls that result from loss of functionality in forms or other items containing hard-coded links.
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 books for Windows SharePoint Services.