The best way to solve this problem is to use a migration tool that can scan and classify all the Notes applications in your environment. This can be a largely automatic process. For the example above, you might set up an application class called 'Product Tracking,' and configure a set of rules to determine members of that class. Some rules for detecting 'Product Tracking' applications could include:
The application inherits from the 'XYZ Product Tracking' design template
The application title contains the string, 'Product Tracking'
The application contains a script library called 'Product Feature Approval Process'
The application manager is listed as 'Joe Cool/Acme Products'
Some rules will be more precise than others, but you should be able to automatically classify almost everything according to the design template. However, since there always are exceptions, you still will need to manually add or remove some class members.
Please note we are talking about 'similar designs,' not 'exactly the same designs' here. Even when most of the applications in your organization are built on shared templates, individual applications may have small customizations, so it's important that your migration tool can compare the design of two applications, and report on the precise differences in the application designs.
SharePoint provides two main constructs for reusing application designs: list templates, for creating new lists in the future, and site templates, for creating new sites in the future. Once you have designed, built, tested, and validated your new Product Tracking application in SharePoint, you can save it either as a list template or a site template. When you migrate the other 11 instances of that application class, you can simply instantiate additional instances in SharePoint, and migrate the data. Your migration tool should provide a way to use these custom templates when provisioning applications during migration; however, even if you must manually instantiate the applications, you still will have saved much time and energy.
You will want to reuse your migration jobs as well as your application designs. Just as SharePoint allows one person to reuse the development work of another, your migration tool should allow you to save your migration jobs so others can leverage them, as well. You can significantly streamline your migration if you save these reusable pieces in a repository and use a tool to help you apply them appropriately.
Even when you have done a great job classifying all your application types, designed reusable migration jobs for each application class, and built reusable application templates, migrating hundreds of thousands of Notes applications still is a daunting challenge. This is where automation comes in.
The combination of a rules-based classification system that automatically classifies most of your applications, and a manual mechanism for classifying exceptions, provides the ideal foundation for automating a large-scale migration process. Based on the rules established for your classification system, your migration tool should be able to automate much of your migration work. You don't have to migrate on a class-by-class basis; you can base your migration on the scheduling criteria of your choice as long as the appropriate rules are consistently applied as each application is migrated.
It's important to note that simply applying the class rules for every application encountered doesn't allow you to deal with the exceptions. Some applications based on a common Notes template may contain small customizations, so your migration process should allow for both detecting those exceptions and adjusting the default migration jobs accordingly. With that in mind, automating your migration should proceed in several steps.
1. Automatically apply the class rules to each individual application in the class. This will assign a unique set of provisioning and migration jobs to each application according to the rules of its class.
2. Scan each application for deviations from the original Notes template, and make necessary adjustments to the migration jobs assigned in the first step.
3. Run the provisioning and content migration jobs. Your migration tool should log this activity and keep track of what has been migrated.
Here's a benefit of this multi-step approach: as you assign migration jobs via the class rules and then customize them as needed, you build up a 'migration plan' that serves both as a preview of what will occur, and a script of migration steps to be taken. You can run small parts of that script and validate the results before running the whole thing, or run the script against a test SharePoint environment, validate the results and run it again against your production environment.
We've considered many aspects of migrating large, real-world Lotus Notes environments, and discussed a practical approach to thinking about application complexity. We've also noted how the cost, time and risk usually associated with large Notes-to-SharePoint migrations can be greatly reduced by consolidating similar applications. Here's a recap of the biggest leverage points you have for effectively managing the migration process:
Understand what will and will not be easy to migrate. This is different from understanding the complexity of an application in absolute terms.
Understand when out-of-the-box SharePoint features and light customization can deliver capabilities that were expensive development projects in Notes.
Take time to discover common application types used in multiple application instances in your environment, and encode them into your classification system.
Focus the bulk of your development and migration effort around reusable application templates and migration jobs that can be automated via your classification system.
Apply a migration tool that streamlines the provisioning and migration process where appropriate, yet allows you to intervene and manually deal with exceptions.
Leveraging each of these points before you begin your Notes-to-SharePoint migration will make the entire process less overwhelming, and save time, money and risk, as well.