Team Axceler is back in the office after a fantastic few days in (sometimes) sunny Florida where we attended DevConnections Orlando 2011. Coming from Seattle, I was one of the few folks happy to welcome the showers and cooler temperatures mid-week, but we were book-ended by beautiful weather. While my primary focus at the event was around two sessions in the SharePoint business and social tracks, Axceler was also an exhibitor, and s I spent a good amount of time talking to customers at the booth. We had strong traffic throughout the event, and were able to finally meet many of our happy customers in person - which is always a treat.
Amidst the many ControlPoint and Davinci Migrator demos, I was able to spend time talking with various partners and SharePoint experts, and capturing additional footage for my video series, The One Thing You Need to Know About SharePoint 2010. I was able to capture footage with Cathy Dew from Summit 7 Systems, Inna Gordin from BA Insight, and Jeff DeVerter from Rackspace, among others.
For the social track, I presented part of an ongoing analysis of competitive social tools in the enterprise space, comparing and contrasting their features to the latest capabilities in SharePoint 2010:
For the business track, my new session explored aspects of migration transformation, focusing on best practices to clean up and reorganize taxonomy, templates, content and configurations before and during migration:
I look forward to participating in two of the upcoming DevConnections Coast-to-Coast events this spring (I'll be presenting multiple sessions in
Boston April 25-27, and
San Diego May 2-4), and their June event (June 13-15) in
London. See you there!
As I made my way down to DevConnections in Orlando, my thoughts were on my two sessions, and the tweaks I wanted to make to my presentations. I’ll be introducing a new session this week, entitled “Don’t Just Migrate – Transform Your SharePoint Environment” that shares multiple examples where customers, partners, and my own projects were successful – and not 
so successful and why. Based on solid project management and business analysis fundamentals, this session will help you avoid some of the most painful and even embarrassing errors made during a SharePoint Migration.
If you’ve seen me present, you know that I love lists of practical information – and content that is actionable. One of the lists I’ll be presenting this week contains some of the most common SharePoint migration pitfalls and how to avoid them:
- Rushing the process.
In the movie Spaceballs (I love to quote classic American films), the antagonist’s spaceship overshoots their target by miscalculating their jump into hyperspace by fractions of a percentage, landing them in the wrong galaxy (and with a plaid vapor trail). The point here is that small mistakes in rushed planning cycles can lead to huge gaps further down the road, which can be expensive to overcome. In SharePoint for example, data model and taxonomy flaws may not show up for months down the road – and it is harder and more expensive to correct the problems later.
- Not identifying all of your customizations.
If you’ve performed previous SharePoint migrations, then you have likely run into the pain of digging through error logs to find out why a migration failed – only to come across a rogue web part or custom site design. As Murphy’s Law dictates, these failures always happen at the most inconvenient time: over a weekend, during crunch time. In addition, they usually cause the maximum amount of duress to you, your management team, and your end users .
- Treating all sites and end users the same.
Three out of four teams may use SharePoint out-of-the-box, but treating that fourth team – with their custom workflows, extensive dashboards, and customized integration to the CRM system – the same way as the other would be disastrous. Why? The OOTB sites should, in theory, migrate cleanly, but the fourth site will need care and hand-holding. Treating them the same could break the site, leaving the team that actually uses SharePoint in turmoil. Understand the individual needs and requirements of each team, especially your power users – the folks who depend on SharePoint day in and day out.
- Not testing.
Migrations are iterative. This is because different teams, sites, and site collections have different priorities and requirements. You need time to validate what has been moved both from a technical standpoint, and from an end-user standpoint. A robust migration strategy allows for verification that permissions, navigation, look and feel, and content are all working as planned.
- Going in without a rollback plan.
A good project manager has a plan for and mitigates all risks with a solid rollback plan. Why should a SharePoint migration be any different? You may be able to recover from problems caused by rushing into the process, not identifying all of the customizations in your environment, treating all of your sites the same, and not employing healthy test practices – but you will not recover (without severe pain) from roll back failure (one of the reasons why in-place upgrade is rarely recommended). So plan accordingly. Have your backups ready, otherwise Mr. Murphy and his Law will likely join you on this little endeavor.
Migration is an opportunity for your organization to clean up, transform, and realize your SharePoint vision. It is not just a technical activity, but should be a much more thoughtful and planned process.
Our goal here at Axceler is to help you better manage your SharePoint environment, from better planning and pre-migration analysis with Davinci Migrator, to centralized management of permissions, features, analysis and reporting with ControlPoint. I’ll cover more on these topics in Orlando this week. Hope to see you here!