Discover the secret to pain-free conversion
of your Lotus Notes and Domino data.
Call anytime USA toll free 1800 617 5409
Articles

A Logical Approach to Notes Migration

Over the years, the majority of development associated with Lotus Notes was all about building fancy forms and views; the amount of developers writing complex LotusScript or Java agents was quite minimal. Because of this, most simple data validation, background document processing and button event scripting was achieved with canned actions and Notes formulas. In fact, about 75 to 85 per cent of Notes and Domino applications fall into this category and, as such, the process of converting NSF to PST for this portion is relatively easy. Here are the five steps you can take when migrating this portion. Bear in mind that, when it comes to the remaining 15 to 25 per cent of highly complex applications, these steps will not suffice.

1. Inventory and sponsor

Start off by preparing an inventory containing every application that your business has developed with Lotus Notes. Then, for each of these, assign an “application sponsor” whose job it will be to have an in-depth understanding of how the application works, to justify why the application is necessary and thus deserves to be migrated, and who will arrange testing of the application once it has been migrated to the new environment.

2. Categorise

In the meantime, go ahead and begin categorising your applications. The following four categories should be used: Basic applications, which map directly to existing site templates or SharePoint lists; Medium applications, which can be mapped to customised site templates and SharePoint lists and where workflows are not included; complex applications, where workflows are included and which require a customised site template or SharePoint list; highly complex applications, which don’t really fall into any of the above and which will necessitate major development for migration. When you’re done, look at all the applications that fall into the first three categories. These are the ones we’re discussing here.

3. Analyse

Your migration team will need to analyse how every application functions and, where they’re not sure, reverse engineer the application to come up with a workable substitute. This process also involves analysing the purpose, structure and level of customisation associated with every application, including identifying which source and target fields should be mapped in migration, which external data to the migrated forms should be used in lookups, and the business logic associated with calculated fields, button-click events and more.

4. Choose

There are many third party vendors that can help you convert NSF to PST, so at this point you’ll need to select a migration tool to aid in the process. Choosing the best migration tool is crucial to lowering costs and reducing potential business down-time. While Microsoft does offer tools of its own in this regard, such as SharePoint Designer, InfoPath Designer and Visual Studio, unfortunately these pieces of software are not capable of handling large migrations, and using them will end up costing more.

5. Migrate

With the above steps completed, it’s time to let the migration process begin. This essentially involves plowing through each application one by one, testing each in its new form to ensure there are no bugs or errors, and then ticking it off your list.

Leave a reply