Using this feature
When designing Target Data Definitions in Migrator for Notes to SharePoint, you can add target columns of type WordDocument. You must also specify a column Name (which is used in the field mapping process).
Specifying a Template is optional. If you do not specify one, you will always get plain word documents containing whatever rich text contents and standard properties you choose to map from Notes. If you want to specify a template, simply click on the Template property and press the details button to launch the Word Template Options dialog.
In the Word Template Options dialog you can optionally import a Microsoft Word 2007 template (.DOTX file) using the Import button. Note that a complete copy of the imported template will be saved as part of your Target Data Definition and will be used as the basis for any documents that you generate with it.
If the imported template contains any of the MSWord Content Controls that are supported by Migrator for Notes to SharePoint, and these controls are not bound to SharePoint columns or XML data, then they will appear as mappable controls in the Mappable Fields section of the dialog. The content controls that are supported are RichText, PlainText, DatePicker, ListBox, ComboBox.
Word Template Options dialog also includes a complete list of the available Mappable Fields, which are the parts of the generated Word documents that you might want to map Notes data to. This list includes the main rich text Body of the document, all the Standard Properties available in every Word document (Author, Created date, Subject, Title, Keywords, Category, Status and Revision) and well as any Custom Properties that may have been defined by the Word template you loaded.
If desired, you can customize how these Mappable Fields appear on the Mapping tab. (Recall that Migrator for Notes to SharePoint maintains the distinction between the reusable Target Data Definitions that describe the schema of your SharePoint targets and the mapping of source columns to target fields in a specific migration job.) You can clear certain Mappable Fields that you do not want to show on the Mapping tab. You can also override some of the Mappable Field properties such as the MappableName that is visible on the Mapping tab, the AutomapNames property that provides a hint as to which Notes source columns should automatically map to the target field, and the AllowMultiple property which controls when mapping of two or more source fields to one target field should be allowed.
For embedded content control type fields, you can define how the data value will be mapped to the content control using the Mapping Behavior property. This property has the following options:
Content controls in MSWord may be data bound to either SharePoint fields or XML data. We do not allow mapping to any data bound content controls as MSWord would ignore our content in favor of the bound data resulting in data loss for the user.
Note that your Target Data Definition may well contain additional target fields that are not part of the generated Word Document. In particular, you can add target columns for any additional metadata properties that should be written to the SharePoint document library, rather than inside the generated Word documents (as described in scenario #3).
You may also want to specify Folder names as well as the alternate locations for embedded attachments and OLE objects that should be migrated separately to SharePoint. These are existing features that are described elsewhere, but they apply equally well to Notes documents.
One final thing you may wish to enable in your migrated Word documents is the new "Migrate Attachment Icons" feature. While this is not always desirable when migrating to List Items, it looks pretty nice in Word Documents.
Once you save your Target Data Definition, the various parts of the WordDocument field you defined will be available on the Mapping tab.
In most cases, you will (at a minimum) want to map the Html version of your Notes documents to the Doc.Body field and map the Subject (or a similarly descriptive Notes item) to Doc.FileName. You can also add additional mappings for standard properties and custom properties as needed.
When you run the job, Migrator for Notes to SharePoint will generate one Word document for each Notes document. You can inspect the migration log for any issues.
Direct folder migration
On the Advanced tab of your Target Data Definition, you can indicate that you want to migrate to a folder in your target list or library. In this mode of operation, every record you extract from the data source will result in a folder being created, instead of a document.
The only additional requirement is that you map at least one item to a target column of type ‘Folder ‘. This controls the new folder names. Many of the usual document migration features will now apply to folders including:
Extracting information from Domino.Doc Binders
With this new feature, you can migrate all the information from your Domino.doc Binders to SharePoint folders. To support this, a new option has been added in the Domino.Doc Source Data Definitions. Simply check the Binders only radio button on the Document Selection tab. When this job is run, Binders are extracted instead of Documents.
Each row in the Preview Data Query tab represents a Binder in the current file cabinet. Additional columns have been added for all of the standard Binder metadata available in Domino.Doc. You can add additional columns to this query as well.
Putting these features together, you would typically map the {Title} property of your data source to a Folder column in your target. Simply checking Map Reader/Author fields, Preserve Created/Modified identities, and Preserve Created/Modified dates should bring over most of the other metadata but you can certainly add additional mappings if desired.
Note that this feature will only write new SharePoint folders; it will not update existing ones with the same name. So a best practice is to run the Binder migration job first (to create the folders with all the properties intact) and then run you normal document migration job. Remember that the Migrator for Notes to SharePoint migration console makes it easy to sequence multiple migration jobs for one database, and to automate these jobs for many databases of the same type.
Migrating to SharePoint publishing pages
Many Notes applications were designed primarily to publish rich content to a wide audience. These often included some type of approval process, management of draft content, and version control. These are great examples of applications that may well to the “publishing” site templates available in SharePoint Server 2013/2016/2019. Here, for example, is a rich text Notes document (with embedded images, attachments and doc links) that has been migrated to a 2010 “Publishing Portal” using Migrator for Notes to SharePoint.
If we put this page into edit mode, we can see that a great deal of out-of the-box functionality is available with no development required.
Migrator for Notes to SharePoint supports migrating any Notes content to publishing pages. This is a little more complex than doing other wiki pages or basic pages and uses the tool’s unique capability to create pages using custom ASPX template code.
If you do not already have a publishing site, create one using SharePoint Central Administration and specify one of the “Publishing” templates
Next, you need to create a “template” for generating pages from your Notes documents. Go to your new SharePoint publishing site and create a sample page by selecting Create Page from the Site Actions menu.t
Select the page layout you want for your new pages. The list of layouts may vary depending on the site template you started with and may include custom layouts designed by your site owners. Populate the page with a little sample data and save it.
Feel free to experiment with checking the page in and out, versioning it, scheduling it’s release or submitting it for approval. These are all powerful features of the SharePoint publishing templates, but you actually do not need to use them for the task at hand.
For designing a migration job, you need to extract the page to a local file so you can get an example of the ASPX layout. Select View All Site Content from the Site Actions menu and then go to the “Pages” document library.
In the Pages library, locate the test page you just created and pick Send To –> Download a Copy from the drop down menu for that page. y
Save the ASPX file to your computer and edit in any text editor. Keep this ASPX file handy, because you will be using it later.
Digression: ASPX developer’s may be interested in how this page is constructed. It inherits from a class in the Microsoft.SharePoint.Publishing namespace, but does not actually specify any HTML markup. Instead the code behind the pages uses the data in an XML data island to render the page. Notice that the XML parts specify not only content properties such as PublishingPageContent but also the page layout in the PublishingPageLayout property.
Now you have what you need to create your Migrator for Notes to SharePoint migration job. You can start from scratch or customize an existing job.
If you are starting with an existing job, first change the source Notes database to refer to your database and you may need to customize the source data definition to extract different Notes data items than the default ones specified (“Subject”, “Body”).
You should also change and target SharePoint URL to point to your publishing site. The pre-existing jobs are already configured to create new pages in the “Pages” library, place any embedded objects in the “Images” library, and place any attachments or embedded objects in the “Documents” library. This is consistent with the way things work normally when a SharePoint user created content in a publishing site, so you probably do not need to change those parts.
If you open the target data definition in the migration job, you will notice that there is a target field of type ‘PageName’ and that the PageType property of this field is set to “Template”. This PageType allows you to specify your own custom ASPX code in the PageTemplate field.
The ASPX code is what needs to be put into the PageTemplate field. Not all of it though, just the bits that describe the page structure. The content parts can be left out and, as you will see shortly, we will specify the content in a different way (mapping the data dynamically from Notes). Your ASPX page may look different, but generally you want the ASPX tags at the top (which start with “<%@”) and the <html> tag.
Notice that the target data definition also specifies several fields that allow data to be mapped as content in the generated pages. Some of these you may recognize as the properties that were specified in the XML data island (the green part). We included PublishingPageContent for mapping the Notes rich text and PublishingPageLayout for specifying the page layout. Other page types may require additional properties but you will find that many of them can be omitted as the defaults are acceptable for migrations. Title and ApprovalCode allow setting of metadata on the page. ExternalImages and ExternalAttachments allow mapping of additional files to the appropriate SharePoint libraries.
Press OK to save the target data definition. Next, go to the Mapping tab to review how various fields are set from the dynamic Notes data. Most of these mappings will make sense to an experienced Migrator for Notes to SharePoint user, but two deserve special attention.
The PublishingPageLayout is set to a constant value, which is the URL of the appropriate layout page. It is critical that you replace this value with the address of a layout page on your SharePoint server. Recall that in the newly created test page in the example, the page layout “Article page with body only” was selected. In the resulting ASPX file, this translated to the PublishingPageLayout property in the XML data island (the green bit) set to “http://quest-e52a78ada/sites/publishing/_catalogs/masterpage/PageFromDocLayout.aspx”. This is the URL that you need to use here. If you do not get this part right, your pages will not open.
The jobs are also designed to set any migrated content to the “Approved” state. This is accomplished by mapping a constant value to the ApprovalCode field. Of course you can change this to a different constant value or even make it dynamic depending on the state of your Notes document.
Depending on the page layout you selected, you may need to map other properties as well. When you are ready, press the Run Job button to start the migration.
