As discussed previously, Notes Migrator for SharePoint 5.0 has a powerful feature for automatically provisioning an entire SharePoint site for each Notes application encountered. For example, the following Class Rule says that for each database based on the Lotus "Team Room" template, the tool should automatically create a SharePoint site (using the standard Team Site template in this case) underneath a particular site collection and should run four migration jobs to move content to the appropriate lists and libraries within that site.
Note that the new Site Name will be generated using properties from the individual Notes databases. In this case {0} will be replaced with the Database Title. If we look at the detailed Site Creation Options, we can see that substitutions can occur in a number of places.
Similarly, if your Notes application has a hierarchy of databases, you can automatically recurse through them and provision sub-sites for each child application. For example, this Class Rule says that for each room and sub-room in a Lotus QuickPlace or QuickR site, the tool should automatically create a SharePoint site or sub-site. Since large QuickPlace sites at some of our customers can have trees of dozens (or sometimes hundreds) of rooms and sub-rooms, this turns out to be an extremely useful feature.

Wow, surely you couldn't ask your migration tool to do any more than that, right? Well it turns out, you can.
We got the feedback from some customers that while this was perfect for some scenarios (such as Team Rooms and QuickPlaces) there were other cases where creating a new site for every Notes database was overkill. What some situations called for was to automatically provision new lists or libraries on an existing SharePoint site for each Notes database encountered.
So in version 5.1 (in beta as of this writing) we added a way to make the target list/library name dynamic. When managing the auto-assigned Migration Jobs for a Class, you can use the same {0} syntax described above to indicate parts that should be substituted with data from the source Notes database as jobs are assigned. You can either use the substitution syntax in the List name in the Job itself or press the Target button to override the List name without opening the Job editor.
In this example, all Notes Document Libraries will be migrated as new SharePoint lists on the same specific SharePoint site. The name of the new list will be substituted with the name of the Notes database.
So if we apply this rule to the two Document libraries in our test environment we see that the original database names were used for the new SharePoint library names.

In the last screen shot above, the green and white plus signs show a preview of the two new "planned" lists ready to be provisioned on the existing SharePoint site. These are now ready to be "bulk migrated" whenever you are ready.
As a final example of how this new feature can be used, consider Domino.Doc libraries. Here, we would often want to create a new site for each Domino.Doc library and then create a SharePoint list or library on that same site for each Domino.Doc cabinet in that library. To achieve this, we need to look at the Class rules for both the Domino.Doc Library databases and the Domino.Doc cabinet databases.
In the Domino.Doc Library class, we create a new site (using the Blank Site template this time) that has the same name as the Domino.Doc library and we indicate that we want to assign that same target site to all children (the Cabinet databases). Note that we do not run any actual content migration jobs for the Domino.Doc libraries.

In the Domino.Doc Cabinet Class, we assign content migration jobs that provision new SharePoint libraries with the same names as the Domino.Doc cabinets.
So putting these together the target site for each cabinet will be the one generated for the parent library and the target library name will be based on the cabinet name. The following screen shot shows a Domino.Doc library called "Marketing Library" with three cabinets. When the above Class rules were applied, we ended up with a plan for provisioning a blank SharePoint site called "Marketing Library" and three libraries within that.
Note that you could have still chosen to create sub-sites for each cabinet, which was the default behavior in version 5.0. You simply need to decide what you want to result to look like and set the Class rules accordingly.