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.
- Are You Too Old to Work in Tech? IT's Midlife Crisis
- If Hadoop Disappears, Will the Label on Your Distro Matter?
- Inside Acquia's Gartner Ascension, Web CMS' Next Road Trip
- Customer Success is a Failure
- EMC Should Sell Documentum, HP Should Buy It
- SharePoint is Already Legacy
- Connecting Workers to Information in the Digital Workplace