I have recently heard a lot of conversation in the community about upgrading from SharePoint 2007 to 2013. In fact, this seemed to be somewhat of a focal point last month at SPTechCon San Francisco, as many people asked my opinion on how to plan for the upgrade and what recommendations I had to get it completed as effectively as possible. The interesting thing about the questions is that they were focused on the business, relating to strategies, not technical issues related to how the upgrade itself should be tactically approached—which is great, because there is still direct Microsoft-defined migration from 2007 to 2013.
As I went through each of the conversations, my response was specific to the business size and needs, mainly focused on the advantages the upgrade would bring. One area of concern I had, which is what sparked this piece, was the fact that many organizations were moving to SharePoint 2013 for reasons other than planning and alignment with their organizational goals. For example, one organization responded to my question by simply stating that the project was “in budget.” This company also had upwards of 15,000 people who would be using the system, and news of the blind upgrade was like nails on a chalkboard for me.
First and foremost, to begin your upgrade project, your first step must be doing your research and getting a common expectation set across the organization. Note that I appropriately give this the title of “upgrade project.” This is more than just a simple database upgrade and refresh of your user interface, and it is critical that your organization give this initiative the respect it demands in order to deliver it properly. The reason for calling it a project is because “projects” get different exposure in organizations: They typically demand a Project Manager, resourcing and budget that are defined and measured, all of which are required for your project.
With your project in place, it’s time to work on your expectations and organizational-level sets. If you have the ability, bring together the project team that built your 2007 environment and ask some questions about what they believe the focus of the 2013 upgrade should be. If that team is not accessible, locate the lessons learned documentation, or assemble some users who were involved in the rollout. These resources will likely be able to walk you through the trials and tribulations of the implementation, including which business units were easiest—and hardest—to roll out. Try to find out the functionality that was commonly implemented across the organization and, most importantly, where critical business data currently lives, who owns it and how the needs for accessing that information have changed since the 2007 rollout.
Next, ensure you have a firm understanding and grasp of where your information is, as well as what data objectives you have and will have going forward. What you may find is that the same data exists in multiple locations on SharePoint. Though not a focal point of the upgrade, now is the time to learn what information is available on SharePoint and how you can scale for success. For example, you may find that you can consolidate some of your data and revise your reporting strategy to align with this updated information source.
Additionally, now is the time to review your dependencies on existing line-of-business systems, as you can use this project to identify information that you can surface up through SharePoint.
As I mentioned above, identifying the functionality that is currently being used (notice I didn’t say deployed) is important to catalog at this point in your review. This information will show which areas of SharePoint are truly being used and depended upon by your users, not necessarily the ones that have been prioritized and put online. Be sure to review this information from an objective opinion, as this is also an opportunity to reposition functionality in SharePoint’s new 2013 skin. Ensuring that you have placed the critical components of the 2007 system in 2013 will build your case for adoption and governance as you continue your project.
As you move through your upgrade decisions with 2013, including on-premise and cloud discussions, be sure to entertain conversations about the app model versus the deployment of existing Web Parts. The 2013 app model embraces the consumption of information in different ways than previous versions of SharePoint. As demands for data have changed significantly since your 2007 rollout, it is important to review your data needs, policies, mobile demands and how your information is being used.
Piloting and rolling out your project needs to be a measured and precise part of your implementation. This is as strategic a step as you will have in your project. Take the time to consider which users and business groups to include, and take the time to evaluate their impact on the organization overall. It is entirely possible that a group you haven’t considered for the initial 2013 rollout is actually best for the pilot. Their new view on the 2013 system may provide a more detailed analysis of the end product and yield greater feedback overall.
Eric is the Executive Vice President of Concatenate, creators of the RealTime suite of products, based in Toronto. A SharePoint MVP, you can reach Eric by e-mail at ericr@concatenateinc.com or on Twitter at @rizinsights. Read his other SharePoint thoughts on his blog at www.ericriz.com.
