When migrating a Notes "Document Library" to SharePoint (WSS or MOSS), customers sometimes encounter a mismatch with what SharePoint calls a Document Library.
SharePoint document libraries are organized as individual files (what the Notes world calls "attachments") in a folder hierarchy. These files have "properties" (metadata such as title, author, and whatever other fields you want to add). Notably, rich text (HTML) properties are generally not allowed on Document Library files.
Contrast this with the way many Notes "Document Libraries" are organized. Often, the users see a list of Notes documents in a view or folder. When they open one they see a formatted document consisting of various Notes fields including, in many cases, one or more Rich Text fields. Such a document may contain zero, one, or multiple file attachments. In some cases, the position of those attachments in the rich text field is also important.
Here is a Notes Migrator for SharePoint job that extracts the various parts of a Notes rich text document (attachments, images, embedded objects) into separate document library files:
This naive migration of all the "parts" to a SharePoint Document Library can yield disappointing results in several ways:
- Rich text is lost.
- Notes documents that had no attachments, images or objects are not migrated at all.
- Notes documents that had multiple attachments are now split into separate files in SharePoint with no connection.
- Additional Notes items migrated as file properties are duplicated for each file.
- Users now see a file/folder user interface instead of the view/form interface they are used to.
A slightly better approach would be to use folders to keep all the "parts" from one document together. Note that this job assigns folder names and, in addition, extract simple HTML versions of the rich text bodies.
Another possibility is to render your Notes documents as MIME (multi-part HTML) files. This option encodes all the "parts" into a single binary file that you can check into a document library.
MIME files do a good job at rendering Notes rich text, and Internet Explorer does a good job at rendering MIME files, but the problem is that there is no good tool that I know of for editing them (especially one that works with SharePoint). So this solution is for static archiving, bit for creating living, breathing documents.
So some of the above options are acceptable if you have to target a SharePoint Document Library. But for some users, they are still not good enough.
I believe that solution in many cases is to migrate to a SharePoint List instead of a Document Library. SharePoint Lists are in many ways similar to the way a typical Notes application is structured:
- Documents are presented as a list of fields laid out on a form (just like in Notes).
- Rich text fields are allowed. Most, but not all, rich text capabilities in Notes are now available in SharePoint 2007. (Be sure to specify Enhanced Rich Text as your field type.)
- List items may contain zero, one, or more file attachments. Multiple attachments remain grouped together.
Here is a Notes Migrator for SharePoint job that converts our Notes document library into SharePoint List:
Clearly this is much more "Notes like". (And yes, the DocLinks still work, but that is another post for another day.)
Admittedly, SharePoint Document Libraries have a lot of cool features that Lists do not have, such as the check-in / check-out functionality and the great Microsoft Office integration. So if you want these features, you may have some tough decisions to make. Take a look at how your Notes "Document Library" is really structured. If it is built as just a container for file attachments with not much else, it may be a smooth migration to a SharePoint Document Library. If, on the other hand, it is more form and rich text oriented, with multiple attachments per document, than you may be better off migrating to a SharePoint List.
There is one more option here that is work considering: InfoPath. Here is a Notes Migrator for SharePoint job that converts each Notes document into an InfoPath document:
More on the ins and outs of our InfoPath capabilities in a separate post.