The previous article in this series [link] discussed the basics of migrating standard Lotus QuickPlaces to SharePoint.  Now we will dive into some natural follow-up questions...

• What if I want to change the defaults (for example, migrate certain pages to a SharePoint Library instead of a List)?
• What if my QuickPlace uses custom forms or custom fields?
• What if I want select data based on complex criteria?
• What if I want to transform data as I migrate?

The key to understanding how to make all this work is to look at your Source Data Definitions.  Recall that the first tab on the Notes Migrator for SharePoint job designer is always about your data source (Notes, Domino.Doc or QuickPlace).  Depending on which of these modes you are in, the "Select Data Source" and "Edit Source Data Definition" functions will display options specific to Notes, Domino.Doc or QuickPlace.

You can think of the Source Data Definition editor as your query designer.  Not surprisingly, the QuickPlace version of this editor allows you to select pages to be migrated (the "rows") and fields to migrate (the "columns") based on constructs in the QuickPlace application model.  Even though QuickPlace sites are implemented as Notes views, forms, and items under the hood, our tool lets you think in terms of QuickPlace pages, page types, and custom fields.  Our tool also hides the fact that QuickPlace sites are implemented using multiple Notes databases and use specialized security constructs.

As discussed in Part 2 of this series [link], our tool includes five predefined Source Data Definitions for extracting QuickPlace Pages, Discussion, Calendar Entries, Contacts, and Tasks.  You can load in one of these data definitions as the starting point for designing a customized data definition or simply start a new one from scratch.  To do this, use the Edit or Create buttons on the QuickPlace tab.

The first tab of the Source Data Definition editor is the same for QuickPlace as it is for Notes and Domino.Doc.  You can specify the Name and Description of your data definition, as well as the Notes Templates that you want this Source Data Definition to be automatically associated with.  (Most Quickplace sites are based on the standard "MeetingRoom" template from Lotus, but if you use a custom place type you can associate your custom Source Data Definitions with that template.)  Finally you can specify which SharePoint List (or Library) templates this data source would most often map to.

The second tab of the Source Data Definition editor allows you to select which documents will be selected from the current QuickPlace room.  The checkboxes at the top of this tab allow you to specify which types of pages/documents should be extracted.

• Content Pages - These are the primary types of pages created when users type content into the QuickPlace user interface. These pages can contain rich text bodies and multiple attachments. Most custom page types also fall into this category.
• Imported Pages - These are pages are created when users import Word files, HTML files, etc. These pages typically contain the imported file itself, plus an HTML rendering of the file generated by QuickPlace.
• Link Pages - These pages are simple links to other pages (internal to the QuickPlace or external).
• Calendar Entries - These pages contain fields for scheduling events and contain special fields for organizing attendees, repeating meetings, etc.
• Tasks - These pages contain fields for managing to-do items and contain special fields for organizing due dates, assignees, etc.
• Discussion Pages - These pages implement a topic/response hierarchy used in threaded discussions.
• Members - These pages contain information about the team members, etc. who typically use the QuickPlace.
• Orphans - These are all the other pages that are not members of any specific view or folder in the QuickPlace (except for the Index). In practice, these pages are often out-of-date or otherwise not useful (as evidenced by the fact that there is not direct navigation to them) and they can be omitted in many migration scenarios.

For advanced jobs, you can also select documents by Folder, by Form used, or by using a dynamic Notes formula.  For example, you can select documents that are based on one of your custom page types.  Our tool's built-in form selector for QuickPlace shows both standard and custom pages types. 

While it is certainly possible to extract all the above page types at once and migrate them to a single SharePoint list or library, it is often better to differentiate between them and migrate Discussion pages to a SharePoint Discussion board, Calendar entries to a SharePoint Events list, and so on. This involves running multiple jobs for each QuickPlace (and for each sub room).  As mentioned in an earlier post, Notes Migrator for SharePoint 5.0 (now in beta) includes powerful features to help automate the running of all those jobs.  I will cover those features in much more detail soon.

The third tab of the Source Data Definition editor allows you to specify the data fields (the "columns") you want to extract from the selected QuickPlace pages.

Note that by default, this section is empty!  This is because Notes Migrator for SharePoint already knows how to extract standard QuickPlace fields such as Title, Body and Folder.  We actually make over 15 standard fields available.  Our tool expresses such "metadata" fields in curly brackets, for example {Name}, {FolderName}, {CreatedBy}, {Authors}, {FormName}, {Revision}, {Abstract} and {Attachments}. If you do not make use of custom fields, the predefined standard fields may cover your migration needs entirely.

The bottom line is that with QuickPlaces, you only have to specify the custom stuff.  This is in sharp contract to migrating "ordinary" Notes applications, where everything is "custom" and you have to specify just about everything on the Data Fields tab.

The Select Custom Form Fields button will display a list of the custom fields available in the current QuickPlace room to make it easy for you to select them.

As with "ordinary" Notes applications, you also have the option of adding Formula columns and other advanced column types.  These are not usually needed for most QuickPlace migrations and they depend on some knowledge of QuickPlace internals, but they can definitely be useful massaging data as you migrate. 

For example, if you wanted to manipulate the page name, which is normally available as the {Name} metadata column, you could create a Formula column that used the following formula:

@Uppercase(h_Name)

The Notes formula evaluator operates in the context of the underlying Notes document and does not know about Notes Migrator for SharePoint constructs.  So in addition to knowing the Notes formula language, you would have to know that QuickPlace stored names in the h_Name data item.  Again, this feature is not for everyone but it can be very powerful for doing special manipulations that we did not think of embedding in our tool (yet).

The "Preview Data Query" tab allows you to see the results of the data query you designed. You can click Test to execute the Command against live data. Any results from executing the command will be displayed in the Results window. Notice that both standard Metadata fields and custom data fields are shown.

Binary data columns (images and attachments) and MIME columns will not be shown in the preview window.  Multi-valued items will always be displayed as concatenated strings. To see the details of large data items, click on the item's cell and the full contents will be displayed in a dialog box.

Data definitions can be as simple or as sophisticated as you need them to be. To see some working examples, you can open the data definitions that are included with Notes Migrator for SharePoint and see how various features are implemented. 

Notes Migrator for SharePoint Source Data Definition files are formatted as XML text and are intended to be reusable by others who are migrating similar QuickPlaces.

Once you have finished customizing you QuickPlace Source Data Definition, you can use it just like a standard Data Definition, as described in Part 2 of this series [link].  In particular, the custom fields you defined will now be available for mapping to SharePoint.