It's been a while... I'm back with lots of SharePoint 2007 -> 2010 upgrade tips and tricks - sharepointers - Site Home

I haven't posted on this blog in quite a while but I plan to start adding some new content. I've spent the last several months figuring out how to upgrade all of our hosted SharePoint customers, so in doing all that i have created lots of tools, scripts and notes to make the whole SharePoint 2007 to 2010 upgrade process easier

Let me start with a few quick nuggets about parallel DB upgrading. Of course if you consider SharePoint business critical at all then you'll want to perform some dry run tests of the entire upgrade process. A dry run is a test that simulates exactly what you will do on the day of the upgrade. This is to uncover all of the "surprises" you find when you upgrade to 2010... this of course can be anything from comestic issues to sites not rendering errors. Dry runs are critical to find specific issues in your environment and you will save yourself a lot of headache and pain if you test it out first.

If you have a SharePoint 2007 farm that you are looking to upgrade to SharePoint 2010 you should consider how large your farm is. Upgrade is a time consuming process. In our lab tests upgrading content DBs with about 100 GB of content (~250 site collection) took on average 4-5 hours. If you have lots of data and lots of databases this could be a very slow operation do one after the other. SharePoint allows for upgrading multiple content DBs in parallel. This allows the overall process of upgrading lots of DBs go much faster.

Some tips about upgrading multiple content DBs in parallel

Perform perf testing / dry runs of upgrade to make sure you'll hit your SLA window. Hours? Days? Certainly something to consider and make sure you can meet.
Determine is the max SQL load / WFE capacity your hardware can support. In my testing we were able to upgrade 10 DBs simultanously per SQL instance, but after that the time to upgrade each additional database increased dramatically. 10 was our sweet spot. Also keep in mind that you can spread hte upgrade load across all of your SharePoint servers but upgrade is definitely a SQL intensive task.
Although you can perform a parallel upgrade, you need to attach content databases for upgrade with a delay. 30 seconds after another database upgrade has started seems to do the trick.
Create an automated way to kick off DB attaching for upgrade that you can use for dry runs and the production upgrade. This also eliminates typos from the attach process. I have some scripts that do this that I will share in a future post.

OK thats it for now. Hope these tips help