Migrating to SharePoint 2010

Migrating to SharePoint 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 Microsoft MCTS Training.

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 Server 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."

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 it tells you whether these are functioning properly. You run the command directly from one of the SharePoint servers in your farm. It might 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 Microsoft MCITP Certification:

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. Most issues have links to online materials that explain the problem in more detail. Although these information items might 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)."

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 Files\Common Files\Microsoft Shared\web server extensions\12); 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 might 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 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 in which 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 perform 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. How long the upgrade will take depends on the speed of your servers and the amount of data. Small farms might take only a couple of hours, whereas large ones might take a day or more.

Before you begin, you should stop the World Wide Web Publishing service on each web front end 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.