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.