Upgrade Overview

This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This page may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

You can upgrade an installation of Microsoft Windows SharePoint Services in two fundamental ways: Perform an automatic in-place upgrade or a gradual upgrade process. An in-place upgrade is a one-way process that directly modifies the database of the previous version. A gradual (or side-by-side) upgrade assumes both versions run simultaneously on the same computers, different databases exist for the two versions, and the data is upgraded in manageable chunks during outage windows.

In-Place Upgrade

An in-place upgrade replaces the previous code in a Web application with the code of the latest version, and manipulates the databases that were used with the previous version. The upgrade process is monolithic, meaning that until the upgrade is complete for databases, the SharePoint sites are unavailable.

An in-place upgrade executes a set of applicable upgrade actions on service instances and resources of the previous version, providing a one-way transformation to the current version. This upgrade updates the Internet Information Services (IIS) Web sites (Web applications) that run Windows SharePoint Services code, and modifies the databases and content of the previous version to work with the most recent SharePoint builds.

An in-place upgrade is used primarily for single-system or small-volume installations, and is recommended when there are no custom Web Parts added to the server farm, and where all the content can be upgraded over a period of days.

Gradual Upgrade

A gradual upgrade assumes that the previous and new versions of code run simultaneously on the same server, that a new database is created for the new version of Windows SharePoint Services during the upgrade process, that a number of sites are served by both application versions, and that the user is automatically directed to the proper domain after upgrade. The operator upgrades a number of site collections at a time to the new database and application version. The previous version data is maintained, and it is possible to revert any site collection to the pre-upgrade application and data. The gradual upgrade sequence is designed to minimize downtime, and depends on running the two versions side by side and defining a self-contained upgradeable subset of data.

The gradual upgrade sequence contains two phases. The initial phase needs to be completed in whole. It creates a new set of version 3 service instances and resources and populates the version 3 configuration database with entries for the old version 2 sites. Version 2 content is not upgraded during this phase. Requests for a remote site are redirected to the real URL and serviced by the old version. The second phase of the sequence upgrades and migrates a collection of site collections. The algorithm locks version 2 sites, copies them from the version 2 content database into a temporary database of the version 2 schema, and executes the set of applicable upgrade actions. It then copies the upgraded sites into the version 3 content databases. Requests to these upgraded sites are no longer redirected. This second phase is repeated until all site collections of the previous version are upgraded.

As a last step in the upgrade process, the administrator manually finalizes the upgrade operation to cut off any link between versions 2 and 3 when no further upgrades are required.

Build-to-Build and Version-to-Version Upgrades

Windows SharePoint Services supports two code paths for upgrade: version-to-version between different versions, or build-to-build for the same version. Build-to-build upgrades are always in-place because it is not possible to have different builds of the same server application version running on the same computer. Version-to-version upgrades may be in-place or gradual.

Upgrade Sequences

The Windows SharePoint Services upgrade infrastructure provides an extensible interface that you can implement in custom code to upgrade a specific resource or service instance of an application. The infrastructure provides the means to call upgrade code in a consistent and deterministic manner, in other words, as an upgrade sequence, meaning a logical chunk of upgrade code for a single resource.

Upgrade proceeds sequentially from higher-level upgradeable object to lower-level contained upgradeable object until an entire server farm has been upgraded. The upgrade process starts by upgrading the configuration database and SharePoint Central Administration, as well as data specific to each server in the farm, and then runs on each virtual server to upgrade each site collection until all Web sites in all the site collections of each virtual server are upgraded. Each version 2 virtual server is thereby upgraded one-by-one to a version 3 Web application, as are the content databases that support their site collections.

An upgrade sequence consists of one or more upgrade actions discovered at run time that need to be taken to upgrade a specific feature. Windows SharePoint Services accepts a resource instance or a set of resource instances, determines which upgrade sequences need to operate on the resources based on loaded assemblies that are specified in configuration files, and runs the sequences on the selected resources. The sequences are ordered according to the information specified in the configuration files.

Windows SharePoint Services upgrade is data-driven, which means that resources registered as upgradeable in the configuration database are upgraded in a specific order. Any resource instance that needs to be upgraded must be registered in the configuration database, in which there can be only one separate upgrade sequence per upgradeable resource instance. There may be upgrade sequences for Web applications (virtual servers), content databases, or shared services, and so on. An upgradeable object has built-in schema versioning, allows for provisioning of upgrade dependencies, and has properties that determine whether the current object needs to be upgraded and whether to upgrade it.

The upgrade infrastructure provides an interface definition for upgradeable objects that allows you to create custom code that upgrades a specific resource. Based on resources that need to be upgraded, you must define upgrade sequences (or plug-ins) that implement this interface so that your upgrade code can be called.

You can run upgrade sequences any number of times on a given server. An upgrade sequence must determine whether any action needs to be taken at any given time, and it must also, in case of errors, provide adequate check-pointing to allow you to resume upgrade from a certain point the next time you run the upgrade code. Upgrade sequences create logs and report errors and progress back to the user interface.