Features that existed in SharePoint Portal Server 2003 that are no longer in SharePoint Server 2007 include the following:

Features that have been updated or replaced with new features are illustrated in Table 22-2.

Elements that are not upgraded are the following:

Based on these changes and deprecations, what are the pre-upgrade tasks that you should perform so that you know your upgrade will be successful? What follows is an expanded answer to this question.

First, you’ll need to thoroughly understand your SharePoint Portal Server 2003 implementation. Most SharePoint Portal Server 2003 administrators are not fully dedicated to administrating their SharePoint Portal Server 2003 environment. Most have 10-15 other platforms that they are responsible to administrate, and SharePoint Portal Server 2003 is just one of the platforms on their radar screen. Document URL topologies, permissions, and other configurations as part of your pre-upgrade effort.

This is no small matter because the upgrade method you choose will be predicated, in part, on the final hardware platform on which you want SharePoint Server 2007 to run. Table 22-3 outlines your choices relative to the upgrade methods and the effects those choices will have.

For the vast majority of upgrade scenarios, we have found that administrators want to run their SharePoint Server 2007 implementation on new hardware. So, for those migration efforts that will use either the gradual or the in-place upgrade method, the SharePoint Portal Server 2003 farm will need to have been moved to the new hardware before the migration to SharePoint Server 2007 is commenced. In our estimation, it is easier to move SharePoint Portal Server 2003 to new hardware than it is to move SharePoint Server 2007 to new hardware. Best practice would be to run either the in-place upgrade or the gradual upgrade on the best hardware possible. To do this will mean moving your SharePoint Portal Server 2003 farm to new hardware first.

If you’ll be using either the in-place or gradual upgrade process, then you’ll be forced to upgrade to a 32-bit SharePoint Server 2007 platform. You can’t install a 64-bit SharePoint Portal Server 2003 version because it doesn’t exist. Without a 64-bit version of SharePoint Portal Server 2003, you will be forced to move to a 32-bit version of SharePoint Server 2007, and then upgrade from there to a 64-bit version.

If your migration plan calls for upgrading to a 64-bit version of SharePoint Server 2007 while using the in-place or gradual upgrade methods, then you’ll have to build into your plan an intervening 32-bit SharePoint Server 2007 platform that can be upgraded to 64-bit.

So, how do you do this? Use the following steps.

When considering the gradual upgrade process, remember that you’ll be forced to run on 32-bit hardware during the entire gradual upgrade until the entire set of site collections has been moved over to the SharePoint Server 2007 implementation. Only thereafter will you be able to introduce 64-bit servers into your SharePoint Server 2007 environment.

What we’re referring to is the answer to the question, "Where does information reside in the farm?" In our experience, the vast majority of our customers did not like their URL topology and found that their first attempt at deciding where information would reside was largely a negative experience. Many were led astray by consultants who seriously didn’t know what they were doing. We’ve run into implementations that placed all of the site collections under the sites managed path in a single portal. Others had not turned on Shared Services (SS) across multiple portals and were now facing the prospect of moving multiple indexes and sets of My Sites to a single Shared Services Provider (SSP). And others had turned users loose with Self-Service Site Creation only to find that site collections were created under the wrong wildcard-managed paths. One customer was even advised to use a single site collection for all of his collaboration activities enterprise-wide.

These and other mistakes about the information architecture occurred because governance rules were not in place and a well-thought-out information architecture was not created. Thus precious little structure existed that could inform users about where information was supposed to reside.

So, what many administrators and business stakeholders want is to leave behind the unstructured misery while moving information to the new SharePoint Server 2007 platform in such a way that everyone in the organization understands where information is supposed to reside and how it is supposed to be managed. Understanding who the content owners are and who makes overriding information architecture decisions is also foundational to not recreating the same taxonomy misery in SharePoint Server 2007.

When considering a migration to SharePoint Server 2007 from SharePoint Portal Server 2003 that requires the movement of data between site collections and, perhaps, Web applications, it is important to note that all three of the Microsoft migration methods will migrate your information architecture misery intact. The only migration method that will allow the movement of content from an existing URL topology to a new URL topology will be the user copy method.

Now, it can rightly be argued that after the information is migrated to SharePoint Server 2007, that you can use stsadm –export/-import commands to move sites and site collections around the farm. This is true and is the advertised way to move information. However, we see little reason to place this burden on the administrators and specially trained end-users. It is more efficient, in the long run, to have the users copy the information over to the correct locations and eliminate the movement of information between URLs.

Also, the user copy method provides the highest degree of URL flexibility in the SharePoint Server 2007 farm. All of the other three methods require the use of the old URLs from the SharePoint Portal Server 2003 farm, either at the farm level (in-place and gradual) or at the database level (content database). The user copy method allows you to create an entirely new set of URLs that isn’t dependent in any way on the SharePoint Portal Server 2003 implementation. The tedious part might be mapping the old URLs to the new URLs, but this is a small cost compared to redoing your information architecture after the upgrade has been completed.

