s customers start to migrate from their existing SharePoint Portal Server 2003 (SPS2003) installations to the new version of SharePoint—Microsoft Office SharePoint Server 2007 (MOSS 2007)—one of the critical and daunting tasks they face is the process of upgrading applications and custom code from SPS 2003 to MOSS 2007.

Microsoft provides tool-based support for upgrading from SPS2003 to MOSS 2007. Like all automated tools (such as the VB to .NET Migration Wizard for example) this one is not a magic bullet. Depending on the customizations and custom extensions added to a particular SharePoint installation, the upgrade tool’s performance varies. Fortunately, Microsoft also provides a Pre-Scan tool that can provide warnings on areas that may cause the upgrade process to fail. As shown in Figure 1, the upgrade process itself generally involves four steps:

Figure 1. Upgrade Process: These are the four critical steps to follow when upgrading from SPS2003 to MOSS 2007.

1. Check for Service Pack 2
2. Pre-Scan & Analysis
3. Choose Approach
4. Execute the Upgrade

Each step is discussed in more detail in the following sections.

Check for Service Pack 2
The first step is to check whether SPS2003 Service Pack 2 (SP2) is installed. If it’s not, the upgrade tools provided by Microsoft will not work. Therefore, you should ensure that the installation of SharePoint you are planning to upgrade has SP2 installed.

To check for SP2:

1. Open Control Panel ? Add/Remove Programs
2. Select the entry for “Microsoft Office SharePoint Portal Server 2003” or “Microsoft Windows SharePoint Services 2.0”
3. Click the “Click here for Support Information” link.

Following the above procedure will reveal the Version Number for SPS2003 or Windows SharePoint Services (WSS). Using that version number, you can determine whether SP2 is installed. Table 1 lists the various applications and their corresponding version numbers. The highlighted rows show the version numbers for both products when SP2 has been applied.

When you’re sure SP2 has been applied to your installation, you’ll be able to use the upgrade tools.

Pre-Scan and Analysis Tool
The Pre-Scan Tool is an assessment and reporting tool that provides feedback on the upgrade process based on the specific SharePoint instance. You can download the tool from Microsoft.

You must run the Pre-Scan tool against an existing SharePoint instance. Although running the Pre-Scan process appears to be an optional step, it’s not. Instead, it’s a required prerequisite before you can execute the actual upgrade. The Pre-Scan process scans the sites and flags the database to indicate that the scan has been completed. Later, the upgrade process (psconfig.exe) uses the information collected during the Pre-Scan process.

If you try to run the upgrade process without running the Pre-Scan, you’ll get an error message stating that the Pre-Scan needs to be performed before the Upgrade process can continue.

During the scan, the Pre-Scan tool reports on these elements:

• Custom Web Parts: Pre-Scan detects and reports the existence of any custom Web Parts.
• Orphaned Objects: Finds objects that have become orphans, for example, a list that exists in the database but is not linked to any site.
• Sites using customized site templates: This is for user reference, so that the user can verify the customizations after the upgrade process has been executed. For more information on upgrading custom templates please refer to the documentation.
• Sites based on custom site definitions: This is for user reference as well.
• Sites based on specific languages: Informs the user that a specific language pack needs to be installed.
• Unghosted Pages: Pre-Scan provides a list of unghosted pages along with their URLs.

It is important to understand that this list merely provides a good starting point; there is always a possibility that the upgrade process may encounter other issues that Pre-Scan failed to find.

Pre-Scan is a command line tool. To execute it, use one of the following commands:

   PRESCAN /ALL    (Or)   PRESCAN /c preupgradescanconfig.xml /all   

The second option accepts a specialized XML file (preupgradescanconfig.xml in the example) as a parameter. Use that option when you want to exclude sites based on custom site templates (.STP files) from the Pre-Scan reports.

Pre-Scan generates the following three files as output:

