We recently upgraded our SP2007 to SP2013. As all at Seilevel would call it, it was an experience. We use our SP as a document repository, holding project documentation for easy internal access. We found out information about our current installation of SharePoint and decided to go with a brand new install, rather than trying to migrate all of our data. This means that we’d have to more or less manually reconstruct our SharePoint shell from a new install, and use a tool to migrate documents. It’s fairly straight forward.
After some bumps in the road on this internal project, we have SharePoint2013 up, running, and completely functional for our purposes.
Through this experience, I’d like to share a few things with you:
1. Using a Roles & Permissions matrix was a GREAT idea. Our permissions on Sharepoint2007 were a mess. Rather than recreate these exactly, we used SP groups to which members were added. First creating the Roles & Permissions matrix made this task very easy, as the developer simply followed the spreadsheet.
2. Start user buy-in and determining internal project value early. It’s good to get people excited about the change rather than simply choosing a day to turn off their old tool.
3. Create a training deck to help people learn to use the top features they’re used to. Highlight what’s changed and what has stayed the same. My team was initially disturbed that SP2013 looked completely different than SP2007. When I highlighted that it’s mainly a UI change, that the functionality they’re looking for is still there, and showed them how to do it, they all became more accepting. This training deck was key.
4. If you have to manually migrate things over, like we did, turn the old site to “Read Only”.
5. Understand that although this is a fairly simple and straight forward project, time and effort need to be dedicated or it will fail.
As for the change from SP2007 to SP2013, I like it.