Introduction 

SharePoint Migrations can be simple.  The reality is that often SharePoint Migrations take a lot of time, effort, and energy…all of which translates to money spent.  On top of that, often the business and end users don’t appreciate the complexity of a SharePoint Migration, and view the process as an inconvenience thrust upon them with little warning or context.  Whether you plan to perform the migration entirely in-house, bring in a SharePoint partner to migrate for you, or somewhere in between, these three tips will help you plan a successful migration for the business, the IT team, the end users, with a leaner project budget. 

1. Take a SharePoint Inventory 

Having a detailed, thorough inventory of your SharePoint environment is the crucial first step for embarking on the SharePoint migration journey.  The inventory tells the migration team: 

  • What needs to migrate and how much is there to migrate? 
  • How many sites will they check for migration quality? 
  • What are the legacy features or customizations present and how many are there? 

A good inventory gives the migration team relevant data points for a first estimate. This first estimate will be the highest estimate you’ll see, as without further analysis, the migration team must assume that everything has to be migrated, and they will have to remediate issues with all legacy features and customizations found. 

Ok, but how do I put together this inventory?

If you are running SharePoint 2010 or 2013, Microsoft has a fantastic assessment tool, the SharePoint Migration Assessment Tool.  The SharePoint Migration Assessment Tool (SMAT) scans your SharePoint environment and generates detailed reports and a summary report, not only a list of sites but reports on legacy SharePoint features that need attention when migrating to SharePoint Online.  Microsoft also released via GitHub a tool that takes the individual reports from SMAT and creates a single workbook with some nice conditional formatting. 

Figure 1 – SharePoint Migration Assessment Tool Report

Even if you are running a SharePoint version SMAT does not yet scan, it will give you a framework to assess those environments with other means.  Usually that involves a combination of PowerShell and 3rd party tools such as ShareGate or AvePoint. 

I have an inventory!  What do I do with it? 

I know from experience one can spend a ton of time analyzing a detailed SharePoint inventory.  I always start by looking to understand a few key insights:

  • Who does each site belong to?  Can I define a business function or owner for each site? 
  • Was there activity in a site/library/list within the last 6 months to a year? 
  • If there are workflows/InfoPath forms, are they still running?  Can I look at connected lists or libraries and define when they were last run/filled out? 
  • If there are other custom components…who built these, who were they built for, and are they still using it? 

2. Define Your SharePoint Migration Flavor 

Not all migration projects are the same.  The different flavors of migrations have varying impacts on the duration, effort, and how to communicate the migration to the business and end users.  In the 10 years of delivering migrations to clients, I have found most SharePoint migrations fall into one of three flavors. 

An AS-IS Flavored Migration 

  • Why – We need to get off an unsupported, unstable, unattended SharePoint instance.  The main reason we want to migrate is to upgrade to a supported SharePoint platform (or supported operating system). 
  • Impact – AS-IS migrations require less planning and analysis, with a narrower scope as we are not opening things up for reorganization or improvements. 
  • What to tell the people – “We’re performing a SharePoint upgrade [explain reason and timeline]…we expect minimal disruption or changes to your SharePoint experience, but we wanted to share a couple of things for you to expect as we perform this update [bullets of changes with way for users to express concerns]…thank you for your patience and we’ll be in touch as the upgrade project progresses.” 

A Cleanup to Grow Flavored Migration 

  • Why – Could be a similar why to the AS-IS migration, but we want to be more intentional and specific about what we migrate. 
  • Impact – Cleanup to Grow Migrations needs more planning and analysis to find the active and important content but moving less sites and legacy features saves technical migration effort. 
  • What to tell the people – Adding onto the message for an AS-IS migration, communicate the opportunity to simplify and consolidate what we have in SharePoint, and provide guidelines going forward for how we want to best use the new SharePoint platform. 

A Cloud Transformation Migration 

  • Why – Microsoft 365 provides us with a lot of new and nuanced productivity and communication options, while in the past we have stuffed it all into SharePoint.  We want to revisit how we use SharePoint and ensure we solve the right problems with the right technology.  
  • Impact – The cloud transformation is the longest approach to a migration, but it presents the opportunity to deliver more value to the organization and reengage end users.  Taking an Agile approach to the migration helps manage budget by focusing spend on critical areas first, often revisiting priorities to tackle the next migration chunk. 
  • What to tell the people – “We’re moving to the cloud!  Don’t worry, we’re going to take our time, and we’ll be having lots of dialogue across the organization to understand how you use SharePoint now, what works, and what could be better.  We want you to get hands on with your cloud sites early on in the process, so you can give us feedback and tell us how we can make the new SharePoint better for you!” BE SURE TO SHARE THE VISION, GOALS, and TENTATIVE TIMELINE, plus WHEN/WHERE THEY’LL GET UPDATES. 

3. Talk to the People 

No matter the flavor of migration we decide on, it is essential that we perform this migration with the people in the organization.  This means communicating broadly, early, and often!  We know the end users rely upon SharePoint to perform their daily responsibilities, and even if they are unhappy with the current SharePoint instance, it is what they know and are comfortable with.  When we introduce technology changes without engaging our users on the reasons we’re migrating, the benefits we expect, and how/when they may be impacted by the migration, we risk project failure even if we deliver all the technical tasks of a migration to perfection.  A great first communication should cover three key points: 

  1. Explain the WHY behind the migration, the plan, and paint a picture of what SharePoint looks like at the end of the migration. 
  1. Really emphasize the migration team is looking for feedback and participation throughout the process and communicate how users can provide that feedback. (Do they provide it directly to the migration team, or through stakeholders who stand for different roles or groups of users?) 
  1. Set expectations for the time commitments we will ask of our users and stakeholders.  Acknowledge that everyone is busy, but this time will help the team understand the concerns and fears around this change.  The migration team is committed to addressing user feedback, and it is critical to a positive experience for everyone involved in the migration. 

We will also need to engage process owners and subject-matter experts about the variety of legacy components and customizations we found with our SharePoint Inventory.  We have done the analysis to narrow the list down to only what is active.  Now, we need to talk to the people to help us prioritize and understand those legacy features.  I approach these conversations with an open mind, plenty of curiosity, and also a few questions to try to answer by the end of the conversation: 

  • Is this legacy thing important?  What would happen if it did not work for a day?  A week? 
  • Who uses this legacy thing, and why do they use it? 
  • How does this legacy thing fit into a broader process or core business function? 
  • Does this legacy thing do everything its users want? 

Conclusion 

Migrations are complex.  I used to use a moving metaphor to help describe a SharePoint Migration. The more migrations I performed, the more I realized a SharePoint migration is not really like packing up a single house and moving it somewhere else.  It is more like packing up an entire neighborhood, sometimes even a small city, and moving it somewhere else.   

An investment of time and effort in building an accurate inventory of your SharePoint environment, intentionally selecting your migration flavor, and a commitment to talking to the people early and often will save money over the course of a migration.  The end users feel more involved in the process, and will be more open to change, simply by having the opportunity to speak out and feel heard. 

If you have questions about your upcoming migration, schedule a free consult with our migration team, and we’ll help assess where you are at in your journey.

6 + 1 =