The Top 5 SharePoint Migration Pitfalls and How to Avoid Them
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!