Migrating to SharePoint 2010 - 22 Feb 2010

In 2008, Microsoft SharePoint became the fastest server-side product from the company to gross $1 billion in revenue. That’s no surprise as there is no other single product that can deliver the diversity of features that is so desperately needed by today’s organizations. Going into 2010, Microsoft has not been resting on its laurels and will be releasing a major upgrade, dubbed SharePoint 2010.

Although this release has significant user experience, performance, and other improvements, migrations will test the mettle of even seasoned IT pros as they upgrade their current SharePoint environments. New hardware and software requirements, architectural changes, and UI changes in the product will require solid migration and testing plans to ensure these upgrades proceed smoothly.

My goal of this migration article isn’t to illustrate every detail step-by-step. Instead, I’ll highlight the major aspects of a migration and prepare you for some of the gotchas. This guidance is based on the beta 2 version of SharePoint 2010 and applies to both SharePoint Foundation (the successor to Windows SharePoint Services—WSS—3.0) and SharePoint Server, which replaces Microsoft Office SharePoint Server (MOSS) 2007.

Migration Preparation

As you prepare for your migration effort, the first item to note is the new system requirements. Microsoft SharePoint 2010 will be available only in 64-bit and will require Windows Server 2008 SP2 or Server 2008 R2 as your base OS. On the backend, you must also have a 64-bit edition of Microsoft SQL Server. Supported SQL versions are 2005 SP3, 2008 SP1 and 2008 R2. SharePoint also requires the Microsoft .NET Framework 3.5 SP1 and a few other components, so check technet.microsoft.com/library/cc262485(office.14).aspx for the full list. Those of you building development environments will be able to run SharePoint 2010 on Windows Vista SP1 or Windows 7, but this won't be supported for production use.

Another key prerequisite is that you must patch your SharePoint farm to at least MOSS 2007 SP2 before you upgrade. You can determine your current build by looking at SharePoint’s version number. Simply go to Central Administration, click the Operations tab, then select Servers in Farm. If your version number is less than 12.0.0.6421, you’ll need to upgrade to at least SP2. Note: For those still running SharePoint Portal Server (SPS) 2003, you'll first need to upgrade to MOSS 2007 before you can migrate to 2010. For more details on migrating from SPS 2003, see the Microsoft SharePoint Team Blog post "Planning for Upgrade from SharePoint Portal Server 2003 to SharePoint Server 2010" at blogs.msdn.com/sharepoint/archive/2010/01/04/planning-for-upgrade-from-sharepoint-portal-server-2003-to-sharepoint-server-2010.aspx.

In SharePoint SP2 (and improved in the October 2009 cumulative update), Microsoft added a new operation to Stsadm to help facilitate your upgrade to 2010. The utility is called pre-upgrade checker, and you can think of it as an upgrade compatibility report. I strongly recommend running the tool on your current SharePoint farms. It assesses the health of your farm and suggests areas that you should correct before upgrading. By health, I mean it will inspect the state of various components, such as features, site definitions, and content databases and tells you whether these are functioning properly. You run the command directly from one of the SharePoint servers in your farm. It may take anywhere from a couple of minutes to an hour or more depending on how many databases you have and the overall complexity of your farm. Here is the basic command syntax:

stsadm –o preupgradecheck

This command won't make any changes to your environment. It's safe to run multiple times, although I recommend running it during off-peak hours because of the load it will place on your servers. When the execution is complete, the tool prepares a detailed HTML web report. Figure 1 displays a sample report I ran on one of my farms:

Reading through and understanding the report will take some time. Blocking (or failed) issues are those that you must address before upgrading. As Figure 1 shows, SharePoint isn't running on a 64-bit edition of Server 2008. The report will also include useful information items as well. Most issues have links to online materials that explain the problem in more detail. Although these information items may not be major problems, they could complicate the upgrade, and doing an upgrade won't resolve them. As much as possible, you should resolve these problems before you upgrade. For more details on the pre-upgrade checker, see "Run the pre-upgrade checker (SharePoint Server 2010)" at //technet.microsoft.com/library/cc262231(office.14).aspx.

