Don't Get Blindsided By A Complex Migration

By Christian Buckley posted 12-31-2014 23:16


As I was going through images on an old external drive, I came across a series of images I used for blog posts back in 2009 and 2010 while at my old company echoTechnology (acquired by Axceler in May 2010) and getting ready for the launch of our SharePoint migration tool, Davinci Migrator. The image here brought back memories, and made me reflect on consistent mistake many organizations make as they prepare to migrate their SharePoint environments to SharePoint 2013, either on prem or online. This picture made me think of my impassioned pleas to companies getting ready to migrate to the latest version of SharePoint (at that time the 2010 version), and my advice to them to understand what kind of migration they were preparing to undergo. Sounds pretty straight forward, but there is actually a lot of depth to this question.


Whether consolidating hardware locally, or beginning your transition to the cloud, even small deployments (based on the number of sites or size of your content databases) could have great complexity. For example, what is happening with your information architecture? And do different teams (and within teams, different content types) require variants on that information architecture? Do you plan to apply homogenous governance rules and policies across all sites, all site collections, and across different governing bodies (and site owners)? Probably not. Migrations are rarely that simple, but you need to do the planning to figure out just what you need to do.


Is your migration bigger than a breadbox? Probably.

As a former business analyst and, for many years, a project manager, creating and managing process documentation -- and the change management efforts surrounding them -- was a core part of my job. For SharePoint migrations, it helps to go through the process of documenting what the current system looks like, capturing the nuances of how each team uses the platform, so that you can build a proper migration plan.

Maybe you're already a step ahead, and you have a plan? Great. Does the migration plan include a map of the sites and navigation, your taxonomy and metadata requirements, details on specific features, custom integrations and solutions that need to be transferred or rebuilt, and requirements for the handling and disposition of your various content types? Each one of these things may bring with it a set of requirements and decisions. Furthermore, is your strategy the same for the various organizations you serve? Are there special considerations for the different site collections, and if it’s a larger deployment, requirements for different farms? Do you need to reach out to multiple teams and tailor your plans for each?

One of the most compelling stories for SharePoint is its sheer extensibility. There is no such thing as a homogenous deployment – SharePoint is build-to-suit (yes, even SharePoint Online can still be designed to meet your unique collaboration requirements, even as a hosted platform in a multi-tenant environment). And as a platform that can be highly configured (and with on prem, almost infinitely customizable), which can make migrations very complex. One team may use SharePoint for their day-to-day product management efforts, and require migration of their look and feel, custom navigation, content types, and large content databases. Their system might be a high-availability, business-critical platform. Another team may only need their document libraries migrated, as they use SharePoint as more of a file share. These are two very different migrations.

The net-net here is that you need to understand the end goal of your migration. Is it a straight dump of sites, folders and content, as-is, with a plan to clean up and reorganize later? Do you plan to restructure as you migrate? Does each team in your organization have a different strategy? Answering these questions will help you properly scope your project, better understand the degree to which you'll need to plan out your new deployment, and as a result, reduce the risks associated with your SharePoint migration.