Will Holland is a Senior Software Engineer at ThreeWill. Will has proven to be adept at understanding a client’s needs and matching them with the appropriate solution. Recently he’s developed a passion for working with .NET, MVC, and cloud-based solutions such as Microsoft Azure and Office 365.
So far, we’ve addressed a handful of “Why” questions. If you’ve made it to this blog post, then it’s likely safe to assume that you’ve decided that a migration is worth the effort. Now it’s time to start asking the meaty “What” questions…the answers to which will help you lay a solid foundation towards developing your migration plan and strategies.
What is NOT being migrated? Though it may seem a little odd to have one of the first questions in a “migration” blog be “what is NOT migrating”, I assure it’s one of the most important questions you should be asking.
Most people tend to start out with “we’re just going to migrate everything”, which I understand. It certainly simplifies the decision-making process if you avoid making decisions altogether. However, you’re missing out on a huge opportunity to clean up years of cruft. Plus, there are some things that are either technically impossible or financially infeasible to migrate, such as third-party customizations.
Start making a list of rules to filter out stale or unsupported content. Rules like “If it hasn’t been updated in the past year” or “If it would require writing code to continue to support”. Then just channel your inner Marie Kondo and start tossing out stuff that won’t bring you joy to have in your new environment.
The Five Ws of a Migration – What?
If you answered the previous question, and assuming you have content remaining in your “keep” pile, it’s time to ask your self this question. More specifically, you need to spend some time analyzing the content you want migrated to determine how that scope effects your migration strategy.
What are the challenges that this content poses to a migration? Are there a lot of very large files? Are there SharePoint lists with more than 5000 items? Are there business critical sites in scope, or timing constraints caused by quarterly processes.
Identifying those risks early can help you strategize your policies on dealing with them.
You’ve been playing the role of Fate and gone through the work of defining what’s being migrated and what’s being put out to pasture. But what about the lives of the people affected by your decisions. Do you want to allow them to have a say in what happens? In most cases, the answer will be yes, although there may be some cases where you’ll need people just to play with the cards you’ve dealt them.
Assuming, though, that you need or want input, think about what choices you want to give people. You certainly want people to tell you to get rid of stuff you had thought needed to be kept if they’re no longer using it. But do you want to allow them to keep something you had initially planned to discard? Maybe you just want to give them a choice of “Delete” or “Archive”.
Communication is one of the most challenging aspects of a migration. Mainly because every organization is different in how and what they communicate to end users. Some companies want to
keep thing hush-hush to avoid panic until all the pieces are in place. Other groups may want to spread the good news.
A lot of it will just depend on your users. Are they skittish of big changes? Maybe go with softer messaging that highlight the benefits of the new platform. Or, if your users are the “early adopter” type, perhaps you give detailed messaging on the goings on of the migration.
Determining your communication strategy early can really help reduce later churn caused when confused users start interacting with your migration.
Spend some time doing some research on what tooling is available that support your migration path. If you’re migrating from a more well-known platform to another well known platform (Like SharePoint 2013 to SharePoint Online, for example), you’ll have some great choices to consider that might enable you to handle the migration on your own.
However, if you’re coming from a lesser used platform or going to latest Intranet-in-a-box startup, you might be out-of-luck and will need to either move things manually or come up with your own migration tool, at which point you might want to grab some outside help from someone with more experience.
Either way, you’ll be able to know what you need in your utility belt.
If you’ve come up with answers to all these questions, then congratulations. You’ve gone a longways towards drafting your migration plans.
You’ve identified what you’re migrating, and what can be trimmed away. You’ve come up with strategies for communicating with your userbase and decided on what inputs they’re allowed to have. Finally, you’ve identified what tools you’ll need to get the job done.
You’ve got your materials list, your equipment, and your blueprint. Now you just need to know where to start building. Next time.