No matter which migration method you choose, there will be a need to communicate outages, downtime, training opportunities, and other unforeseen changes in the migration plan. Communication will be necessary to ensure that users and management are not unprepared by both anticipated and unforeseen events.

It might sound silly, but even anticipated, planned-for events can catch key stakeholders off guard because they either didn’t record it in their calendars or they "just forgot." Communication can go a long way toward mitigating the negative effects of surprises and help keep everyone moving in the same direction for the migration.

Prescan.exe (Figure 22-2) needs to be run on your databases immediately before each upgrade action to ensure that any problems with your databases are found and fixed before the migration starts. Prescan is a command-line utility that you’ll be prompted to run by the upgrade software if you’ve not already run it on your databases. Especially in the gradual and content database upgrade methods, you’ll want to run prescan.exe before each site collection or database is upgraded. If you don’t do this, chances are nearly 100 percent that your upgrade will fail.

Figure 22-2. Prescan command-line tool being run on a SharePoint Portal Server 2003 implementation

How many times has it been suggested that an administrator first obtain and then test her backups before proceeding with an upgrade of content to a new platform? The answer is more than any of us can count. But we’re not kidding. Before you embark on your upgrade plans, you first need to test your SharePoint Portal Server 2003 farm backup and restore procedures as well as your SQL backup and restore procedures. Be sure that you understand how to restore the entire SharePoint Portal Server 2003 farm from scratch so that you can revert back to your SharePoint Portal Server 2003 farm if needed. Because of the way the databases are altered during the in-place and gradual upgrade process, the chances are good that if the process fails at some point, you’ll need to restore your SharePoint Portal Server 2003 farm to its original state.

When you perform a gradual upgrade, the information that is being upgraded during the upgrade process is copied from the SharePoint Portal Server 2003 database into a temporary database and then upgraded within that database. Thereafter, it is copied from the temporary database to the SharePoint Server 2007 database. This means that you’ll have three database sets involved in the upgrade of information along with three transaction log sets. Be sure that you have enough SQL disk space to hold the same information in those databases and transaction log sets during the upgrade process.

Figure 22-3 shows the SQL Server database list during a gradual upgrade of a portal and its personal sites. As the portal is upgraded, the following three databases are involved:

Figure 22-3. Illustration of the three databases needed during a gradual upgrade of content

An orphaned object is an entry in one SQL database table that points to a nonexistent entry in another SQL database table. The most common orphan occurs when there is an entry for a site in the configuration database sites table but no corresponding site entry in the content database sites table. Windows SharePoint Services v2 SP2 contained two fixes to prevent orphans and contains an update to stsadm.exe, which you can use to clean orphans from the database. You may notice that you have orphans if stsadm -o restore fails to restore the site, even with the -overwrite option when you know the URL exists or stsadm -o deletesite fails to delete the site.

The upgrade process will heavily tax your processor, memory, and hard disk subsystems. Some long-running processes could fail if the default Web site and ASP.NET timeouts are left unchanged. In order to avoid this, we suggest that you increase the Web sites’ connection timeout on the Web Site tab to 65,000 seconds. In addition, you should increase the ASP.NET runtime timeout. This can be specified at the machine, site, application, and subdirectory levels, which is found after the <httpRuntime> element in your machine.config or web.config files.

When we talk about broken links, we’re referring to links that are embedded within a document that link to another URL location with your current SharePoint Portal Server 2003 farm. Most, if not all, of these links will be broken when you upgrade SharePoint Portal Server 2003 to SharePoint Server 2007. They will definitely be broken if you use the user copy method. In our experience of working with customers who are upgrading, nearly all report that their users must manually edit each document and redo the link(s) within each document.

For those who have a high number of links embedded within their documents, this could represent a significant effort on the part of the users. Best practice is to plan for it and train your users on how to perform this action. You might have to put up with some complaining and push back. But coding a script to find all of the links and redoing them within the documents after they have been moved to SharePoint Server 2007 would be difficult and time consuming. Consider this one of the pain points of a SharePoint Portal Server 2003 to SharePoint Server 2007 migration. There isn’t much else you can do.

The default setting for increasing a transaction log file size in SQL is 10 percent. It is best practice that you change this setting during the upgrade process. Specifically, it is best practice to minimize the growth of the transaction log by setting the database(s) to use the simple recovery method and then to increase the growth of the transaction log by 100–500 MB, not by a percentage. What we have seen in the field is that those who leave this setting at a percentage find that, as the transaction log file size grows, the time required to increase the log file size lengthens. Some have experienced timeout errors because the increase of the transaction log took longer than the timeout limits in IIS. Increasing the IIS timeout settings will help, but changing the increase method to a set number of megabytes will ensure that the transaction log increase will not take longer than your timeout settings. Using the simple recovery method will write the data to the databases immediately after they have been committed to the transaction log. Sections of the transaction log will be re-used once the committed transactions are written to the database. Remember that the simple recovery method limits your restore of the database to the last backup of the database. After the upgrade process is completed, be sure to reset the values to the defaults or to other values that you have determined are best for your SQL and SharePoint environment.