Avoid a Bumpy Ride with Multilingual Support Content Migration

Moving content from one support knowledge base (KB) to another is hard enough in one language, let alone in two or more. In our recent interviews with 36 global firms about how they create and manage multilingual support content, KB migration elicited the most spirited discussions. Here are five pieces of advice from our research to improve the chances that your next migration initiative will go as smoothly as possible in one language or many.

• Assume that the move will take at least six months from beginning to end. If you have more than a few hundred articles in a few languages, a half-year will give you time to develop user profiles, work through any errors, and perform additional testing. Determine how long it takes to migrate three to six articles, identify the problems, and then estimate the amount of time the full migration may require. Our research participants suggest executing a soft rollout, while keeping the old KB available for a few months.


• Designate a project manager to be in charge and enlist friendly developers. Every one of our interviewees recommends a full-time project manager for migration - and maybe more than one, depending on the size of the KB. That person should plan on completing lots of work after midnight to ensure that all parties have unimpeded access to the current knowledge base during regular working hours. If you have the luxury of in-house developers, recruit those you trust and cultivate their support throughout the process.


• Decide whether or not to clean your data prior to migration. Each approach has its pros and cons. Our interviewees generally agree that it makes more sense to clean data first if you're delivering more than a hundred articles in a few languages, especially if the move involves KBs that result from a merger or acquisition. They also recommend soliciting input from local support teams and partners about which content is the most and least valuable. However, take steps to avoid having these discussions unnecessarily prolong the migration process.

• Don't rely on scripts as magic bullets. Automation scripts tend to be more trouble than they're worth, unless you're migrating a huge library of content. Those who have used them say that there's still a large amount of manual work to perform at the end. Why? Because segmentation is often different, data trees don't sync up between databases, and things break due to formatting. Companies typically make a first pass with scripts, followed by human passes to review and fix whatever has broken. Shoot for an 80/20 solution, in which scripts handle 80% of the content, while the remaining 20% requires manual intervention.
• Migrate UI and localization processes as well. KB migration includes more than just content. Don't overlook the need to revise content creation and localization workflows, along with user interfaces, filters, and connectors. Plan to update the content of your metadata for multilingual search as a result of the content audit prior to migration. Above all, factor in enough time to test, test, and test again.

Moving multilingual support knowledge bases from one platform to another consists of many moving parts and the commitment of multiple players across various teams enterprise-wide. Although CRM and KM platforms are far from ideal for delivering localized support content, the migration process is still a great opportunity to further enhance the support experience for global customers. Recruit a good project manager who has authority, engage supportive developers, and move full-speed ahead with confidence.