Notes SharePoint Blog

In Part 2 [link] we examined the ins and outs of QuickPlace / QuickR migration jobs.  All the examples were using the Notes Migrator for SharePoint Designer Client, which specializes in designing and running one migration job at a time.  As discussed, QuickPlaces usually require multiple migration jobs in order to move the right content to the right type of list in SharePoint (Pages, Tasks, Discussion, Calendar, etc.).  Not only that, most QuickPlaces have multiple (sometimes hundreds of) rooms and sub-rooms, each of which would typically be migrated to a distinct SharePoint site or sub-site.  This means that migrating even a small number of QuickPlaces would get very tedious very quickly if you had to migrate each bit of content in every sub-room using the Designer Client.

Enter the other client, the Notes Migrator for SharePoint Migration Console.  This is the client that spans thousands of Notes databases instead of just one at a time and allows for a great deal of automation of your migration tasks.  This is extremely valuable in any large migration project, but is especially valuable for QuickPlace / QuickR projects.  Most QuickPlace rooms and sub-rooms are based on standard templates and, even though they tend to proliferate very quickly, they usually lend themselves to automated provisioning and automation quite nicely.

First a short word about machine requirements.  Although the tool is documented to require less, I definitely suggest that you have at least 4 GB of RAM available if you have a large environment to analyze and migrate.  Also watch out for your repository size.  If you have more than 4000 – 5000 databases you should consider splitting the project into multiple separate repositories, as described elsewhere.

(Warning!  Some of the features described below are only available in the Notes Migrator for SharePoint 5.x Premiere Edition today.  When version 6.0 is released, they will be available in the Starter and Standard Editions as well.)

Discovery

Everything in the Migration Console starts with Discovery.  This is the part where the tool scans your various Domino servers and finds all of the databases that are available there.  There are actually several types of Discovery you can perform with the product, all of which are available as actions on the main Notes Migrator for SharePoint scope node (top left) of the console. 

The first type of discovery is the general Discover Databases function.  This discovers all Notes databases on the server, regardless of whether they are really QuickPlace databases or not.  As shown below, you can pick the Domino servers you want (click on Manage Locations to add another server to the global list) and indicate that you would like to do a header analysis along the way. 

The tool attempts to classify all Notes databases based on the classification rules programmed into the tool (more on that later).  It can recognize that a database appears to be based on a QuickPlace template, but it does not attempt to look much deeper than that.  This is why you will see classes such as “QuickPlace (Unorganized Content)” in the various Notes Databases views; we have not really looked inside the database yet to see whether it is a room or sub-room and where it fits in a QuickPlace hierarchy. 

While this type of discovery is optional for a QuickPlace migration project, it can be very useful in cases where you have orphaned databases (no longer part of any hierarchy) or databases that you can’t access using your current Notes ID.  There will remain as “QuickPlace (Unorganized Content)” even after you do the deeper discovery (below).

Next you can also perform Discover QuickPlace Organization or Discover QuickR Organization operations.  As shown below, you can pick the QuickPlace servers you want (click on Manage List to add another server to the global list).  This type of discovery will crawl the metadata inside the QuickPlace databases and determine how they are structured in QuickPlace application terms of places, sub-rooms, etc.  Note that the classification of these databases will change to “QuickPlace” and “QuickPlace Sub-room”, etc., instead of just “QuickPlace (Unorganized Content)”.  More importantly, notice that you can now view the hierarchical QuickPlace application model under Applications scope node. 

Crawling a QuickPlace hierarchy is significantly slower than doing a simple database discovery.  For very large environments, where one QuickPlace might have hundreds of rooms and sub-rooms, you may want to discover just one QuickPlace at a time.  The trick to doing this is to specify a discovery location using the “<server>;<place>” format, where <place> is the short name of the QuickPlace (as you would see it in a browser URL).

