sdsdsd

Notes rich text migration to SharePoint (online)

The Notes client is very powerful in its rich text functions.

The rich text field in a Notes document allows users to combine:

  • text (all sorts of fonts)
  • images
  • tables
  • expandable sections
  • attachments
  • OLE embedded attachments
  • links / hotspots to Notes document or other destinations
  • and much more stuff I am sure

The Notes Rich Text field is stored on a Notes form, together with other fields (text, choice, date and much more) that are used as metadata. The SharePoint counterpart of a Notes Rich Text field is a Rich Text enhanced multi-line column that you can add to your SharePoint list. This column lets you display Rich Text with pictures, tables and hyperlinks.

Except that SharePoint (Online) does not offer the same rich text features as Notes, another important difference is the storage location of the Rich Text content. Whereas Notes stores all content of a Rich Text field in a Notes Document (including images and attachments), images and attachments in a SharePoint Rich Text column are stored in a separate library. When you upload an attachment to a SharePoint list, you need to specify the SharePoint library where the attachment is stored.

The actual attachment is replaced by an icon with a link to the location of the file as shown below.

Equally, it is not possible to copy and paste an image as an embedded image into a Rich Text field in SharePoint. Only referring to the image location will display the image embedded in the Rich Text field. So in the end, all attachments and images displayed in the SharePoint Rich Text column are stored on a different location, outside the list.

In SharePoint you generally use a Custom List or a Document Library for storing data. A Document Library should be used when your main focus is on files/documents and related metadata. A Custom List should be used when fields are more important than files, for instance an Address Book.

If you want to migrate Notes Rich Text to a Custom List with a Rich Text column nonetheless, you need to carefully consider the following consequences of the mandatory storage of attachments and images in a separate library:

  • Modifying: removing the ‘file’ in the Rich Text field only removes the link to the attachment, not the attachment itself
  • Versioning: because the files are located in a different library, there is no way to version the list item and the file(s) together as one entity
  • Permissions: readers fields can be translated to item level security, but they are only applied to the list item itself, not to the migrated files in the external library

The following scenarios are working great for a Custom List as a migration target:

  • No Rich Text is involved during migration
  • There is Rich Text, but no Notes document level security (readers fields), and content is migrated for reference only (no future modifications)

Instead of a Custom List, you could also migrate to a WikiPage Library, where files can be stored within the same library. Although the disadvantages related to the Custom List also apply to the WikiPage Library, the big advantage of a WikiPage Library is that you can use the Quest NMSP ‘render’ option to simulate the Notes look within SharePoint. Additionally, the Quest NMSP job to produce this result is built in literally a few seconds, and it is working good for reference-only migration without document-level security.

In the picture below, on the left you see a simple Rich Text Notes document from a Notes Document library. On the right, you see the ‘render to SharePoint WikiPage’ migration result.

In a WikiPage Library, each Notes document is converted to an aspx file. Attachments and images can be embedded in this aspx file, but this is not recommended, because it will take longer to open each page as the size of the page becomes larger with each embedded file. The usual approach is to migrate the attachments and images to a folder within the same library (‘_Attachments’ in the example below), and replace them with links on the WikiPage itself.

In many cases though, migration of Rich Text to a Custom List or a WikiPage Library is not sufficient to meet all requirements. Although the files are now stored within the same library, they are still stored separately from the main page. This means that you still can’t apply metadata and permissions to all items related to a single WikiPage.

This is where migration to a Document Set library is a solution. A Document Set is a special type of folder for storing files. Contrary to a normal folder, a Document Set can contain metadata. When we migrate a Rich Text Notes document to a Document Set Library, we do the following:

  • All attachments, objects and images in the Notes document are migrated to a Document Set
  • Some (or all) fields are migrated to metadata of this Document Set
  • We convert the Rich Text Notes content to a PDF document that displays the structure of the Notes document, and store this PDF within the same Document Set. This PDF includes embedded images, and links to the migrated files

Below you see the same Notes document ‘Demo document’ migrated to a Document Set (note the Category hierarchy displayed in the navigator on the left).

