5 Steps for Building a SharePoint Migration Plan

From all outward appearances, we seem to have turned a corner with SharePoint 2013 migrations. Compared to previous versions, SharePoint 2013 has experienced a relatively slow adoption cycle as organizations paused to understand the impacts of the new release -- and to understand, in many cases, their cloud strategies.

Migrations to the latest version seem to now be increasing speed. Since the SharePoint Conference in Las Vegas earlier this year, my own observation is that more companies are approving budgets and updating plans, and with that movement and more firm cloud strategies in place, we are also seeing an increased interest in SharePoint Online and Office 365.

Steps to a Smooth Move

So for those of you who are planning a move to SharePoint 2013, here are five steps you can take to ensure things go smoothly: 

1. Define Your Business Priorities

Simply put: know what it is you are trying to achieve for the business before you start. A migration is the time to think about your system holistically -- about the services you are running, your site and site collection topology, your permissions management model, and so forth -- and then to prioritize, validate, and refine your requirements. Make sure what you are trying to accomplish with the technology matches up to your business needs.

Begin by identifying key workloads or use cases, and prioritize them by business impact. Then, approach the top priority workloads first. Think about your strategic initiatives, and how the technology is going to help you meet those workload requirements. For example, you might approach it from a vertical like the automation of your Human Resources processes and workflows. Further down the road, after you have your top priority workloads in pilot mode, you may want to think horizontally, such as how your management team across all organizations will access and consume team or project reporting via common dashboards.

Depending on the level of complexity of your existing environment, you may need to do some extensive planning around how you will move existing solutions for extranets, line of business (LOB) application integrations, or social capabilities, or whether it makes sense to build anew -- or just adopt the out of the box capabilities of your destination platform. Some best practices you might consider include identifying early and utilizing the business analysts in your organization and getting them to help drive the planning.

Its always wise to let the people and teams who own the data and systems drive as much of the planning as possible, because they are the ones who are close to the business and content and ultimately need to sign off on the migration plan (and user acceptance testing of the new system). Throughout this process, be sure to engage with your business users and change leaders frequently. Have a robust communication strategy in place. Changing management is most effective when there are strong communication mechanisms in place, providing transparency throughout the entire process.

2. Reaffirm Your Taxonomy

At the center of any knowledge management platform is your taxonomy. Without a strong taxonomy (whether automated or manually applied) your data will still grow, but your content will become less "findable." The danger with taxonomies are that it can all seem very complex and overwhelming for those without PhD's in library sciences, prompting far too many organizations to default to simple (and ineffective) taxonomy structures.

My advice is to approach it on a site level first, allowing teams to clean up what they have today and what they believe will improve data classification going forward. Then, share your commonalities at the site collection level, and so forth up the chain so that you have a clearer picture of what should be managed across the entire organization and what should be managed at lower tiers. It's important to set realistic expectations about how long it will take to get your taxonomy to a manageable level. Don't try to solve every issue during the migration, but at least start the process and make adjustments as you move your teams across.

My good friend and fellow SharePoint MVP Ben Curry (@curryben) from Summit 7 Systems shared a great phrase when discussing taxonomy development and planning during a webinar, saying "Design for those that matter, design for those that care." I love that quote because it's a reminder to prioritize your migration and planning activities around those teams and workloads that really matter (i.e. the people who rely on SharePoint to do their jobs). This includes how you approach taxonomy development.

You should always leverage what you've already built, but be sure to talk to your end users about what is working and what is not working. You can't count on your existing taxonomy usage as an indicator of what is working, as people will more than likely abandon a process if they get frustrated rather than go through the extra steps to improve the process. Communicate your taxonomy plans and get feedback.

3. Evaluate Your Information Architecture

Of course, your taxonomy is only one piece of your overall information architecture, and a migration could mean a complete restructuring of your site structure and templates, content types, and other aspects of your content and records management framework. Be aware that a re-architecture project can exceed the size of your migration, and involve every team that touches SharePoint -- which is another reason why you should prioritize your workloads and migrate in a phased approach so that you are not overwhelmed by the enormity of the effort.

Migrate in waves, building content maps for pre and post migration so that each team (and individual content owner) understands the transformation of content as it is moved from one system to the other. Do it in waves, one workload at a time. Go into it with a communication plan with clearly defined roles and responsibilities so people know what to expect. Be clear on the level of effort before migrating, and be clear on what it will take to manage afterward.

4. Establish Clear and Simple Governance Guidelines

When you have clearly defined your business requirements and the key workloads to be solved, then you can evaluate the capabilities of SharePoint and map what the business needs over what SharePoint is capable of providing. What fills the gaps and ensures those business requirements are met is your governance strategy. Governance is about mitigating risks, whether managing your intellectual property from creation through archival/deletion or meeting your auditing, compliance and other legal requirements. It's about ensuring data integrity, enforcing your change management processes, and helping you to determine the education and training needed for each role, from end user to farm administrator.

Your best practices will be determined by your legal or regulatory requirements. Once you have mapped your requirements against SharePoint's capabilities, you'll be in a much better position to be able to determine whether you should build or buy to meet those requirements. Document your environmental constraints, such as your data retention and compliance requirements, as well as Microsoft's recommendations around site and storage limitations, performance tuning, and other SharePoint standards. Review all of these things on a regular basis -- more frequently in the beginning as you add your new workloads and refine your governance strategy, until you find the right meeting cadence going forward -- and iterate on your strategy, as needed.

5. Implement Transparent Change Management

One of the most critical factors to any enterprise application deployment is having a strong change management in place. This will ensure that your migration strategy has maximum exposure within the organization and gives people a formal method for providing feedback. It's always a good thing to identify user resistance to change as early as possible, providing tools and time to help them through the migration. A mature change management process provides a 360 degree review of requirements and input from all levels of the organization, so that priorities and decisions are made out in the open.

The idea here is that the more you involve people in the process, the more likely they are to support the end results. Make it clear to people how they are involved and what is expected from them -- during the requirements process, as part of the initial pilots and user acceptance testing, and as part of the change management virtual team. Give people opportunities to share their experience and feedback and fold that learning back into your migration plans. Show them what actions you are taking, and when you think it will be delivered, leveraging social and collaborative features to mentor, educate, and communicate. You will end up with much stronger support for the final platform than you would otherwise.

While not a complete list of everything to be included in your migration planning efforts, these are the core steps to ensuring that your migration is a success and that your new environment has the necessary foundation for future growth.

Lessons Learned

Migration is not just about moving data to a new platform, but using the move as an opportunity to realize your true operational vision and to get your end users and other stakeholders involved in the process. It's a time to consider all of your business and environmental constraints, thinking about security, compliance, performance, and simplifying the platform for your end users and administrators alike.

Just remember to always focus on business needs and delivering first on those workloads that will drive the greatest return on investment. Because that is what SharePoint is for -- meeting your business needs and delivering business value.

Title image by Volodymyr Kyrylyuk / Shutterstock.com.