Finally, you may want to perform a Discover Directory Entries operation.  This part is certainly optional, but will examine your Domino directory to determine which of your databases was mail-enabled (and many QuickPlace databases are).  This scan will even tell you what the mail address was for the mail-in databases was, which can be useful information when configuring similar behavior in Exchange/SharePoint. 

Analysis

Notes Migrator for SharePoint can help you do a great deal of analysis on each database you discovered.  Analysis is discussed in great detail in other posts, but I will summarize the capabilities here:

• Analyze usage patterns, filtering out any names that should not count as true end-users
• Analyze data complexity, including how many pages of each page type there are in each database 
• Determine which documents have blocked or oversized file attachments that will not be allowed on SharePoint
• Analyze design complexity, determining which QuickPlace rooms have been customized by end users
• Extract all the user/group names used in a QuickPlace, so you can plan how to map them to Active Directory accounts (and deal with exceptions)

Note that all Discovery and Analysis data is available in the Database Properties dialog and most of it is also available in the Migration Console views.  You can design custom views and reports that display it or simply export it all to an XML file for reporting in Excel and other tools.

Defining the rules for provisioning and migration

Now we get to the really cool part: all that Discovery work you did above was not just so you could see what you have out there on your QuickPlace servers.  All that data you collected is going to be your “home base” for managing and automating much of your migration project.  The piece that makes all this happens is your classification rules.

Underneath the Classification Rules scope node you will see both Technical Classification Rules and Business Classification Rules.  For the purposes of automating your QuickPlace migrations we will be concerned with Technical Classification Rules and, in particular, the “QuickPlace” and “QuickPlace Sub-Room” classes.  (Substitute “QuickR” and “QuickR Sub-Room” classes if that is what you have.)

If you edit the “QuickPlace” class rule properties, you will see various details about how databases of this type are recognized, analyzed and triaged.  For now, skip over to the Auto Target tab.  Check the “Enable automatic Target Identification” checkbox and then select one of your existing SharePoint site collections as the “Base Site URL”.  This sets the top level under which all new QuickPlace rooms and sub-rooms will be migrated to. 

Next, check the “Create new site for each database” checkbox and press the Options button to specify how the site will be created.  The Name and Relative URL should be variable (using the substitution codes indicated at the bottom) as this class rule will be applied to many QuickPlaces.  In example below, the URL will be formatted using the original folder path.  The name and description will include the original QuickPlace application name.  Finally you can specify the SharePoint site template you want to use (the standard SharePoint Team Site template works nicely, but feel free to specify one of your custom templates) as well as other site creation options.

Similarly you should check the “Assign targets for every child application” and “Create new sub-site for every child application” and then set the site creation options, as described above.  This will cause all QuickPlace sub-rooms to get migrated as SharePoint sub sites.  As you will see shortly this is a recursive process that could generate a tree of hundreds of sub-sites automatically!

The last item on this tab is optional.  As discussed in Part 1 of this series, QuickPlace rooms have their own menus which are often customized and are often considered an important part of the design of the QuickPlace.  Depending on your particular situation, you may elect to use the standard Quick Launch menus defined in the your SharePoint site template (selected above) or you may decide that you want to migrate the old QuickPlace menus over to SharePoint instead.  If you want to replace the standard menus with migrated QuickPlace menus, check “Provision Navigation Links” and the “Replace Links”.

IMPORTANT: The “Provision Navigation Links” function uses the dynamic Link Tracking Service and therefore requires that the service be enabled when the actual migration occurs.

Now let’s move over to the Migration Jobs tab.  Check the “Enable Automatic Migration Job” checkbox and then define the desired security mapping options.  Security mapping details are described in great detail in other posts; I will summarize by saying that the options available here controls how QuickPlace access control rules are mapped at the site level whereas individual migration jobs control how QuickPlace access control rules are mapped at the list and individual document level. 

Also note that enabling these options will require you to establish a system for mapping Notes user/group names to Active Directory identities, which is essential for a real migration but might be considered optional for a proof of concept or first test migration where you want to get quick results.

