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.