• Pre-Scan Log (Text File): This file logs the time when the scan was performed.
• Pre-Upgrade Report Log (Text File): This file contains the checks performed and the issues detected. Figure 2 illustrates a sample log.
• Pre-Upgrade Report Summary (XML File): Figure 3 shows a sample summary report.

Figure 2. Sample Pre-Upgrade Report Log: In this report, you can see the checks the Pre-Scan tool performed and any issues that were detected.

Figure 3. Sample Pre-Upgrade Report Summary: Here’s an example of the XML-formatted summary report.

Using the Pre-Scan reports, you can take the appropriate actions to rectify any reported issues and then select a migration approach, but first you need to ensure that your current hardware will run the upgrade, and you should backup your system.

Verify Hardware Requirements and Back Up
You have multiple options when upgrading from SPS2003 to MOSS 2007, but before you attempt to execute any of them, you should be aware that while it may be possible to run MOSS 2007 on your current hardware, the system requirements for MOSS 2007 are higher than those for SPS2003. Therefore, you should check to ensure your current hardware meets the MOSS 2007 system requirements. To do that, download the system requirements for MOSS 2007 and compare your system specifications against those requirements.

You should also backup your existing SharePoint system and make a test of the backup to ensure that it works. That way, you can go back to the existing version if the upgrade process fails or corrupts the existing instance for some unpredictable reason. I recommend that you follow the procedures described in the TechNet article “SharePoint 2003 Disaster Recovery“

Approach Options
After verifying your system requirements and performing a backup, you can select one of the approaches available for performing the upgrade described below.

In-Place Upgrade
This approach is recommended by Microsoft for single-server or small farm environments that do not have customizations. Using this approach, the upgrade process migrates your existing SharePoint installation directly to MOSS 2007, retaining the original URLs. The existing SPS2003 installation will be down while the upgrade process is running. After the upgrade has completed, there is no option to roll back to the original using this upgrade approach. Therefore, in most cases, you should avoid this approach, because other MOSS 2007 upgrade approaches provide a rollback facility. If any problems occur using this approach, you’d have to manually restore your existing system from the backup.

Gradual Upgrade
This approach installs the new version side-by-side with the existing version on the same server, without affecting the existing SPS2003 installation. Using this approach, both versions are available for viewing and verification. If you find any problems with the upgrade, you have an option to rollback the changes.

The gradual upgrade approach is less risky, because the original installation is still available even after the upgrade completes; therefore, this is the recommended approach when you’re planning to use your existing hardware to run MOSS 2007.

Database Migration
This option is most useful when you want to install MOSS 2007 on a separate server farm and upgrade the existing content, in other words, when you’re deploying the new version on different hardware from your existing SPS 2003 installation. This is the lowest-risk option because it leaves the original SPS2003 installation untouched.

Other Upgrade Considerations
In addition to selecting one of the three approaches, consider performing a trial upgrade on a virtual machine by creating a mirror of your current installation. A trial upgrade gives you the most realistic perspective on what you can expect from the upgrade process.

Another important aspect to consider while performing the upgrade is that in many cases the upgraded code may no longer be the optimal way to carry out tasks in MOSS 2007. For example, SPS 2003 and WSS v2.0 do not support workflows out of the box. Any form of workflow must have been implemented through code in a custom Web Part, or custom ASP.NET application. MOSS 2007 and WSS 3.0, on the other hand, provide extensive workflow support out of the box, eliminating the need for custom code in scenarios where the included workflows may offer a good fit. Even in scenarios where the out-of-the-box workflows do not meet your needs, the new version’s integration with Workflow Foundation means that you can develop and deploy even complex workflows to SharePoint 2007, and they will work seamlessly.

While it is possible to register and use a v2 Web Part based on .NET Framework v1.1 in MOSS 2007, you may want to revisit the design of any custom functionality to evaluate how it maps into the MOSS 2007 world. If you decide to stick with existing custom Web Parts, you’ll need to deploy those manually onto the upgraded version. Deploying custom Web Parts is a not a huge task, but ensuring a successful installation generally involves manual steps.