Finally we have a set of migration jobs.  Every entry here is a complete migration job, as described in Part 2 of this series.  You can add, edit and delete migration jobs using the buttons at the bottom and the pop-up migration job designer. 

Note that Notes Migrator for SharePoint includes a complete set of migration jobs for QuickPlace and QuickR and you may or may not need to edit them.  The default jobs are designed to do a nice job migrating to sites created with the standard SharePoint Team Site template. 

Note that the top level QuickPlace class has an extra job for migrating the QuickPlace Welcome page to the SharePoint site’s Announcement area.  If you do not want to do that, you can simply delete that particular job.

Good reasons for wanting to customize the migration jobs in your QuickPlace class rules include:

• You are using a different SharePoint template
• You have a different idea how lists should be named or organized
• You want to use Wiki pages, etc., instead of custom lists (the default)
• You want to enable document-level security mapping for all migration jobs
• You want to enable the Link Tracking Service for all migration jobs

Be sure to Press OK to save your work!

You should also edit the “QuickPlace Sub-Room” class rule and perform a similar set of edits.  You do not need to specify the Site Provisioning rules, as these were defined for the parent “QuickPlace” job and will applied recursively.  You should however specify Provision Navigation Links options, Security Mapping rules and Migration jobs that you want applied to any SharePoint sub-sites provisioned from your QuickPlace sub-rooms.

Assigning Targets and Jobs to Individual Databases

Now that you have defined your class rules, applying them to your actual databases is very easy.  Under the Applications scope node select the Apply Class Rules action.  Select Yes to include all the sub-rooms (recursively) and then indicate that you want to assign both the Migration Targets and Migration Jobs.  As with most Database properties, Migration Targets and Migration Jobs may be “locked” in some of your databases (because you made some manual entries), so it is usually a good idea to Override All Locks when applying the rules.

When the assignment is done, you can examine the log files to get an idea of what happened.  Even better, spot check some of the individual databases to see if things got assigned the way you expected them to.  In the example QuickPlace sub-room, the site path, the security mapping options and the migration jobs were all automatically assigned according to our rules for QuickPlace sub-rooms.

 

Note that the site shown above is indicated as a “Planned Site”.  This means that the SharePoint site does not really exist yet, but you can still assign databases and migration jobs to it.  You can even see it previewed in the tool’s SharePoint scope nodes.

You can now change any of the assigned properties for specific databases.  In fact a common way to deal with customized QuickPlaces is to first assign a complete set of default rules as described here, and then use the analysis functions of the tool to locate small end-user customizations that have occurred over the years.  You can decide on a case-by-case basis which customizations merit (for example) a customized migration job or even custom SharePoint development.

Migration Time!

There are a couple of tool configuration options (described in detail elsewhere) that you should pay attention to before migrating.

• Logging level – Use Verbose for debugging, but don’t leave it that way for large migration jobs.
• User/Group Mapping options – Needed to preserve author metadata as well as access permissions.
• Link Tracking options – Keeps doc links working, even in an extended migration project

One configuration option that many people miss is the HTTP Link Detection feature.  If you configure the tool with mappings from URL prefixes to live Domino servers, it will try to resolve any HTTP links to other web-enabled Notes or QuickPlace documents and treat them as dynamic links in our Link Tracking Service.

 

Finally it is time to migrate.  Under the Applications scope node (above) select the Migrate To SharePoint action.  Select Yes to include all the sub-rooms (recursively) and then indicate that you want to perform all provisioning and migration tasks.  (In practice, many people actually decide to provision all the sites and sub-sites first, verify those, and only then migrate all the content.)

The process described here is a “soup to nuts” approach for migrating QuickPlace / QuickR environments.  Hopefully you agree that the blend of automation and ability to customize as needed strikes the right balance, and that the trouble of setting the rules up correctly the first time more than pays for itself when you start applying those rules to large numbers of databases.