Tips to migrate Wiki to knowledge base

[Tasha3]

We have been asked to migrate content from a Wiki site (XWiki v8.2.1 - very old, hundreds of pages) to ServiceNow knowledge. Wondering if anyone has done something similar and has any advice?

- Is manually moving content from each Wiki page to a new article our only option? How could we automate this?

- Does the "Article Type: Wiki" provide any benefits in this scenario? (From what I can tell, no. I grabbed code off of one of the Wiki pages and pasted into an article of this type, and it was really messy and much of the content appeared as Wiki code not readable content)

- Would exporting each Wiki page as HTML be better than a simple copy & paste of the content into a new article? 

Any advice welcome if you've had experience with a similar task!

Thank you!

[jonasgersbo]

In short: yes, it’s possible using an import script, scraping the contents.

We’ve done the same journey and in hindsight, I wish we had not.
Our Wiki solution was built on a concept of linking, where articles belonging to the same area were linked together. The Tiki-Wiki solution contained 26 000(!) articles, where we deemed anything not updated for the last 5 years unnecessary to import. It also contained a Service Catalogue of sorts, an entire mapping of all locations and even groups, thus the high numbers. That left us with approximately 9 000 articles to import. 

Enter the links… Not every link was possible to redirect to the corresponding, new entry (as they were pointing to entries in the old Wiki not imported), so our users requested individual wiki articles to be imported as they were ”crucial for the support”. Soon we were up to 16 000 articles.

Once the Wiki was decommissioned, we soon found out that the images and attachments were visible in the articles, whereas they were in fact still residing in the old solution. Due to a combination of imperfect coding of the script and the people handling the old solution leaving, we made a decision to pull the breaks on any attempt to restore images from entries ”being old enough to drive”. Best decision ever.

Now we’re down to 12 000 articles and still stumble upon entries lacking images or not viewed since implementation almost 5 years ago. The initially disabled valid to date and auto-retirement is now finally on its way back, which will hopefully change that number for the better.

As you mention yourself, it brings with it a lot of code garbage as well.

If your organisation is mature enough, I’d rather recommend an HTML transfer whenever a wiki entry is actually used. This way you retain the control and make sure it complies with any standards you may set.

[PrabhakarCh]

we are doing similar stuff, but from share point to KB. its not simple and direct. since KB doesn't read PDFs, we had to convert the PDFs into Word, then you need to have an Add-in plug-in which would enable to make work on online-word document in KB. Check with your NOW Account team and they can help you with.  

[David Kay · Accepted solution]

Fork-lift migrating an old knowledge base into a new system essentially always ends in tears...especially if, as I hope, you're using the migration as an opportunity to upgrade your knowledge processes and content standards.  

The approach we (and most of the KCS community) recommend is to manually migrate a small amount of content that you know for sure is being used all the time--either because you have the analytics available, or just because you know anecdotally.  Then, leave the wiki available for search.  Have people search the new ServiceNow KB first, but if they don't find the article they need there, they can search the legacy wiki.  If they find useful information, they can migrate it on demand in the new KB, using the modernized processes and standards.  (If you have a more centralized authoring model, perhaps they put in a request to migrate the legacy content rather than doing it themselves.)

After some months of this, you'll find that all of the content people are actually using has been migrated into ServiceNow, and you saved the hassle of migrating obsolete or unhelpful content from the legacy system.  In effect, you get a fresh start on your new KB without losing access to potentially useful content in the wiki.

[Tasha3]

Thanks - this seems like a sensible approach. Our Wiki is getting migrated to a new server (because the current location has reached EOS) so we should be able to implement a process of migrating the used content and avoid at least some of the tears!