Outcome-Based Migration Planning

I’m going to go out on a limb here and say that migrations are not drag-and-drop. I know this is a very retro topic, but it’s still very relevant today. For many organizations that are looking to consolidate their various data silos, to pull together multiple versions of their SharePoint environment, their formal intranet, and other cloud storage locations. Migration continues to be a roadblock for moving forward with that strategy.

You’ve likely seen the latest features of the newest version of Microsoft 365 in its “evergreen” state. And as much of the new bells and whistles excite you about moving to the latest platform, you also recognize that an upgrade will include a major cleanup effort and untangling of customizations, sorting through 3rd party tools, and who knows what else. In short, there is nothing out-of-the-box about your environment, and the idea of a drag-and-drop migration is, at best, unrealistic.

Search the web and you’ll find plenty of content that seems helpful at first glance, but leaves you wanting. They tell you to backup your hardware. Check. Run the out-of-the-box analyzer. Check. Prepare your users. Check. But what these articles fail to provide is any kind of practical guidance.

The truth is that migrations are phased, iterative, error-prone, and not your ultimate goal.

• Migrations are phased. How and what you migrate should not be determined by the technology you use. It’s about matching the needs and timing of your content owners and teams. Migration should be flexible, helping you to move sites in content organically based on those end-user needs, not on the limitations of the technology.
• Migrations are iterative. Your planning should not be limited by the number of migration attempts you make or by the volume of content being moved. A healthy migration recognizes the need to test the waters to move sites, content, and customizations in waves, allowing users to test and provide feedback.
• Migrations are error-prone. Drag and drop SharePoint migration does not exist in the real world. Maybe for plain vanilla sites without any degree of customization, but these sites are few and far between. There is no easy button for migration.
• Migrations are not the goal. But proper planning and change management policies will help you to be successful with your current and future migrations. The goal should be a stable environment, relevant metadata, discoverable content, and happy end-users. Your move should be an outcome-based strategy focused on consolidating your content, cleaning up your information assets, and ensuring that people have an environment that they can actually use.

If you’re looking for some additional articles that outline best practices for migration planning, check out the following resources from the AvePoint blog, including migrations from the G Suite and Slack to Microsoft Teams:

• Top 5 Pre-Planning Tips for a Successful Microsoft 365 Migration, by Stephanie Racine
• Office365 and SharePoint Migration Checklist: Master Microsoft Migration, by Michael Segner
• How to Successfully Conduct a 15 TB Microsoft 365 Tenant to Tenant Migration (Case Study), by Michael Segner
• How to Get Started with Microsoft 365 Migration, by Adrian Valencia
• What to Know Before Migrating Records Management to Microsoft 365, by Brent Middleton
• G Suite to Office 365 Migration: 3 Simple Ways to Help Users Adapt, by Edmund White
• Migration Report: Moving 120GB from Slack to Microsoft Teams, by Michael Segner