We have an HTML based help system, maintained with RoboHelp, that our call center staff use while fielding phone calls. It contains about 2000 individual documents that are indexed, keyworded and cross-referenced using RoboHelp's tool suite. For a number of reasons, the company has decided to eliminate RoboHelp and merge this data into SharePoint. I see so many different options to do this, and I am having a really hard time wrapping my head around what's going to work best for us. I'd love to hear any input from anyone who's experienced a similar migration. I found this question, and while mine's similar, I'm at a place where I need practical advice about more detailed circumstances.

A few notes on our environment and restrictions:

1.) We're taking advantage of this opportunity to clean up the documents, but we'll likely still end up with no less than 1750 documents.

2.) We're also taking advantage of this opportunity to analyze if the current system has optimal functionality, or if we need to design something from scratch. My guess is that our current system meets about 80% of the needs, and we'll be making some minor tweaks, but no major redesign.

3.) The current system is based on two frames: the left has a search box and a Javascript index generated out of RoboHelp's index list. To the right is the individual document. Clicking on the left nav search term or index term updates the document displayed in the right frame.

4.) Help documents are frequently cross-referenced with each other.

5.) I'm doing this project as part of a user area and am restricted in how much I can manipulate SharePoint beyond out-of-the-box client-side functionality. I do not have .NET or Designer, and am supposed to get special dispensation if I want to use CSS or Javascript to manipulate data. Preference is given to techniques that exist on the Site Administrator menu of options.

6.) SharePoint was chosen as the platform because of its low cost ($0 in additional licensing costs), ease of use, familiar look and feel of the ribbon interface, agility when making changes, change management tracking, and ease of roll-out.

Here's where things get muddled. I can see the following solutions, the associated pros and cons, but am really looking for some outside perspective to help me make sense of it all.

1.) SP Wiki. PROS: ease of interlinking and cross-referencing, ease of maintenance, ability to grow organically as procedures and policies change. CONS: Converting this volume of pages to rudimentary wiki pages seems easy; is re-creating the linkages between documents as daunting as it seems it would be?

2.) Custom List. PROS: The form-based interface for entering new data is very useable and clear for users. The "preview view" is VERY similar in functionality to the current system. CONS: no way to cross reference documents with each other, no provisions for images.

3.) Document library. PROS: Flexibility to store documents as Word or HTML. Image publishing is easier. CONS: Same import issues that I have with the Wiki. With the document library option, I'm also suffering indecision about whether Word or HTML is the best choice. HTML is, IMHO, more universal than word. However, HTML isn't in the users' skill sets as much as Word. HTML can be edited in the web-part, but Word needs to open an external program (e.g., MS-Word)

So that's where we are. Does anyone have any advice from their similar projects? Are there best practices for this type of documentation repository? I'd love to hear your thoughts!

3 Answers 3


Ok, this is a huge question but I'd like to address your 3 options specifically.

1) Wiki:

A Wiki would be ideal for this task. You are trying to create a sound knowledge base. You would have to convert each document to a web page, however this is made easier with automation. Check this out:

Enable document converters for a Web application

2) Custom List:

A custom list would allow for easy creation of new documents, but this might be overkill. A document library or wiki is more ideal for this.

That being said, there's no reason you couldn't have embedded images in your article, just use a Multiline Text field with rich text formatting. It's an OOTB option. This article shows some screen shots of how you would flip this on for a list field (you can even enable this on fields in Picture and Document Libraries via SharePoint Manager):

Rich Text Fields in SharePoint Document and Picture Libraries

3) Document Library:

An additional benefit of using a document library for your solution would be versioning for content editing in these documents, making it easier to track revisions as well as seeing historic versions of each document.

Why would it need to be one or the other, HTML vs. MS Word? You could have both and link to either from either. The URL structure is the same regardless. And you can open Word documents in the browser, and set this as the default behavior for all Word documents on the site. Microsoft would love it if the life cycle of the document was entirely within SharePoint.

To set this as the default behavior for MS Word see: Configure the default open behavior for browser-enabled documents (Office Web Apps)

General Concerns

As far as the daunting task of relinking all of the documents... yes, it is daunting and will have to be done manually... for all 1700 documents. You'll have to do that with any of these options. Guess that will be the fun part.

  • you have an interesting definition of "fun" ;) Great comments and links to explore! I'm especially intrigued by the enhanced rich text fields--and their ability to handle links between documents.
    – dwwilson66
    Aug 3, 2012 at 14:26
  • I'm from Michigan. Sarcasm just flows so naturally here. Aug 3, 2012 at 14:29
  • I'm from Wisconsin. I think it leaches into the lake and ends up here.
    – dwwilson66
    Aug 3, 2012 at 16:05

I'd probably lean to the document library approach. You can add a Related Documents column that simply looks up to that list where people can add references to those documents.

You can create a template in Word for users to easily create new documentation.

Metadata in the ribbon of the Word Client (Wikis can have metadata too) lets people add information that can be turned into search scopes.

If you upgrade SP down the line, you can utilize Office Web Applications and give users browser based Word editing.

Wikis are just OK in my opinion, they are far from anything wikilike except for the doublet bracket syntax. The rest you can do in Word and better.


You have to ask yourself what's most important? For me, it would be usability.

I would bite the bullet and do the SP Wikis for the ability of cross references, but that's just my opinion. The are easy to manage, searchability is strong, and readability would be easier than Custom Lists or the Document Libraries. As long as we are talking a long-term solution.

Also, if this is a solution that you are spending money on, you might as well spend money for third-party tools to convert your Word documents into Wiki pages, and such.

  • SharePoint has document convertors OOTB for free. Why spend money on one? Especially when the OP said a major selling point of SharePoint for his company was it's low licensing costs. Aug 3, 2012 at 14:11
  • Right now, the BIGGEST things are usability and user adoption issues--but the latter is more design issues once we choose a library to use. Obviously, though, I'm concerned that interlinking 1700 documents in a wiki may run significantly over budget on the labor side of things. Are you aware of any thrid party tools that help automate this task somehow?
    – dwwilson66
    Aug 3, 2012 at 14:15
  • Forgot about the OOTB Sharepoint document converters, and I've never had to use them. I would also look into starting small with important and the most used documents first, and work your way out. The documents that don't get used nearly as often can probably be left in their document state, so you can have an SP Wiki for widely used documents, and keep the other documents in their file format for linking from wiki pages...
    – Mike
    Aug 3, 2012 at 14:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.