By migrating a Notes document to a Document Set, we can keep everything from the Notes document together within one container, and apply a single set of metadata to it. Also versioning and permissions are set on Document Set level. The Document Set contains:

  • A ‘Rich Text’ PDF document displaying the content of the Rich Text Body field of the Notes document
  • The attachments, in this case 1 Word document. Images are embedded in the PDF itself, but could also be migrated as files.

In the Rich Text PDF, notice that the image is embedded in the PDF, whereas the Word attachment is a link to the actual file, stored within this Document Set:

It should be emphasized that the Notes Rich Text in the PDF is only for display purposes, and cannot be modified by the user. The PDF display should only be regarded as a ‘snapshot’: the user must forget the Rich Text potential of Notes and start to work in the SharePoint way, i.e. work with the files and the metadata of the Document Set. Although it is possible to migrate Rich Text to a Word document instead of a PDF, we do not recommend that, because of the following reasons:

  • A Word document is editable, which is not intended in this migration
  • The attachment links don’t work in Word online
  • Word online is slow

The Metadata for the Document Set apply to all items within the Document Set. In this case, only DemoDoc_Cat is added as metadata, but naturally you can apply many additional columns as metadata for the Document Set:

We also developed a way to migrate the Notes document-response structure to Document Sets. With special coding, we created the possibility to migrate a Notes response structure as a hierarchical folder structure within a Document Set. So the Document Set represents the Notes Main document, whereas the folders within the Document Set represent the responses to this Notes Main document.

As an example, we take the following Notes database:

The 4 main Notes documents in this database are migrated to 4 Document Sets in a SharePoint library called ‘NMSPDemo’. The ‘Some other migration jobs’ document set contains a subfolder for the response ‘Folder as migration target’, as you can see below. The same applies to the ‘Update Categories Agent’ folder that is migrated to a sub-subfolder.

A disadvantage of migrating a response structure to one Document Set is that the metadata of the response documents cannot be migrated. You can only apply metadata to a Document Set once (which is done for the main document), and it is not possible to create a Document Set within a Document Set.

So far in this blog, we only explained possible solutions when you want to migrate Notes documents to ‘Out Of The Box SharePoint’. However, when Notes applications start to become more complex, and the purpose is to continue working with the migrated application data similar to the Notes rich text way, a much more sophisticated solution is needed to meet the requirements. We have investigated several possible options to cater this. Our preferred solution is Shareflex.

In Shareflex, the Notes document is stored in a list (in this example called ‘Audit’). When opening the item, you notice the tabs: ‘Audit’, displaying the metadata, ‘Details’, displaying the actual Rich Text, and ‘History’, displaying the item history.

Under the ‘Audit’ tab, you will see the whole Rich Text content, including images, formatted text, attachment links etc, editable for the users. The files are listed under the Audit documents tab. When you click on the Word link under the ‘Audit Documents’ tab, you will see a preview of the Word file in the right pane (other extensions like pdf, excel, etc, are also supported).

The actual attachment is saved in a separate library, called ‘Audit Documents’ in this example. The ‘Audit Documents’ tab shows only files that are linked to this item which are displayed here. You can consider the ‘Audit Documents’ tab as the counterpart of the Notes ’embedded view’.

Shareflex allows us to migrate Notes rich text content to a SharePoint application allowing the users to continue working in the Notes way with migrated rich text and attachments in SharePoint. Users can edit the rich text in SharePoint and can add files to the Shareflex document, all combined in one SharePoint page. Versioning is supported to the main item and the files (standard SharePoint library functionality).

When the users delete the word file link in the rich text field the actual word file is still listed under documents, so users know the actual word file is not yet deleted. Security is applied to the main item and the files.

As the name suggests, Shareflex is a very flexible platform for displaying and handling data.  With XML coding, you can customize the content, workflows etc. It is possible to expand the user interface with much more tabs, for instance to display responses or other related items. Rules and timer jobs can be used to process data the way you want it.

So if you have a custom Notes application that you want to continue to use in SharePoint, Shareflex is the preferred option used in our migration projects.

Please contact us here in case you are interested to learn more about our approach and solutions.