Another important preparation step is to review your current customizations. SharePoint customizations come in many forms, and I am referring to those that involve changes to the file system on your SharePoint servers. This can include custom features, site definitions, field types, web parts, event receivers, assemblies; manual changes to files in the SharePoint root (C:Program FilesCommon FilesMicrosoft Sharedweb server extensions12); changes to web.config files; third-party software; and custom SharePoint solutions. SharePoint can be customized in many ways, so this is not a complete list. I know this is a tall order but may be very important as I’ll explain shortly. Do you have a change log that documents what changes were made? If not, start working on one today! This is also important for disaster-recovery purposes. A useful tip is to use a program like SourceForge WinMerge (sourceforge.net/projects/winmerge) to compare the contents of your SharePoint root to an unmodified one. If you run third-party software, this would be a good time to contact the vendor to see if the software is compatible with SharePoint 2010.

Upgrade Options

The next step in your migration plan is to decide what type of upgrade you’ll be doing. As it relates to the actual servers in the farm, Microsoft provides only two major upgrade options: in place and database attach. These are very different approaches, so I’ll review each of them. For those that have experience with upgrading from SPS 2003 (or WSS 2.0), you’ll notice that the side-by-side and gradual upgrade options are no longer options when upgrading to 2010. Third-party SharePoint migration products that give you more upgrade options are also available.

In-Place Upgrade

An in-place upgrade is designed to be the basic upgrade option. It’s an all-at-once upgrade where you upgrade all the servers in your farm at the same time. Although basic, it’s risky since once you start the upgrade, there’s no cancel option to go back. Fortunately, the upgrade works fairly well, and even if you experience hiccups, it should resume where it left off. To do an in-place upgrade, you must meet the 64-bit and Server 2008 requirements covered already. So, for example, if some servers in your current farm are running Windows Server 2003, you will first need to upgrade those before you begin an in-place upgrade.

If you decide an in-place upgrade is right for you, plan on and schedule downtime for the upgrade process. I can’t tell you how long the upgrade will take as it depends on the speed of your servers and the amount of data. Small farms might take only a couple of hours, whereas large ones may take a day or more.

Before you begin, you should stop the World Wide Web Publishing service on each web frontend to prevent any HTTP requests. Then, perform a full farm backup. This is just a precautionary step in case the upgrade should fail and you need to return to your previous version.

You start the upgrade by first installing SharePoint 2010 on each of the SharePoint servers. The install is similar to the previous version, although a useful new option can automatically install all software prerequisites. The installer will detect a previous version and will tell you that you’re about to do an in-place upgrade.

Once the install part is done, you need to run the SharePoint Products and Technologies Configuration Wizard on the server that is hosting the Central Administration website. This is where the upgrade actually begins. During the upgrade process, each content database will automatically be upgraded. If you’re running MOSS, each Shared Service Provider (SSP) and its settings will be upgraded and converted into new service applications.

Database-Attach Upgrade

A database-attach upgrade is done on a brand new farm on new servers. Compared to an in-place upgrade, it is safer since you don't disturb your current environment. Keep in mind that this will take more time as you need to manually reapply farm settings and customizations, and upgrade each content database one by one. Despite the extra work, database-attach upgrades are also a great way to test SharePoint 2010 without having to do an in-place upgrade. If you don't meet the system requirements such as Server 2008 or 64-bit, this type of upgrade is your only option.

After performing the installation and creating a new SharePoint 2010 farm, you manually create your web applications. I recommend using the same settings as your current farm, including the URLs such as portal.company.com. You might want to add temporary entries into your hosts file (C:windowssystemdriversetc) to bypass DNS name resolution. After creating each web application, you can delete the default content database that is created.

