11/09/2010 Update: Joel Oleson has blogged his own upgrade decision tree 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 here, 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 http://bit.ly/a8IyIA 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 my Twitter and I will DM you the details.