Most organizations face the question of what to do with non-KCS knowledge content that exists in a legacy knowledge base being replaced by a new KCS knowledge base. We have never seen a mass migration of legacy content work in a KCS implementation. The legacy content is not in the KCS structure, nor is it expressed in the context of the requestor. Those who have done a mass migration have ended up removing the legacy content because it disrupts findability. The investment of time and money to clean, write scripts, and move legacy knowledge is not worth it, and turns out to be counter productive.
A better strategy to deal with legacy content is to create a demand-based process that will help us identify the legacy content that has value. Keep the legacy content in a separate repository and make it available to knowledge workers to search. Let requestor demand focus our attention on the legacy content that has value. Create KCS articles in the new knowlege base for the content that is being used from the old knowledge base.
Following are some considerations that support a demand-based migration strategy:
Consortium member experience shows that 90%-95% of what is in the old knowledge base will never be referenced. With the demand-based process outlined above it doesn't take long before the knowledge workers stop searching the legacy content. And the migration effort is only spent on the content that has value.
A variation on this demand-driven theme: if our legacy system allows us to create a list of the most used items in the legacy data base, use the items on that list in the KCS training as exercises for knowledge workers to rewrite the most frequently used items as KCS articles. This is not only a great training technique, it helps seed the new knowledge base with valuable legacy content - without disrupting findability.