Yet another aspect to consider is whether any upgraded code will continue to evolve. For example, if you know that there are feature updates planned for the custom Web Parts, it may add value to migrate the code from .NET v1.1 to .NET v2.0/v3.0, because MOSS 2007 is built on those two versions; therefore, code based on the newer versions can tap into the newer features.

MOSS 2007 does not support the concept of areas. Instead, all areas are upgraded to regular sub-sites. MOSS 2007 sports a new improved Site Directory. The upgrade process updates the SPS2003 Site Directory to the new version automatically. That’s also true for the “My Sites” functionality, which is also upgraded automatically to the newer version. The upgraded version of My Sites has features such as blogs, Colleagues and so on. (Colleagues is a new MOSS 2007 feature that automatically lists your manager, your peers, and your direct reports as your colleagues in a list, and also provides the facility to add ‘people you know‘ to that same list.)

If you select the gradual upgrade approach, you must explicitly select which personal sites should be upgraded.

The URLs for some resources have changed in MOSS 2007. For example: An SPS2003-based URL such as http://MyFirstSite/c12/DocLib would change to http://MyFirstSite/DocLib in MOSS 2007.

The upgrade process does not upgrade search indexes in any of the SPS2003 versions, which means you must run a full crawl of all the content after the upgrade. Further, search scopes and search groups are not upgraded at all.

One difficult decision when performing a gradual or an in-place upgrade concerns unghosted pages (pages that have FrontPage customizations). One option is to run the upgrade on these “as is.” Doing that results in these pages looking the same way as they did in WSS 2.0, but that decision means that newer features of MOSS 2007, such as Recycle bin or Workflows, will not be visible on those pages. The other option is to reset the pages to the site template. Resetting the template ensures that the sites will be upgraded to the new look and feel of MOSS 2007—but all customizations will be lost. If you select the latter option, specify the reghostonupgrade command line option for psconfig.exe as shown below:

   psconfig.exe -cmd upgrade -sidebyside -reghostonupgrade 

Choosing an Approach
The in-place approach is useful only for development and test environments, because it’s a high-risk option. There are various reasons why an upgrade may fail, and some of the reasons may be beyond the ability of the Pre-Scan tool’s prediction capability. An in-place upgrade could leave the environment in a mess with no option of built-in rollback. Therefore, this approach is not suitable for production upgrades unless you can support it with backups, and pre-testing on a mirror installation to ensure that the approach works.

The gradual upgrade process is the most flexible, because it allows you to upgrade one site collection at a time, in a step-by-step manner. At each step, the gradual approach lets you verify the upgrade by comparing it with the previous version. Furthermore, you can roll back to the original version if the upgrade results are unsatisfactory. This approach provides fine granularity and control; therefore, this is the approach that’s usually best for production instances. This approach would be most useful in SharePoint farms where the number of sites is high, or where sites are complex.

The database migration approach is best when you’re planning to deploy MOSS 2007 on a new farm with new hardware. You can’t use the gradual upgrade approach for a new farm; however, you can use the gradual upgrade process on the older farm, and then backup and restore the upgraded v3.0 databases onto the new farm. Using that combination, you can leverage the control and granularity provided by the gradual approach and still deploy on new hardware.

Performing the Upgrade
To use either the in-place upgrade or the gradual upgrade approaches, execute Setup.exe for SharePoint Server 2007 on the same server as the installed code base (SPS2003). Don’t forget to check for SP2, as discussed earlier. The setup installs the pre-requisites needed for MOSS 2007 such as ASP.NET 2.0 and the .NET Framework 3.0.

When you run Setup.exe on the same server that contains an SPS 2003 installation, you’ll see an upgrade dialog that provides you with a list of installation options (see Figure 4).

Figure 4. Installation Dialog: Here’s where you select how—or whether—you want to upgrade your existing installation as you install MOSS 2007.

