In-Depth
The SharePoint Upgrade Trap
SharePoint 2007 migrations are simple enough, but beware of hidden dangers. Here's a look at some of the more common upgrade and migration problems.
When I think about the process of migrating from SharePoint 2003 to SharePoint 2007, the phrase "deceptively simple" comes to mind. Microsoft gives you the option of either performing an in-place upgrade or a migration. If you choose the in-place upgrade option, all you have to do is insert an installation disk, answer a basic question or two, click Next a few times, and you're good to go.
Simple, right? So why qualify the process as deceptively simple? Well, there's a lot that can go wrong. Let's look a bit more closely at some of the caveats to the upgrade or migration process and what you can do to avoid some common problems.
Upgrade Paths
The first thing that you need to know about the upgrade process is that not every version of SharePoint can be directly upgraded. SharePoint 2007 supports in-place upgrades from SharePoint 2003 and Windows SharePoint Services 3.0.
If you are running Windows SharePoint Services 2.0, then the easiest way to upgrade is to upgrade to Windows SharePoint Services 3.0, and then to SharePoint 2007. Microsoft offers a full upgrade toolkit that can help you to upgrade from Windows SharePoint Services 2.0 to 3.0. You can download this toolkit here.
If you happen to be running Microsoft Content Management Server 2002, then you will not be able to do an in-place upgrade, but you can migrate the server's content.
What Could Go Wrong?
So if an upgrade or migration is so easy, what could possibly go wrong? Even though Microsoft has thoroughly tested the upgrade and migration features, they have no way of knowing about any custom code that you might be running. The migration or upgrade process works really well if you are using only stock Web parts, but things become a bit sketchy when you start introducing customizations.
One classic example of this is that if you use a tool such as Microsoft FrontPage to customize a SharePoint site, that site is said to be unghosted. What this means is that when the migration completes, the site will still retain some of the look and feel of the SharePoint 2003 site, because Setup doesn't know how to convert Web parts that do not comply with some default parameters. Fortunately, Microsoft does provide administrators with a way to return a site to a ghosted status once the migration is complete.
Path of Most Resistance
As you can see, the upgrade or migration process is not always as easy as you might at first be lead to believe. That being the case, I strongly recommend performing a trial upgrade or a trial migration. That way, you can find out about any potential issues ahead of time, without affecting your production servers.
The easiest way of performing a trial upgrade or a trial migration is to get a couple of high-end PCs that you can temporarily configure as servers. Once you have these PCs in place, you can place them on an isolated network and then restore your SharePoint backups to them.
Using an isolated network is important -- you don't want your trial migration to impact your production network in any way. The down side to using an isolated network segment is that you will need to set up at least one domain controller and at least one DNS server on it.
One of the easiest ways to bring an infrastructure server onto your isolated network segment is to install a trial version of Windows Server onto a PC and then use DCPROMO to promote it to a domain controller. Once you have done that, then you can physically remove the new domain controller from your production network, and then attach it to your isolated segment. You will then need to seize the operations master roles and configure the domain controller to act as a DNS server.
Keep in mind that because you have seized the operations master roles, you won't be able to plug the domain controller back into your production network. That being the case, you will need to use the Active Directory Users and Computers console to remove the references to your new domain controller from your Active Directory.
It's a lot of work to get the SharePoint server and the domain controller in place for a trial migration or upgrade. The nice thing about using this method though, is that it allows you to get an accurate feel for how the transitioning process will go when you eventually try it on your production network.
Keep in mind that even if it appears that your trial migration or upgrade was successful, you need to have some of your power users log into your isolated network and interact with your SharePoint site in the same way that they do on the production network. Having experienced users to thoroughly test the post-migration lab network is the only way that you will be able to tell for sure whether or not there were problems with the migration process.
A Simple Plan
Unfortunately, if you have created any custom Web parts, made customizations to existing Web parts, or purchased any third party SharePoint add-ons, then there is no way of knowing exactly what is going to happen during the upgrade or migration process. That's why it is so important to thoroughly test your migration plan before you attempt to upgrade or migrate your production servers.
About the Author
Brien Posey is a 22-time Microsoft MVP with decades of IT experience. As a freelance writer, Posey has written thousands of articles and contributed to several dozen books on a wide variety of IT topics. Prior to going freelance, Posey was a CIO for a national chain of hospitals and health care facilities. He has also served as a network administrator for some of the country's largest insurance companies and for the Department of Defense at Fort Knox. In addition to his continued work in IT, Posey has spent the last several years actively training as a commercial scientist-astronaut candidate in preparation to fly on a mission to study polar mesospheric clouds from space. You can follow his spaceflight training on his Web site.