Upgrading from one platform to another is always a chore, but this chore has been made somewhat easier by the development of several migration paths from Microsoft Office SharePoint Portal Server 2003 to Microsoft Office SharePoint Server 2007. These paths provide different ways of migrating information from the old platform to the new. In addition, these paths have significant tradeoffs that we’ll discuss; you’ll find that no one path will be a perfect solution for you.
In our work with customers, we have found that roughly half of those who migrate don’t use any of the three migration methods given to them by the Office SharePoint Server 2007 product team. Instead, they simply stand up a new SharePoint Server 2007 farm and then instruct people on how to copy information from the old platform to the new platform. This is usually due to the customer’s dissatisfaction with their current 2003 implementation and the feeling that starting over is less painful than migrating and fixing the mistakes that they made in their Office SharePoint Portal Server 2003 implementation. In addition, SharePoint Server 2007 maps to technical requirements that SharePoint Portal Server 2003 never could. That’s why we advise our customers to plan their SharePoint Server 2007 installation first to meet new requirements, then figure out how to migrate the old content into it. Good examples are those organizations that architected SharePoint Portal Server 2003 taxonomies based on their organizational chart and therefore stove-piped their processes. We’re finding that many organizations let the old SharePoint Portal Server 2003 site die on the vine due to the pain of moving from a broken design. They leave it up to the users to migrate critical data to the new SharePoint Server 2007 implementation.
Most of the mistakes that customers report to us relate to their URL topology, where information was hosted within their SharePoint Portal Server 2003 implementation, and/or the poor navigation (SharePoint Portal Server 2003 areas) that was developed. Many who implemented SharePoint Portal Server 2003 liked the product and its features, but the vast majority of users with whom we have worked did not like how it was implemented in their environment. Based on this, they have a strong desire to start over in a fresh, new environment.
Unfortunately, all three of the Microsoft migration methods that were developed by the product team retain the information taxonomy that was implemented in SharePoint Portal Server 2003. While site collections and sites can be moved after they are upgraded to SharePoint Server 2007, the sheer number of sites and site collections that might need to be moved can outweigh the benefits of using one of the three migration methods. By contrast, the reason so many customers are selecting the user copy migration method (which is really just engaging the end-users to copy over their information from the SharePoint Portal Server 2003 platform to the SharePoint Server 2007 platform) is because this is often the easiest way in which a clean, new information taxonomy can be implemented in SharePoint Server 2007 while moving over the SharePoint Portal Server 2003 information using the least amount of effort.
In this chapter, we’ll discuss the best practices for the three Microsoft migration methods and also include the user copy method that we’ve seen adopted by customers more often than any of the other three methods. While the user copy method is not a product team–originated method, we feel it is selected often enough by customers that it warrants inclusion in this chapter.
Note
Because of the complexities introduced by migrations from one platform to another, this chapter will focus on the upgrade or migration path from SharePoint Portal Server 2003 to SharePoint Server 2007. We will not discuss upgrades from SharePoint Team Services to SharePoint Server 2007, Windows SharePoint Services to SharePoint Server 2007, or SharePoint Portal Server 2001 to SharePoint Server 2007.
More Info
For information on how to migrate from Windows SharePoint Services to SharePoint Server 2007, please consult the Microsoft SharePoint Products and Technologies Administrator’s Pocket Consultant (Microsoft Press, 2007).
There are four approaches to upgrading a SharePoint Portal Server 2003 implementation to SharePoint Server 2007. The same four approaches can be used to upgrade Windows SharePoint Services v2 to Windows SharePoint Services v3. The four upgrade approaches follow:
An in-place upgrade is used now for testing environments; Microsoft no longer recommends using the in-place upgrade in production environments. 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 used by your SharePoint Portal Server 2003 installation. A content database migration allows you to move content to a new farm or new hardware. It also upgrades one content database at a time. The user copy method allows you to stand up a new SharePoint Server 2007 farm on new hardware and have the end users copy over their SharePoint Portal Server 2003 content to SharePoint Server 2007.
During the in-place upgrade process, the SharePoint Portal Server 2003 implementation is upgraded in real time on the same hardware to SharePoint Server 2007. The SQL content databases are upgraded to a SharePoint Server 2007 platform and, as such, the in-place upgrade is irreversible. This is why it is a best practice to back up your SharePoint Portal Server 2003 farm in case the upgrade goes poorly and you need to restore SharePoint Portal Server 2003.
During the in-place upgrade, original sites are overwritten, so you cannot view the previous versions of the sites after upgrade. You have no way to check the differences between your previous SharePoint Portal Server 2003 Web sites and the new SharePoint Server 2007 Web sites. You have only your memory, documentation, and screenshots for reference.
Originally seen as the best approach for small or single-server environments, the in-place upgrade approach is now recommended only for development, testing, and staging environments in which you need a quick and dirty upgrade. Microsoft does not recommend performing in-place upgrades in production environments because the process may fail for various reasons outside its control; with no easy recovery procedure, it has caused problems for customers.
The in-place upgrade method requires the least amount of administrative effort. Once the pre-upgrade tasks have been completed, all you do is start setup.exe and then order some pizza and soda so you have something to do while the upgrade process runs. In addition, if you want or need to keep your SharePoint Server 2007 farm on the existing hardware on which your SharePoint Portal Server 2003 farm is running, this method will allow you to do this.
Another advantage of the in-place upgrade is that you don’t change the URLs for your content. After the upgrade is completed, the SharePoint Server 2007 farm will use the same URLs that your SharePoint Portal Server 2003 farm used.
There are three main disadvantages of doing the in-place upgrade. First, because the entire farm is upgraded at the same time, it is offline during the upgrade. For those environments where uptime is required, you may need to consider another alternative. If you have a large farm, the upgrade could take hours. We suggest that administrators plan on an upgrade of 10 GB/hour. So if you have 200 GB of data in your SharePoint Portal Server 2003 farm, it will likely require 20+ hours to conduct an in-place upgrade. This is the second disadvantage of an in-place upgrade: It can take hours to complete.
But what if the upgrade fails for some reason? Well, that leads us to our third disadvantage: There is no roll-back or revert-back process for the in-place upgrade method, so your only choice is to cleanse the SharePoint Portal Server 2003 servers of their farm and restore the entire farm before doing another in-place upgrade.
During the gradual upgrade approach, the SharePoint Server 2007 and SharePoint Portal Server 2003 platforms are both installed side by side on all servers in the SharePoint Portal Server 2003 farm. Once installed, upgrades occur on a site-collection-by-site-collection basis at the initiation of the administrator.
The gradual upgrade process copies the data from the original content database to a new content database. The data in the new content database is then upgraded. The original data is maintained in the original database until the server administrator explicitly deletes it. As a result, you can easily roll upgraded site collections back to the previous version if necessary.
Only those site collections currently being upgraded are offline. When the upgrade process is complete, the original URLs of the SharePoint Portal Server 2003 sites point to the upgraded version of the SharePoint Server 2007 sites. This way, users can continue using the same URLs they used before the upgrade.
The gradual upgrade method allows administrators to control how many site collections are upgraded at one time. This is a clean, methodical way for large deployments to be upgraded gradually over several weeks or months while continuing to host the sites that have not yet been upgraded.
Probably the biggest advantage of the gradual upgrade process is the granular level of control that you’ll enjoy because you’ll decide which site collections are upgraded at which time. This allows for a tighter project management plan that defines a training schedule and site customization schedule to coincide with the upgrade schedule. You can determine which groups to upgrade at which time and that they are genuinely ready for the upgrade and ensure that their unique customizations are ready for the upgrade as well.
Because you can upgrade disparate, smaller groups of users at different times, the total number of users affected by any single upgrade action can be controlled and predicted. In addition, the gradual upgrade process does not delete the SharePoint Portal Server 2003 sites, so you can revert the upgrade to the SharePoint Portal Server 2003 platform if needed. Finally, this upgrade method uses existing hardware, so you can achieve economies of scale with your server hardware.
Like all things in life, the gradual upgrade process has some disadvantages. First, your hardware needs to be able to run both the SharePoint Portal Server 2003 and the SharePoint Server 2007 platforms at the same time because the gradual upgrade process requires that the SharePoint Server 2007 bits be installed side by side with the SharePoint Portal Server 2003 bits on the same servers.
Second, you’ll need to create a set of URLs for the SharePoint Portal Server 2003 content that has not been upgraded to SharePoint Server 2007. The way the upgrade works is that current information sitting in SharePoint Portal Server 2003 that has not been upgraded to SharePoint Server 2007 will need a new, unique URL because the SharePoint Portal Server 2003 URLs will have been assigned to the new Web applications in the SharePoint Server 2007 farm. So, additional DNS work will be required; if you have a large farm with many Web applications, additional URL planning will be needed as well. Figure 22-1 illustrates the upgrade screen in which a new URL is entered for the old SharePoint Portal Server 2003 content.
Third, this method is hardware intensive. For pockets of time, you’ll have three different database sets in SQL for the same content. Factor in transaction logs, and you can see how SQL will require a lot of extra disk space and memory.
Content database migration is an in-place upgrade performed on a copy of the content databases for an individual Web application. In the content database migration method, all databases for a SharePoint Portal Server 2003 virtual server are copied to the new SQL server (if needed) and added to an existing Web application in SharePoint Server 2007 using Central Administration to attach each one in serial. When you attach the databases to the SharePoint Server 2007 Web application, the upgrade process runs and upgrades the data and the database to the SharePoint Server 2007 platform.
First, this is the only method that allows the SharePoint Server 2007 farm to exist on new hardware while the SharePoint Portal Server 2003 farm continues to exist on the old hardware. Second, content is moved at the Web application level, allowing you to select which databases are moved in which order within a given database set. Third, the SharePoint Portal Server 2003 farm is not affected by content database migration because it uses copies of the SharePoint Portal Server 2003 content databases.
First, much more administrative effort is required to use this migration method because you need to build out an entire SharePoint Server 2007 farm from scratch and then ensure that all of the configurations are committed before you can start moving content to the SharePoint Server 2007 farm. In essence, you’re building a new farm to which the SharePoint Portal Server 2003 databases will be migrated. Second, you’ll lack the granular control that the gradual upgrade method will give you. The level of granularity will be at the database level, not the site collection level.
The user copy method is a manual process in which a new SharePoint Server 2007 farm is created on new hardware and then users are given a window of time to copy their SharePoint Portal Server 2003 information to the SharePoint Server 2007 platform. Usually, this window of time is three to six months.
The largest advantage is that a full migration project is avoided by simply having the users copy data from one location to another. In addition, there is no downtime with this method because no databases or site collections are upgraded. Instead, content is copied from one location to another by the users when they are ready to do so. Finally, you can build a new farm on new hardware and then gradually move the SharePoint Portal Server 2003 content to the SharePoint Server 2007 farm without additional consulting or migration support.
The most glaring problem with this migration method is that you’re working with and trusting your end-users to move content from one location to another. Because people tend to put off until tomorrow that which isn’t causing extreme pain today, there is a high probability that users will wait until the last day or two to move their content. For example, if you give your users 90 days to move their content from SharePoint Portal Server 2003 to SharePoint Server 2007, the chances are good that many will wait until day 89 to start moving their content. So, you’ll need a plan to move content from one location to another and a project manager to keep everyone on track. Other than the effort of supporting two platforms for a period of time and assuming that you can work out the people factor of this migration method, we see no other disadvantages to this method.
Table 22-1 outlines the pros and cons of each method.
Table 22-1. Pros and Cons of Different Migration Methods
Upgrade option | Pros | Cons |
|---|---|---|
In-place |
|
|
Gradual |
|
|
Content database migration |
|
|
Content database migration (continued) |
|
|
User copy |
|
|
Now that we have outlined the basics of the four migration methods, it’s time to take a look at the pre-upgrade tasks. Once we have discussed the tasks and best practices that are part of preparing for your migration, we can then discuss the best practices and, frankly, some worst practices that need to be avoided when performing an upgrade from SharePoint Portal Server 2003 to SharePoint Server 2007.