Understanding Your Upgrade Options

There are three approaches to upgrading a Windows SharePoint Services 2.0 implementation to Windows SharePoint Services 3.0:

• In-place upgrade

• Gradual upgrade

• Content database migration

An in-place upgrade is used to upgrade all SharePoint sites at once. This approach is the easiest and is best suited for single-server or small-volume deployments. A gradual upgrade installs Windows SharePoint Services 3.0 side by side with Windows SharePoint Services 2.0, and it allows you granular control of the upgrade process by allowing one or more site collections to be upgraded at a time. You also have the ability to revert the upgraded site back to a Windows SharePoint Services 2.0 Web site. Both in-place and gradual upgrades take place on the same hardware used by your Windows SharePoint Services 2.0 installation. A content database migration allows you to move your content to a new farm or onto new hardware, and therefore requires a greater number of servers to implement than the other two approaches. You could also use a database migration approach to gradually upgrade your Web sites to Windows SharePoint Services 3.0, keeping one set of servers-a Web farm-for Windows SharePoint Services 2.0 and a Web farm for Windows SharePoint Services 3.0.

Note 

For larger deployments, the gradual upgrade is a better option than in-place upgrade because it allows 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 time 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-Place Upgrade

Using the in-place upgrade option, the Windows SharePoint Services 2.0 implementation is upgraded in place (overwritten) with Windows SharePoint Services 3.0 and the SQL content databases are updated. Because of this, an in-place upgrade is an irreversible process; therefore, you should ensure that you have a tried and tested backup solution that you can use to restore the Windows SharePoint Services 2.0 solution.

The original sites are upgraded in-place, and you cannot view the previous versions of the sites after upgrade. This means you have no easy method of comparing or testing the upgraded Windows SharePoint Services 3.0 with the original Windows SharePoint Services 2.0 sites to verify that the upgrade process was successful. You have only your memory, documentation, or screen shots. If you use either the gradual or data migration approaches, you still have the Windows SharePoint Services 2.0 sites that you can use to verify that the upgrade process was successful.

Important 

Because you are using your existing implementation, you inherit the security settings of your Windows SharePoint Services 2.0 configuration. Therefore, ensure you review the security settings of your Web applications before the in-place upgrade process. For more information on this, see Chapter 14, "Information Security Polices."

The SharePoint Web sites are not available to site visitors during the upgrade process. The outage window for all users is the full time it takes to upgrade the entire server or server farm, plus the time required to check the results of the upgrade.

The advantage with this approach is that the site visitors continue to use the same URLs after upgrade. This approach is useful if you do not have another server available on which to install Windows SharePoint Services 3.0.

Gradual Upgrade

Using the gradual upgrade approach, Windows SharePoint Services 2.0 sites coexist with Windows SharePoint Services 3.0 sites on the same hardware until you are ready to uninstall the old version of the software. You can upgrade a site collection or a group of site collections one at a time. The upgrade process copies the data from the original SQL content database to a new SQL content database. The data in the new content database is then upgraded. The original data is maintained in the original database until explicitly deleted by the server administrator. Because of this, upgraded site collections can be easily rolled back to the previous version if necessary.

The gradual upgrade approach is best suited to organizations that want to stage the upgrade over a period of time either because of the time it will take to upgrade the Windows SharePoint Services 2.0 installation, because some feature (such as a language pack) is not yet available, or because they are waiting on some development work, such as a new site definition.

Most Windows SharePoint Services 2.0 sites are available to site visitors during the upgrade. Only site collections that are currently being upgraded to Windows SharePoint Services 3.0 are offline. (Note that the previous version sites are marked as updates only after they have been copied in preparation for upgrade.)

When the upgrade process is completed, 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.

Content Database Migration

Content database migration is also known as the advanced upgrade process because it is complex and requires many manual steps, especially if you want to retain the original URLs for the sites. It is like an in-place upgrade, performed on new hardware on a copy of the content, but it doesn't retain anything from your current installation other than the content itself. If your current hardware is outdated or your current farm has just out-grown the hardware, this might be a scenario to consider. You do not have to migrate all your content databases at the same time. Therefore, it is similar to a gradual upgrade with the unit of upgrade being a content database, which can contain one or more site collections. As with the gradual upgrade approach, you can choose to maintain both Windows SharePoint Services 2.0 and Windows SharePoint Services 3.0 deployments. However, in this approach, the two versions of the software product are on different hardware. In a content database migration, you perform the following tasks:

• Install Windows SharePoint Services 3.0 on a new standalone or server farm installation.

• Make a copy of all databases except for the configuration database to the Windows SharePoint Services 3.0 installation.

• Attach the databases to the Windows SharePoint Services 3.0 installation. This forces an upgrade process, which upgrades the data in place.

As in the gradual upgrade approach, the original data is untouched in the original databases. Because of this, you can quickly reinstate the Windows SharePoint Services 2.0 sites if necessary.

You must use the content database migration approach if you have a scalable hosting mode implementation, you have enabled an Active Directory directory service account creation, or you want to switch between 32-bit and 64-bit hardware.