Migrating Lotus Notes Applications to Microsoft SharePoint

While the process of migrating standard Lotus Notes applications to Microsoft SharePoint is relatively straightforward, application databases can be quite diverse, and organizations can have many custom Notes applications, as well. The complexity of all these applications can vary greatly, representing everything from trivial lists to large applications with thousands of lines of workflow processing code.

Migrating a large environment can be daunting. Not only is it hard to migrate hundreds or thousands of applications, but categorizing them presents challenges just as great. Which applications will be easy? Which will require a lot of development effort? To which kinds of targets should the various applications map? How can the cost and complexity of the migration process be controlled?

Here, we’ll discuss a practical approach to addressing Notes application complexity, and how consolidating similar applications can result in a significant level of reuse and automation of the migration process that can dramatically reduce migration costs.

Several methods for evaluating the complexity of Notes applications have been published in recent years. The most recent is Microsoft’s Design Element Index (DEI) algorithm, which suggests relative weightings for different types of design elements, and ultimately computes a complexity number from one to five.

Several good Notes environment analysis tools currently on the market include an implementation of the DEI method, similar proprietary methods, or both. A tool that scans a large environment and performs an initial ranking of complexity can be very helpful in identifying which applications merit further inspection.

However, such complexity calculations do not always adequately address the practical question of which applications will be easy to migrate and which ones will be difficult. Organizations really need a way to rank applications according to the effort required to migrate them to SharePoint, and to recognize the rare cases where SharePoint may not be the best target.

In many cases, migration is lot simpler than it first appears, and easier than an automated calculation would indicate. For example, an application with many forms, views, and agents that is a standard document library in Lotus Notes may be “complex” in an absolute sense, but map perfectly to a standard SharePoint document library, making it easy to migrate. Another completely custom application took weeks to develop and has multiple forms, actions and agents implementing an approval process, version control and document level security. But, since all of these now are checkbox features in SharePoint, and your migration tool can understand these features, the migration should be simple.

A final example may be a truly complex application – let’s call it Application D – that will take some effort to migrate. Someone needs to build SharePoint content types, custom forms and a new workflow. But, since applications E, F and G are based on the same shared Notes template, you can reuse your work migrating Application D to automate the migration of applications E, F and G.

So from a real-world practical perspective, the five levels of Notes application complexity are:

Standard applications – based on standard Lotus Notes application template; map nicely to standard SharePoint templates

Data-centric applications – have custom data schemas but no significant custom design or logic
Configuration-required applications – were custom developed in Notes, but now may be replaced with out-of-the-box SharePoint features

Medium-development applications – require development using designer tools, but don’t require deployment of custom code to SharePoint servers

Heavy-development applications – require deployment of custom code to SharePoint servers.

To understand the categories into which your applications fall, consider the features of your environment. Your version of SharePoint; your company’s policies on deploying Office clients and customizing SharePoint; your migration team’s skill set; your end user’s willingness to compromise; and your choice of a migration tool all can affect the level of migration difficulty for certain applications.