As we’ve previously discussed, the best way to ensure that your enterprise’s migration is a success is to build a comprehensive, fact-based migration plan, and ensure that you have a capable partner on hand to carry it out. Even once those big-picture concerns have been addressed, however, there are smaller-scale steps you can take to make your migration go smoothly.

It’s important to keep both technical concerns and user needs in mind when migrating simple content, since simple content tends to be the content used for the brunt of day-to-day work. (Migrating complex custom apps is a much more complicated process, so we’ll talk about that next post.) All deployments will deal with some variation of these concerns, though the specific details may vary by system. No matter which system you’re working with, there are things to consider on both the planning and implementation fronts; we’ll start with the planning side.

Preparing the Migration:

Your enterprise has a strong, factual migration plan in place and ready to execute. Great! But have you crossed your small-scale ts and dotted those little-detail is? This set of guidelines is intended to be doubly preventative for common migration problems – first, in the sense that this prevents certain common problems from cropping up during the migration, and second, preventative in the longer term, in that you can avoid sowing the seeds of the same problems that plagued your last deployments all over again.

One key detail is knowing how your content is going to appear in the new deployment. Moving files and simple data from one place to another isn’t always so difficult by itself, but keeping things consistent on both sides of the migration can be surprisingly tricky. Not all systems approach file names or permissions the same way, so you need to make sure you and your migration partner have a plan for dealing with that.

It’s much easier for users to get at their content and start using the new deployment if filenames aren’t mixed up or mangled in transit, the latter of which can happen if they have special characters that may not be handled the same way across different deployments. Your migration partner should have a plan in place to deal with this sort of discrepancy – CASAHL’s preferred approach is to list out the ways unsupported characters are adapted system by system ahead of time, to help keep everyone on the same page. For example, folder names containing illegal characters and character sequences will have those illegal characters replaced with underscore(s): “_”.

If filenames, folder names, and other data labels aren’t consistent between systems, it can confuse users and create opportunities for content to get misplaced or slip through the cracks. If they are consistent, it’s easier for users to pick up right where they left off, and easier for your IT team to support users through the transition. By taking care of that at the outset, you also make it much easier for tech support to ease users into the new migration if they still need help.

Permissions often have the same problem – depending on how folders are structured and shared in your old deployment, your new deployment may need some attention devoted to keeping the permissions consistent. Similarly, we’ve touched on the importance of metadata in previous posts, but making sure your metadata is maintained across systems is also critical, for more or less the same reasons that maintaining consistency across filenames and permissions is important. Missing metadata can confuse users and create usability issues in the new deployment, so you and your migration partner need to make sure your metadata matches between new and old systems, or have a system in place to convert any fields that don’t match 1:1 with the corresponding fields if they don’t line up. This means users will find all their files attributed properly to their new accounts and shared with the users who need them.

Migration time is another major consideration. Your enterprise can’t just pause work for a week to carry out a migration, much less stop work for the two to six weeks that particularly large or complex migrations take. As such, you need to plan to migrate in waves – to migrate the simple content your users access most often into the new deployment first for minimal disruption, and then prioritize the migration of other content based on its frequency of use and complexity to migrate. Migrating content in waves lets you make sure the most important, frequently used content is moved into the new deployment first and fastest – that minimizes inconvenience for users, and gives you a little more time to move less-used content over before users start to feel its absence.

Once you’ve checked those last details, it’s time to apply these principles to your enterprise’s migration.

Executing the Migration:

After you’ve figured out how to address the planning concerns laid out in the previous section, it’s time to implement the solutions. There are a couple different components to executing a simple content migration that successfully account for all of the concerns we touched on in the previous section; these are the tools you’ll need to do it.

Automated migration is the first thing you’ll want to set up; it’s a huge plus for the migration of simple content. Migrating content automatically is significantly faster than manual migration, significantly less error-prone, and speeds the whole process up immensely. It also, between the high speed of migration and low labor costs, keeps migration costs low and predictable. Automated migration is CASAHL’s recommended tool for migrating content in waves, since it lets you get your migration underway as quickly and smoothly as possible.

The second, but no less important, thing to set up is ongoing synchronization between your source and target deployments. Ongoing sync is, in effect, the practical application of the migration time consideration in the previous section. Since it takes time to implement an enterprise-scale migration, especially for enterprises with thousands of users or large collections of legacy apps, enterprises meeting those criteria should seek out ongoing sync capabilities so their users will be able to work in both new and old systems simultaneously. In those cases, the undesirability of pausing work for a month or two during migration means you’ll need a way to keep your existing content available during the migration, and this is the best way to do it.

Ongoing synchronization is also an excellent way to avoid creating data duplicates during migration. By syncing content in both directions, not just old to new, your enterprise will be able to keep all your simple content up-to-date and prevent users from accidentally creating different versions of important work projects across the two systems. You’ll be able to keep from accumulating a whole new set of de-synced data during your migration, and by doing so avoid the creation of a new mess in the process.

A secondary consideration for ongoing sync is that, if you have a legacy app that’s just too complicated and weighty to migrate, you can leave that one app in the legacy deployment and keep it synced with everything in your new deployment. This solution isn’t as good as being able to leave the legacy deployment entirely, but still lets you save a lot of money by eliminating almost all your old licenses and hardware. Ideally ongoing sync is only necessary for the duration of the migration, but in cases with especially complex applications, ongoing sync can occasionally be required indefinitely, so make sure your migration partner can support that just in case.

Ongoing synchronization can also be useful for enterprises that don’t meet those criteria if those enterprises include multiple groups using different technology or work with external partners who use different technologies. In those cases, ongoing sync can be key to success, allowing enterprises to keep their content available to partners during the migration, or allowing internal groups to consolidate their content during the migration without duplicating content.

Conclusion: What Next?

Applying these concepts to your preexisting migration plan can make the difference between a migration that goes smoothly and a migration that’s rockier, unnecessarily expensive, and more time-consuming. Keep the ideas we’ve discussed in this post in mind while migrating your simple content, and your migration will go smoothly and enable your users to hit the ground running.

By the time your enterprise has reached this stage in the migration process, you’re almost done – the last thing to do is migrate or replace any complex legacy applications your enterprise is working with. We’ll talk about migrating complex applications in our next post.