Figure 5. URL Redirection: In this figure, the old version’s sites have been redirected to a temporary domain, while the new version retains the original URLs.

Choose the appropriate installation option based on the approach you’ve selected, and proceed with the installation. If you select the gradual upgrade option, you’ll need to create new host names or “URL Domains,” because the existing sites and the upgraded sites will run in side-by-side mode. Typically you’d move existing sites to a temporary URL domain and the upgraded sites would reside on the original URL domain. For example, if the existing sites are located at http://sps.mycompany.com, then you could create a temporary domain such as http://spsold.mycompany.com that would host the old version’s sites (see Figure 5).

Finally, you’re not forced to upgrade during the installation. You can elect to install MOSS 2007 and then perform the upgrade at a later point in time. If that’s your intent, choose the last choice, “No, do not upgrade at this time,” from the installation dialog shown in Figure 5. You can initiate the upgrade process later by executing psconfigui.exe from the following location:

   ":Program FilesCommon FilesMicrosoft SharedWeb server       extensions12BIN"

The “No, do not upgrade at this time option” is also useful in scenarios where you don’t plan to upgrade at all for some reason, but want MOSS 2007 installed side-by-side on the same box. After the installation completes, you can initiate the upgrade process from the SharePoint Central Administration Operations Tab.

Figure 6. Upgrade Sequence: This sequence of actions lets you select individual or groups of site collections to upgrade.

The Upgrade and Migration section (see Figure 6) under the Operations Tab provides information on the status of the upgrade process. To start the process, navigate to: http:///_Admin/SiteUpgrade.aspx.

Navigating to the SiteUpgrade.aspx page displays the existing Web applications available for upgrade in the “Site Content Upgrade Status Page” (see Figure 6). Clicking on the Begin Upgrade link requests you to enter details about the target web application to upgrade. Next, it displays the site collections within the web application that are available for upgrade. Select the site collections that you want to upgrade and click on the Upgrade Sites button. As you can see, the gradual upgrade process provides granular control over the entire process; it’s possible to upgrade one site collection at a time. After verifying the upgrade results you can then proceed to migrate the remaining site collections individually.

When you click the Upgrade Sites button, the process commences, displaying the status and progress details on the Web page as shown in Figure 6.

Figure 7. Rolling Back an Upgrade: This dialog lets you select a site collection to roll back.

As discussed earlier, one benefit of the gradual upgrade approach is that you can roll back changes if necessary. If you need to revert back to your original version, navigate to: http:///_admin/RevertUpgrade.aspx and select the specific site collection that you want to roll back. During the rollback process the site collection reverts to its original state (See Figure 7).

When you’re satisfied with the results of the upgrade, you can discard the rollback information by choosing to finalize the upgrade from the URL http:///_admin/FinalizeUpgrade.aspx. You can also remove the temporary URL host name after the sites have been upgraded successfully.

Database Migration Option
You probably noticed that the upgrade dialog in Figure 4 doesn’t offer the database migration option discussed earlier. The Database Migration process does not have the same level of UI support as the other two approaches; it requires some manual steps. A detailed explanation of the steps for this approach is beyond the scope of this article, but you can find more detailed information on TechNet.

However, in brief, you use SQL Server’s Backup and Restore feature to create a backup of the databases, then you restore those backups to the new server farm. After restoring the database you can then use the SharePoint stsadm.exe command-line tool to run the addcontentdb command to attach the content databases to the web applications. When you perform this step the upgrade process kicks in and upgrades the databases to the newer version. The upgrade process generates a log file that provides details about the results in the following location:

   "%ProgramFiles%Common FilesMicrosoft Shared      Web server extensions12LOGS"

At this point, you should have a solid grasp of the tasks involved to upgrade SPS2003 to MOSS 2007. Whichever upgrade option you decide to take, you’ll find the process will go more smoothly if you follow the guidance in this article.