It started on Twitter… SharePoint 2010 upgrade method decision tree

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.