Migrating to SharePoint 2010: Lessons Learned

By Christian Buckley
While attending a SharePoint conference earlier this year, I had an interesting conversation with a well-known SharePoint MVP and fellow presenter around the degree of difficulty of migrating from the 2007 platform to SharePoint 2010 versus what we experienced with migrations to earlier versions (from 2001 to 2003, or from 2003 to 2007). We unexpectedly found ourselves going back and forth between each side of the argument.

While SharePoint is now much better architecturally, helping improve and streamline aspects of the migration/upgrade process, deployments have also become much more complex as adoption increases and organizations have begun to make SharePoint a core component of their internal business systems.
While specific and granular technical issues may change somewhat between versions, most of the problems we experience remain fairly consistent because they have less to do with the underlying technology, and everything to do with things like information architecture, planning, and scalability of the solutions we create (or the lack thereof).

There is a shift happening in the SharePoint community, as more people are interested in hearing about how to holistically plan and build their environments the right way, the first time. As adoption grows, and businesses expand their SharePoint footprints across the enterprise, and across the cloud, more thought is going into how SharePoint deployments and migrations are planned.

Certainly, the influx of business users (rather than purely IT and engineering users) is helping shape this change. Many of my presentations focus on the Project Management and Business Analyst perspective because most deployments and migrations neglect to consider and include basic planning considerations.

Speaking with experts around the world, a lack of planning is a strong recurring theme. In my role as an Evangelist, I regularly meet with SharePoint experts, MVPs, and MCMs (Microsoft Certified Masters) and ask them what they feel is important about the platform. As you can see from responses by MCMs Chris Beckett (on video) (and on Twitter), and Brian Culver (on video) (and also on Twitter), as well as from well-known expert Chris Givens (on video) (and on Twitter), proper planning should be at the core of your SharePoint initiatives.

There is no magic bullet. Many of the “best practices” around migration planning are just common sense...and yet many teams seem to gloss over them, or not staff their projects appropriately.

If your organization does not have a dedicated PM or BA available to help drive this process, hopefully your IT or engineering team can find some key takeaways that will help improve your migration:

• Allow for plenty of test time.
An age-old mistake in IT planning is to make up for lost time in tight schedules by cutting into testing. Don’t do it. At the end of the day, SharePoint is a business platform, and your business users need time to review, provide feedback, and sign off on whether your migration was a success. Getting their buy-in is the key to overall adoption.

• Migrate in stages, instead of all at once.
As in any complex project, you cannot do everything at once. You need to prioritize. Within SharePoint, consider which sites and teams need to move first. As with providing ample test time, developing a plan around these priorities will have an impact on end-user adoption. Focus first on those teams who use SharePoint day-in and day-out, and they will become your key advocates throughout the remaining schedule. Think about breaking your migrations into phases as follows:
o Based on usage – what are the most critical sites?
o Based on complexity – what are the easiest sites to move across first, leaving the most complex for later?
o Based on schedule – what are the sites that are most business-critical, possibly due to a new business line, product, merger, etc?

• Have a rollback plan.
Migrations should never be all-or-nothing. Many fail (at least in part) due to unidentified customizations or poorly architected solutions. Know how to roll back your migration, and be ready for problems should they occur. This is why so many experts recommend breaking your migration into pieces, going piece by piece rather than all at once: rollbacks are less painful.

• Make sure you have a solid communications plan for end users.
Because the platform is used (and depended upon) by end users, keep them in the loop on what you’re planning and as the plan is being executed. Tell them what you will be doing, share information with them as the migration is underway, and give them a summary of the plan once completed. Including them in the migration planning is another key to long-term adoption.

• Ensure end users (and administrators) have training on the new technology/platform.
With most migrations, content is reorganized and new features are introduced. Don’t assume that everyone knows how to use these new features. Many of us learn by doing, and can become quite proficient without any formal training. But some degree of formal training can expedite the learning curve from end user to power user, and help your business get the most out of its investment.

• Don’t recreate the same mess.
Migration is an opportunity to clean up, to set your environment on the right path, and to build out a platform that better aligns with your business. It is often referred to as ‘transformation’ because it is a process of reorganizing, re-architecting, and improving SharePoint. Things like deleting empty sites, consolidating site templates and content types, redesigning navigation, removing customizations that can be replaced by out-of-the-box capability, and outlining keyword taxonomies will help your end users take advantage of the rich features in the platform, including improved Search and the new social capabilities.

SharePoint is very much like fingerprints: we all have them, and yet they are all unique. The same can be said for SharePoint migrations. Not every ‘best practice’ applies equally to every deployment, or to every company. Your organization has strengths and weaknesses, and not every one of these suggestions may apply.

The point is to consider the experience of others who have traveled this path, and not make the same mistakes. Follow the advice of the experts, and take the time to plan out your SharePoint migration. Your results will be well worth the investment.

Christian Buckley is Director of Product Evangelism for Axceler, where he helps drive partner and community development. Christian previously worked at Microsoft as a Senior Program Manager on the enterprise hosted SharePoint platform team (now part of BPOS), and also managed an engineering team in advertising operations. Prior to Microsoft, Christian was managing director of a regional consulting firm in the San Francisco East Bay, participated in several startups, and worked with IBM, HP, Cisco, Matsushita, Solectron, Seagate and other large hi-tech and manufacturing firms to deploy collaboration and supply chain solutions. He is co-author of three books on IBM Rational Software configuration management and defect tracking solutions, and can be found online at www.buckleyplanet.net and www.twitter.com/buckleyplanet