11/09/2010 Update: based on this. I recommend checking it out!
Earlier this evening I had a quick-fire Twitter discussion with @joeloleson, @ToddKlindt, @slkrck and @idubbs regarding SharePoint 2010 upgrade methods. This started with me referring to some good advice Joel made a few months back during one of Quest’s Virtual Expo for SharePoint 2010 (which are usually very useful by the way). The expo is still available , and the presentation in question was called “A practical guide to managing SharePoint 2010”. Joel basically stated that performing an in-place upgrade to SharePoint 2010 on a physical environment was “crazy”. Based on the discussion tonight it is clear that Joel was referring to an environment in which roll-back may be a problem – which makes good sense considering that an in-place upgrade is essentially a one stop shop without much configuration required.
Here’s a selection of the Tweets that followed:
- slkrck: Am with Joel here in that in place is crazy on physical – right? 😉 => not best practice
- ToddKlindt You say not best practice, but you don’t back it up with why. I want to know what the reasons are
- slkrck Read #2. If you’re environment is THAT clean; ok. I doubt it , though
- ToddKlindt So if the SharePoint 2007 farm is “fully functioning” an inplace is fine? Sounds good to me
- joeloleson Don’t agree. I’d say if you can rollback then I’d say ok with
- joeloleson Preference is NOT to do in-place. If someone has to do it for cost. No hardware 4 example. Then I’d recommend Hybrid
- chandimak go with the database detached inplace hybrid if u must, still not best IMO
So a few comments around upgrade options from (let’s face it) some of the most well-respected guys in the SharePoint space at present.
Joel then Tweeted this: “joeloleson What would be cool would be a decision tree“
Which I thought was a great idea in aiding the SharePoint 2010 upgrade method decision process. I fired up visio, and got to work based on the following assumptions:
- You have access to the SQL server(s) and any databases that are required for the migration, i.e. all of them in the case of the DB attach method.
- The chosen upgrade method is thoroughly tested with real world data (including similar quantities in order to estimate upgrade duration) prior to implementation on a live environment.
- Any potential licensing issues (e.g. running both a MOSS and SharePoint 2010 farm simultaneously during upgrade) are accounted for.
- A full fidelity backup is available prior to upgrade – you would be crazy not to test it first!
- In the case of the DB attach method, the AAM redirection method is used. Personally, I think this is a no-brainer in cases where you have large content bases that are likely to take a significant duration of time to upgrade.
- The Mount-SPContentDatabase PowerShell PowerShell commend is used throughout the database attach method to upgrade multiple databases at a time.
Here is the result on slideshare:
This is just a first attempt for what is a fairly complex decision, so I welcome any comments you may have. If you would like to collaborate on the VSD file send me a message on and I will DM you the details.