At this time, you should apply all the file-system customizations that you had documented, keeping in mind that the SharePoint root now points to the 14 folder (C:Program FilesCommon FilesMicrosoft Sharedweb server extensions14). This is why it's important to capture all the file-system customizations that have been made. You might be curious what would happen if you miss a few settings? Well, it depends on the kind of setting. If it’s something fundamental, such as a site definition, none of the web sites based on that definition will work. If it’s a web part feature, most likely just that web part won't display. The best way to know is to try it out and see what happens.

When you're ready, you attach your old content databases to the new farm. You start by restoring the most recent content database backups from your current farm to your new farm. To attach to SharePoint, you should use the addcontentdb operation from Stsadm. Here is the syntax for a single content database:

stsadm –o addcontentdb –url -databasename -databaseserver

When running the operation, SharePoint will look at the version of the database, and if it detects an old version, it will start the upgrade on it. An upgrade progress indicator displays to the console, and depending on the size, it could take minutes or hours to upgrade. Depending on your SQL server hardware, you may be able to run several upgrades simultaneously. This is called a parallel database upgrade; you just open another command prompt and run Stsadm again. You can also follow the database upgrade process from Central Administration. Just click the Check upgrade status link from the main page.

For each database you upgrade, two log files will be created in your 14LOGS folder. One is a detailed log showing each step involved in the upgrade session. Another will show just the warnings and errors that were found in the upgrade. You should find this latter one easy to read, allowing you to focus only on possible problems.

When reading the logs, you should know that just because an error occurred, it doesn’t mean the database didn’t upgrade. Similarly, not getting an error doesn’t mean that everything is fine. As with any upgrade, it is essential to test to make sure that existing capabilities still function correctly.

For those running MOSS 2007, you should know that a database-attach upgrade won't fully upgrade your SSP into new service applications. When you attach an SSP database, only your user profile store is upgraded. Search settings, Excel Service settings, Business Data Catalog (BDC) application definitions, and other settings must be recreated from scratch.

Visual Upgrade

One of the best features in SharePoint 2010 is the improved UI, which is implemented with a new set of master pages, cascading-style sheets (CSS), and JavaScript files. Unfortunately, this will probably be incompatible if you have any existing visual customizations. For example, you may be using a custom master page or CSS to brand your environment. To help ease the transition to the new UI, SharePoint has something called Visual Upgrade. This allows you to have SharePoint display the previous UI, allowing you to gradually upgrade the UI on a website-by-website basis. Site collection administrators can also apply the new UI to all websites in the site collection in one step.

When you view an upgraded website, it should look similar to how it looked before the upgrade. This may cause you to wonder if it was upgraded at all. You’ll see the old navigation menu, the old master page, and the old theme. When in this mode, you won’t get new UI features such as the ribbon.

To switch to the new UI, you can use the Visual Upgrade menu command. You'll find this on your Site Actions menu, as Figure 2 shows.

When you click Visual Upgrade, you’ll see three modes to choose from: Display the previous UI, Preview the new UI, and Use the new UI. The default is to display the previous UI. The preview mode is a useful way to test drive the new UI to see how well it works, allowing you to switch back if needed. Once you switch to the third setting (use the new UI), you can go back only by writing code to reset the setting.

If you haven’t made any visual customizations, the new UI should work just fine. Keep in mind that it will take some getting used to so make sure you factor this into your training plan for the migration. For those environments that have heavy visual customizations, you’ll probably find that there's some rework to get these to display properly in SharePoint 2010 when using the new UI mode. Make sure you factor this work into your migration and testing plans.

Moving Forward

With this overview, I've outlined the preparation steps that will enable you to start your migration project. I've also given you information that will help you choose between the two different upgrade types, in place and database attach. For your production environments, you should consider using the database-attach upgrade method for testing. Another option if you have a virtualization infrastructure such as VMware or Microsoft Hyper-V, is to do a physical-to-virtual (P2V) migration to duplicate your current environment. This would allow you to test an in-place upgrade. Finally, I reviewed how Visual Upgrade lets you decide which websites you want to use the new UI. Armed with this guidance, you'll be better able to build and execute a solid SharePoint 2010 migration plan.