3 Methods to Upgrade? Let me give you 4 More...
If you've followed my upgrade blog posts, you'll see a few posts on upgrade and the 3 methods are documented on TechNet and listed from the new TechNet Upgrade and Migration Center and ship out of the box. My recent experience tells me there are more than 3 options or upgrade methods and some variety. Let me give you 4 more to broaden your horizons.
4. Content Migration Upgrade - migrate just the lists and libraries from your WSS 2.0 or SPS 2003 environment. This may also be something you do from other platforms such as Notes/Domino, collaborative shares and/or collaborative public folders. The gist... Simply migrate/copy just the data (drop the UI and customizations). The migration APIs built into the product do support a fairly flexible method of pushing content in and setting appropriate meta data columns. AvePoint Docave, Tzunami Deployer, and a number of other partners listed on the upgrade center would prefer you use their tools to push content in to the new platform and simply focus on setting up the platform the way you want it. Other ways of doing this without affecting your current environment. Make a virtual copy of your environment, upgrade it with one of the first 3 methods, then either backup/restore the sites to the new environment (remove or deal with web parts that fail), save the lists as templates content included. I see customers that did custom site definitions that don't care to create new site definitions or deal with the whole upgradeschema mapping perspective to get to the new environment. Credit here goes to a company that gave their story at a recent meeting on campus who didn't say I can say their name. But they do have 500GB of content and about 25000 users.
5. Multi Threaded Database Attach - When you've got lots of data speed is a factor. Database attach is a lot quicker than gradual and has potentially more flexibility than gradual since you aren't impacting production by running side by side web applications. In the multi threaded approach you simply utilize hardware that will be reallocated after the upgrades are complete. The idea is that you create 2 or more all in one WFE/Query/Index boxes with a common SQL environment (even that can be offloaded if NIC or SQL CPU/Memory is a bottleneck). The credit for this method goes to MS IT, likely Bill Baer, or Sean Livingston the new WSS Upgrade PM for the next version. Ironic huh?
6. Virtual In Place Upgrade - In place upgrade is often seen as the easiest upgrade method. So why not create a virtual image of your environment, configure as necessary, run the prescan, upgrade, etc... address problems, and rollback changes simply don't commit if you don't like what you see. The undo disk changes allow you to quickly do this, all without using physical hardware. It's a great learning environment as well. I've seen this popularized on a couple of blogs and don't claim to take credit for this brilliant idea. This virtual upgrade makes me rethink my blog post emphasis on "in place" upgrade, but the 5 reasons still remain. Sorry I looked and I can't find the blog where I saw someone's success story. There was one comment on my 5 reasons post.
7. Migrate Then Upgrade - Customers that are "super" customized that fall into the category of wanting to get back to a supportable or easier to upgrade environment who may have touched their dbs or want to get out of their custom site definitions and into the out of the box site definitions... may find creating a separate environment that is a "clean" WSS 2.0 or SPS 2003 environment and then using simple stsadm -o backup and stsadm -o restore to backup and restore the site collections into clean database schemas with clean uncustomized file system and _layouts, reduce the "customization" overhead part of the upgrade to then run one of the normal 3 methods for upgrade. They then deal with unghosting and web parts as they come. I recommend reading the article on Best Practices for Ensuring Application Reusability in Windows SharePoint Services. I like to think about it in terms of supportability. Don't get romanced into thinking you have to have a custom site definition by reading it though. You can do amazing things out of the box with features in WSS 3.0 and MOSS 2007, something that wasn't necessarily available in WSS 2.0 or SPS 2003.
