Don’t upgrade to SharePoint 2010 until you read this

In my younger days, I did lots of car maintenance myself. I not only changed my own oil and filter, I switched out brakes, starters, alternators, and more. But as cars have evolved, I’ve learned to leave some things for the experts to handle, which frees my time up to do what I do best.

Upgrading SharePoint raises a similar situation. You may like to be hands-on with your own environment, installing all your own servers and such, but the upgrade to SharePoint 2010 should either be treated with the utmost care or turned over to an expert who’s done it a bunch of times and has it down to a science.

Allow me to outline why doing so might be wise. First, it is a no-brainer that if you have SharePoint 2007, you are going to want to upgrade. The features that relate to security, document libraries, and UI enhancements should have you chomping at the bit to get 2010 up and running.

So where do you begin? You might first consider the type of upgrade you’re hoping to perform:

• You can do an in-place upgrade. Well, you can, but if you do, you need to be prepared for a slew of caveats and for the upgrade to fail (so that you can recover in the event it does). It’s true that the in-place upgrade is the easier and the cheapest way to go — if everything works.
• You can perform what is called a database attach upgrade (or migration) where you back up the content databases you want to migrate and recover them to the new server, and then mount them to a Web application on the new SharePoint 2010 server.
• You might also perform a hybrid upgrade where you upgrade the farm portion via an in-place upgrade but carry over the databases via a database attach.

When deciding how to upgrade, first make sure your SharePoint 2007 environment is ready for that upgrade or migration. One key element is to have SP2 for SharePoint 2007 installed on the server. Without that, you cannot run the pre-upgrade checking tool on the server.

If you do have SP2 installed, you can open up an administrative command prompt and navigate to the location of the STSADM and use the -o preupgradecheck parameter to get a full diagnostic of your system. The pre-upgrade check will tell you if you can perform the in-place or as a database attach or both. It is essential to run the tool first.

You need to have some important hardware and software elements in mind — and may have to wrestle with upgrading items — before you can even think of going with the in-place upgrade. (By contrast, with a database attach, you can make sure the hardware and software meet all the installation requirements.) Maybe you are running on a server running 32-bit versions of SQL or Windows, which is a no-no because SharePoint 2010 requires an x64 processor with 64-bit OS and SQL). Maybe you have Windows Server 2003, which means you have to upgrade to Windows Server 2008.

Ultimately, though you might want to do an in-place upgrade, the circumstances may dictate that you have to go with a migration through database attach anyway. In addition to the compatibility issues, keep in mind that the upgrade process can take a lot of time if you have large databases to upgrade and a large number of site collections — and during that period, your SharePoint environment will be offline. If that downtime is a problem, you may be looking at the database attach as your upgrade method.

With the database attach method, you enter your SQL Studio Manager on your SharePoint 2007 side and can set the content databases to read-only so that users can still access the content through SharePoint. (They can’t add content to those databases, of course.) Once you have the content database set to read-only, you back up the content database and copy it to your SharePoint 2010 server. Disconnect the content database from the existing Web application, recover the database you backed up through the SQL Studio Manager, and then use PowerShell cmdlets to test and mount the database into the Web application that you just disconnected the original content database from. Clear as mud? I thought so.

Regardless of the method you choose, you still want to make sure you have a backup/recovery plan in place that has been tested. Too often I see SharePoint being backed up and the administrators are praying they never have to restore it. Many barely understand how IIS, SQL, and SharePoint all play together. This isn’t the time to begin learning backup/recovery, to learn an upgrade process for SharePoint 2010, and then, post-upgrade, begin learning SharePoint 2010 and rolling it out to your people. That’s way too much to do at the same time.

Let me be clear: It took me a week to research and test the in-place upgrade process and the database-attach migrate process before throwing down the “hire somebody else” gauntlet — and I’m already experienced with both SharePoint 2007 and 2010. Sometimes it really is better to hand off the learning curve, the trial and error, and the late nights researching to someone who can do it in their sleep.

This article, “Don’t upgrade to SharePoint 2010 until you read this,” was originally published at InfoWorld.com. Read more of J. Peter Bruzzese’s Enterprise Windows blog and follow the latest developments in Windows at InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.