Sunday, June 6, 2010

SharePoint 2010 Migration Getting Started


I believe SharePoint Upgrades from 2007 to 2010 is going to be one of the most important topics of discussion for SharePoint consulting. Let me first start off with a history lesson of what I saw with SharePoint 2003 to SharePoint 2007 upgrades. One common scenario I saw was high adoption of WSS 2.0 because it was free, they loved it and wanted to upgrade to MOSS. A second scenario was a client trying to use SP Portal 2003 to support mission critical activities. They understood the limitations, they saw SharePoint 2007 solved their needs and they needed upgrade. It was common in the second scenario to see customizations (custom site templates, web parts, etc.). Typically it was challenging to move forward these customizations because SharePoint 2007 was a complete re-architecture of the SharePoint platform. What we would usually recommend them to lose their SP 2003 customizations because it would be offset by the fact that SharePoint 2007 was just so much better. SharePoint FrontPage modifications typically made things very challenging to complete a full apples-to-apples upgrade. In the end, SharePoint professionals did a good job at moving all the content from SharePoint 2003 to 2007 and then started to build new solutions. Here is a blog that I wrote that provided guidance for moving from SharePoint 2003 to SharePoint 2007.

I wanted to discuss this because I feel that the atmosphere is a bit different now with SharePoint 2007 to SharePoint 2010. These are the commons scenarios that I currently see today:

  • I see a lot of organizations that have made large investments into SharePoint 2007. Not just from a cost of software and ECAL, there has been a lot of investment in either IT staff or consultants to build solutions with SharePoint 2007.
  • SharePoint 2007 is an extremely powerful platform however there are new features of SharePoint 2010 (i.e. enterprise content management, scalability, search, data transparency) are very enticing and many organizations need them to continue to see added return on investment.
  • Customizations to SharePoint 2007 are not as small and trivial as what we saw with SharePoint 2003. The custom applications and systems that are embedded in SharePoint 2007 need to move forward in full to SharePoint 2010.
  • The amount of content to be migrated of SharePoint 2007 is significantly more than what we saw with SharePoint 2003.
  • There tends to be strong user adoption of SharePoint 2007 that there was with SharePoint 2003. Knowing this, it is important to ensure that there is continuity between upgrades to ensure there are little to no disruptions to the business.

My honest opinion is before getting "wrapped around the axel" on exactly how to do this upgrade, we should just look at this like any other enterprise application upgrade. Once we understand that we can bury ourselves into the details of how the upgrade process will go. Will it go perfectly, well there is not a lot of data out there just yet on how smooth an upgrade will go and all the exceptions that you will run into. I do see two things:

  • First Microsoft has provided us some better tooling to facilitate upgrades from SharePoint 2007 to SharePoint 2010.
  • The paradigm shift for SharePoint 2007 to SharePoint 2010 is not as great as the previous upgrade. This gives me hope that the upgrade process will go better for SharePoint 2010.

In this blog I am going to over some of the various aspects you need to take into initial consideration when doing a SharePoint 2010 upgrade. Microsoft has provided an upgrade cycle that they are using to communicate how upgrades will play out for SharePoint 2010. I actually like it and will use it as the basis for this discussion. I am going to add lots of things which I think are important given what I have seen with SharePoint for the past few years.

  • Learn Phase – Focus on understanding what you have today and where you plan to go tomorrow.
  • Prepare Phase – Detailed planning for SharePoint 2010 upgrade.
  • Test Phase – Testing the upgrade process.
  • Implement Phase – Perform the actual upgrade.
  • Validate Phase – Validate the success of the upgrade.

Learn Phase

There are several goals of this phase. I think the most important thing we want to know is what we have today and where we plan to go tomorrow.

Current Status – First you need to get an understanding of what you currently have today. In many cases, your SharePoint environments have probably experienced growth, usage and adoption that you probably have not thought about. Whether intended or not, you need to gain a good understanding of it to make sure there is continuity for the migration. You need to assess:

  • The current infrastructure. Understand all the servers in the farm and what services they are supporting.
  • Review the size of content databases and understand what site collections contain the most content.
  • Understand the topology of the SharePoint sites and how they are organized today.
  • Try to get an understanding of how security has been managed up to this point. I know this is a touchy subject with a lot of organizations have had challenges with permission management with SharePoint 2007. Still you need to get a handle on it.
  • Information architecture and taxonomy needs to be reviewed. This is typically the content types that you may have created.
  • Need to get an understanding of all the services that have been configured and deployed into SharePoint, for instance Search, Excel Services, PerformancePoint, etc. You should also get an understanding of how the business users are using them too.
  • Audit all custom development implementations such as Custom Features, web parts, site templates, event handlers, InfoPath forms, BDC, etc. Anything that has been deployed you're your SharePoint environment should be understood and leave no stone unturned. You really need to look at everything and understand what was done and even more important "how" was it done.
  • Review SharePoint Designer usage. I call this out separately because sometimes access to this tool is given out to more than just developers and allows users to create customizations to SharePoint that not everyone may know about.
  • Review all your SharePoint ULS Logs, web logs, and event logs on all machines where SharePoint installed. Might as well know if there are lots of errors out there. If you see egregious errors or warning it would probably be good to fix these up before doing the migration.

This list is not totally inclusive of everything you may need but it is a great starting point.

Roadmap – Next you need to create a roadmap for SharePoint within your organization along all the same lines that I just discussed.

  • First you need to understand SharePoint 2010, understand the new features and how you plan to use them in your organization.
  • Next you need to understand what requirements of the organization and more importantly the business drivers, business owners and actors who will utilize this. Knowing this will greatly affect both you logical and physical designs of SharePoint 2010 (i.e. we have so much more flexibility with service management in SharePoint 2010).
  • Next you need to be able to map out by quarter and fiscal year what business objectives need to be supported and when. These timelines can greatly affect your migration approach.
  • Need to document all people, process and technology risks associated to SharePoint and create a mitigation plan for each that will be actively managed throughout the migration project.

No comments: