Migrating Lotus Notes applications to SharePoint 2007 – Part 2

Part 1 | Part 2 | Part 3  

Part 2: Application Analysis

Preparing the Inventory

First step in any migration exercise is to build an inventory of Lotus Notes databases. Not many Lotus Domino administrators can actually tell how many databases are running across all servers. The Notes Log (log.nsf) and Catalog (catalog.nsf) database on each server contain most of the information you need but its not in a consolidated and analysis-friendly format.

Preparing inventory is not a trivial exercise for customers with 10s or 100s of Domino servers spread in multiple locations. So, automation is the key here. You can write a small Lotus Notes application to do this or use of the many free tools available in the market.

• Microsoft - Application Analyzer 2006 for Lotus Domino or Microsoft Transporter Suite
• Quest - Notes Migrator for SharePoint – Discovery Edition
• Binary Tree - CMT Inspector Enterprise

You can evaluate these products and decide which one is best for your environment and requirements.

You can also watch - Microsoft Transporter Suite 2007 for Lotus Domino Demo: Application Analysis and Reporting. This click-through flash demo shows how to use the Transporter Suite 2007 for Lotus Domino to analyze your existing Lotus Domino applications and create general and custom reports for them

Recommended Read

I would recommend anyone starting on the Analysis exercise to first read the Application Analysis Envisioning Process for Lotus Domino Applications guide. This guide (authors: Scott Andersen, Lou Mandich, John Gilbert and Dirk Hamstra) discusses the Application Analysis Envisioning Process (AAEP) for Lotus Domino applications. The AAEP provides you with a process to identify and classify Lotus Domino infrastructure, understand its core components and functionality, and accurate guidance for a recommended target solution. AAEP has 4 phases:

• Phase One: Data Collection
• Phase Two: Data Analysis
• Phase Three: Target Solution Mapping
• Phase Four: Architect and Proof of Concept

In all the migration projects I have seen, these are the phases which everyone follows more or less. This guide will provide you a clarity of thought, help you plan better and optimize effort.

Analysis

The analysis of application inventory data throws up lot of useful statistics like last modified date, application usage, number of documents, database template name, which you can use to optimize the migration effort and cost. Some activities advised are:

1. Identify and Remove applications not used or needed. A very large percentage of the application databases would be used infrequently or not at all. In most customers, this figure exceeds 75%. You should identify these databases and after discussion with the relevant business owners delete/archive them
2. Archive legacy data. Some application databases contain historic non-business critical data which is used for reference infrequently and that too by few users. Check the option of exporting such data to an Excel sheet and/or File server and give it to users who might need it in future
3. Drive standardization. Many applications would be similar but not same or replicas. This happens because it's really easy to copy-paste-edit a design component or even a database in Lotus Notes. Migrating such applications to a standardized template based SharePoint Site/List would save a lot of effort and time

In some instances, at the end of analysis process, less than 10% of Lotus Notes application databases actually need migration. Rest of the databases are either deleted or data is exported and then they are archived. For complexity point of view, the migration candidates are either:

1. Simple and/or Standard Template based applications
2. Custom and/or complex applications

Target Solution

For each migration candidate, you would need to decide the target SharePoint solution. The Table below shows the most common options -

The current Microsoft Technology environment and applications should also be analyzed as options for target solution. For example, migrating a complex Lotus Notes application to an existing ASP.NET application might save you some effort and cost. In some cases, a simple data migration to an existing application might suffice the need.

Few more things to account for when deciding on target solution are:

1. Integration and Reporting needs – Tool based analysis is not perfect at detecting all the integration points the application might have with other applications or the reporting requirements. So, for complex and business critical applications, its advisable to manually go through some design components like Forms and Agents to confirm these
2. Buy vs Build decision. You might come across some home grown complex applications like – Client Relationship Management (CRM), Sales Force Automation (SFA), Help Desk, etc. If these are feature rich, then it might make sense to deploy a standard package like Microsoft Dynamics instead of trying to build all the features in SharePoint. You will save on customization effort/time and users will get a ton of additional features
3. User Experience. User experience changes completely in SharePoint so, account for these changes and the related training requirement and costs in the migration plan. Involving some power users and decision makers from the project start would help you a lot in designing most appropriate SharePoint interface and drive adoption after go-live

Proof of Concept

If you have more than one option for the target solution, it's advisable to do a quick Proof of Concept (PoC). You can also include evaluation of a migration tool as part of the PoC scope. PoC helps you in sharing the user experience and feature set with a pre-determined set of end users and get their feedback before deciding on the target solution.

After the PoC, once you have decided the target solution for each Lotus Notes application you are ready for the migration process. That's discussed in next post.