Lots of companies struggle shifting to a newer version of SharePoint and for good reason.
We’ve recently completed a pretty complicated migration to SharePoint 2013 for Goldcorp, a Canadian mining company with 18,000 employees and mining operations in Canada, Mexico, Central and South America.
I thought I'd pull together some of the migration lessons learned to pay it forward for anyone about to go through a similar experience! You can find out more about the new intranet in our upcoming webinar or see some screenshots in the Goldcorp intranet case study on our website.
And now for the SharePoint migration lessons learned:
Clarifying the scope and name of the initiative is a good first step
It may sound silly, but many organizations misrepresent what an intranet redevelopment is all about. Traditional terminology is to “upgrade to a newer version”, although in SharePoint parlance that actually implies the method and refers to an in-place upgrade. For SharePoint you cannot upgrade across multiple versions, say from 2007 to SP2013. When moving from SP2010 to SP2013, you can no longer perform the in-place upgrade. You have two options: Database-Attach or Migration using third party tools or custom scripts. My first suggestion is to make sure whatever you call the initiative, that you have a name that resonates with the business and make sure the technical folks understand that the name may not imply the approach.
Migration tools are not a silver bullet
Despite how advanced many of the top migration tools are, we found that there isn’t a one size fits all approach. Moving site collections are very different from moving workflows or pages with rich managed meta-data. Choose your tool and approach wisely based on the scope of what you are needing to move.
Redesigning the intranet is a double-edged sword
Many companies want to redesign and improve their intranet when they tackle an upgrade to a new version. Others are adamant about keeping to a like-for-like upgrade where the structure and experience doesn’t change. The unfortunate reality is that while it is really valuable to redesign and improve an intranet’s experience, the more you change the structure the more risk and change management is required. On the flip side, if you improve nothing then the business naturally will feel the initiative offered no incremental value. I think a healthy balance of both perspectives is wise.
Build a solid content inventory or audit
I can’t stress this enough. A complete content audit will save you a lot of money and pain when it comes time to migrate. The audit can help tell you what exists in terms of the current structure and creating a content map will make the connection between the current and future structure. You can run a script or pre-migration assessment to map out what exists and investigate the “Site Contents” to see what content lurks within each of the sites. Once you have a solid map in place you can build a migration approach and start testing out the approach. This isn't sexy work, but you will be the hero if you do it right and everyone will be thankful of your efforts in the long run.
Big bang or iterative?
While it can sometimes feel more satisfying and complete to migrate all the content in one big bang, it amplifies the risk and change required by end users. An alternate approach is to consider a more gradual migration roll-out. This may require end users to get used to the idea of a new solution being in beta or a work-in-progress experience, but it may reduce and control the potential for negative impact occurring to specific scoped areas.
Clean-up what you can, but don’t try to boil the ocean
Old site permissions and inactive sites can really complicate a migration process. Everyone agrees an upgrade is a great excuse to clean-up, but what can be really tricky is finding an owner of a piece of content or a site. Many sites become inactive, and aren’t properly retired which can bloat the migration effort and complicate the user experience. Striking a balance is key prior to launch. If you wait too long to make the clean-up perfect, you might be waiting forever and never get to the new solution.
QA the moved content
Sounds obvious, but once you’ve run some initial tests of your content migration approach, it is important to run quality assurance tests and user acceptance tests of the new migrated content. To the migration team, it may look like everything moved across properly. But with a more rigorous testing approach or with owners of the content, you may find that lists are missing, web parts didn’t make it or perhaps the left navigation didn’t make it across properly.
If you have any lessons learned from a SharePoint 2013 upgrade or are curious to learn more, leave a comment below!
