Migrations aren’t easy but they’re common. They [migrations] can get a bad-rap, especially if past failed migration attempts left a bad impression on your enterprise, or perhaps inadequate planning early in the migration made for a bumpy migration (if you found yourself in the middle of a challenging migration). Regardless of where you’re at in your own migration, here are five things you should know (and are hopefully addressing):
1. Migrations are like snowflakes. From afar they all seem the same; up-close they are uniquely different from one another. Be wary of ‘recycled’ migration plans or approaches – while certain aspects of migrations to Office 365 are consistent, there are plenty of variations in source-systems, target structure, and end-user expectations across each migration. Be sure that your plan allows for adequate planning and testing to ensure all the unique parts of your migration are properly accommodated.
2. Don’t ignore the Pilot phase. Most migration plans will have some type of a Pilot phase where (at a minimum), the technical ability to move from the source system to the target system is tested. This is also a great opportunity to gather insights and intel on key factors for the full-migration, such as: Migration throughput and speed and the factors that affect it positively or negatively, common failure or challenge points with the migration, impact to the production source system (if you’re migrating from a live production environment), etc.
3. Consider if you should just lift-and-shift, or can you enhance? The lift-and-shift approach (moving your source system directly into your target system) is a common starting strategy for migrations, though this style of migration commonly isn’t the most efficient. A lift-and-shift works well in scenarios where the source system is: clean, contains up-to-date and relevant information, and is meeting all of your user’s needs. However, if your source system is old, contains outdated content, and is a common target for end-user complaints – this [migration] may be your golden ticket to not repeat the same mistakes in the new platform. Consider the value of moving something people dislike to a new platform vs. the value of moving only what is valuable to an enhanced platform. More often than not, the later option may have a higher initial price tag, but you’ll see a much higher ROI over time as the new platform will better meet your users’ needs.
4. Minimize what you’re moving. Much like long-distance moving, the less things you move, the more efficient the move will likely be. Do you really need to move all of the content from 2001’s company meeting planning collaboration site, or can you move just the final deliverables? Are the documents that haven’t been accessed or edited in more than three years actually providing anyone any value? A content inventory, and proper analysis and validation of needs by content owners can be an incredibly valuable tool. Minimize your migration, and only move the things that matter.
5. Have a contingency plan for all your critical failure points. We have a saying, if it can go wrong during a migration, it probably will. So be sure to prepare for the unknowns. Consider the various points of failure along your migration, things like source-system availability and scalability to support the migration, access to key content area owners, business-impact windows to avoid, time for re-migration for when things fail, migration continuity plans, etc. Everything from an unstable network, to a less-than-optimal SQL server, to a hard-to-reach content owner, can send your migration sideways in a moment. By planning for these occurrences, you’ll be best equipped to handle each challenge as it unfolds.
If you’re in the middle of a migration, or are considering a migration in the near future, and hadn’t considered some of these things, I hope they find their way into your migration strategy and plan. And if you’re a bit worried or need some guidance on making your migration a success, let’s talk.