In the Rich Text migration blog, we already mentioned the Notes database ‘NMSP Views’. This database contains a set of views that can be pasted into the source database, to provide insight into the database content and structure. The information you retrieve from these views, enables you to decide which migration approach suits your goal best. This blog will present an overview which information you can retrieve from these views.
‘Notes Migrator for SharePoint (NMSP) Views’ is an empty Notes database that contains a set of Notes views. You can paste these views into a source database to get a quick overview of the content and structure of that database.
Some of the views contain an action button that you can click to display relevant information. To display this information, a form is needed. So if you use one of these buttons, don’t forget to copy the form as well.
You can download the NMSP Views database here
Many companies that want to migrate Notes data to SharePoint, ask themselves how to best store the migrated content in the SharePoint environment. In particular regarding Rich Text content, numerous possibilities exist, but none seems perfect. Depending on the goal of the migrated content (for archive, for further use), one approach is more suitable than the other. Besides that, some approaches can be eliminated, because the composition of the database content just does not allow a particular solution. In our blog http://notesapplicationmigration.com/notes-rich-text-migration-to-sharepoint-online we address this.
All design element names start with ‘zz_’ so that you can easily recover and remove them from the source database when you don’t need them any longer.
The NMSP view design elements are configured to work for a standard Notes Document Library. If you want to use these views in a Notes database with a different design, you may need to check and modify the view selection formulas and columns.
This view displays all documents by Form, and also indicates whether the document is a main document or a response document (contains a $Ref field). With this information you are able to determine which documents to filter for migration.
This view displays the number of categories per Notes document. This is important for your decision whether to migrate categories to a Managed Metadata column, or a text/choice column.
This view displays the maximum of hierarchical Category levels for each Notes document. If you want/need to display your items in a hierarchy consisting of more than 2 levels, you may decide to migrate Categories to a Managed Metadata column. The decision also depends on the information you retrieved from view ‘zz_Categories’.
This view displays when a Notes documents was last modified/created. The information may help you to decide whether the data should be archived (not used anymore), or will be actively used in the SharePoint environment.
This view displays the total size of documents. You may need this to filter/exclude documents with large attachments during migration. Files > 250 MB are not migrated, large attachments can sometimes freeze and even crash the Notes client where the migrator runs on. Best practice is to migrate the Notes documents with extremely large attachments in a separate migration job.
This view displays all documents that have a Readers field set – Private documents – and cannot be read by the current (migrator) Notes ID. The NMSP Migrator should run on a Notes ID that is able to read all documents. Documents that can’t be read by this ID are not migrated. In most cases, private documents can be read when all roles are enabled for this user in the Access Control list. If this is not the case, use button ‘Show Links (With User)’ to generate a list with private documents that you can copy to a Word document. You can send this to the mentioned user with the question to mark these documents public.
Important note: ‘Full Access Administrator’ is not supported by the NMSP Migrator.
This view displays the Replication Conflicts in the database. In the source definition, always use as part of the Record Selection formula, the following:
This view displays all response documents in the database. The selection is based on the existence of the $REF field on the document.
To find out whether the Document-Response structure is still undamaged, use button ‘Orphans and Subject’ to display the orphan responses and Subject mismatches on response documents. By doing so, you will have a better idea where all Notes data has been migrated to in the SharePoint list, in case response structures have been broken in the Notes database.
Test database, before cut/paste operations:
The following operations were performed in this database:
Test database, after cut/paste operations:
You can use the view action ‘Orphans and Subjects’ to display all orphan responses and subject mismatches in the database. Note that this action is only there to help you understand were documents are migrated to. You do not need to change your migration job.
When clicking the ‘Orphans and Subjects’ button, the following information is displayed:
This view displays the size of documents and number of attachments in documents.
When migrating to a Document Set, the job creates a PDF displaying the Rich Text Body field. This PDF has only value when there is more than just attachments in the Rich Text Field. You can use the button ‘Text in RT Field’ to find out whether there is only attachments or more in the Rich Text field. This button will generate a formula that you can use on the ‘Record Selection’ tab of the Source Data Definition.
You can use a job to migrate all documents containing attachments only in the Rich Text field (no PDF) and a job to migrate all documents containing text in the Rich Text field (PDF).
When all (or none of the) documents contain text in the Rich Text field – as shown in this example (6 of 6 containing text) – there is no need for an additional job using this formula, of course.
This view displays all main documents categorized on Subject. You can use view action ‘Show Double Subjects’ to display a list of subjects that occur more than once in the database. It also generates a piece of code that you can use in the source of your migration job. You only need this code when you are migrating multiple Notes documents to one Document Set (‘Unique by Document ID’ property of the Document Set = ‘False’).
Paste this code in the ‘_DocSetName’ formula. This will make sure that both documents (and child documents) are handled as separate items during migration.
During migration, the last 4 characters of the Notes Document Universal ID are used to make a distinction between both ‘Circus’ Document Sets:
Lialis has been in Notes development for over 20 years and the past 7 years we increasingly focus on Notes migrations primarily to SharePoint. These skills help us to make your Notes to SharePoint migration project less daunting, reduce user impact and achieve a quicker adoption of the new platform.
Please contact us here in case you are interested to learn more how we can assist