When it comes to Notes application migration projects, the first thing that needs to be done is an analysis of the Notes environment. There are a lot of analysis tools on the market, and to determine application complexity many count and compare the number of design elements that make up each of the applications.  That is really not a very good indicator as there is specific code that is problematic when you migrate from a Notes client based application to a browser based application.

At a high level, you need to look at any calls that:

(1) stop the code and wait for user input (dialogbox, messagebox, picklist, prompt)

JavaScript does not support modal windows, where further code execution is stopped pending user action. Therefore, that code has to be re-visited.  In LotusScript, for example, there may be one function that calls a dialog which passes values to the remaining code. In Javascript, that needs to be split into two functions. Function 1 calls the dialog. When ‘OK’ is clicked, the second function is then called and passed the applicable values.

(2) affect document state (editmode, save, refresh)

The Notes client can track the state of the document, that is, whether it is in read mode or edit mode, and it can recompute individual values without having to reload the entire screen. A web browser, on the other hand, is stateless. It does not track whether a document is editable or not, and in order to refresh specific values, supporting code has to be provided (eg: dynamic HTML, Ajax) to do the updates.

If a LotusScript function changes a document into edit mode, moving that function to the web requires an assessment to see if the document needs to be reloaded in edit mode, or if updates can be done by sending an update to the server only. Similarly, a save or refresh type of call in a browser requires a trip to the server and either a full or partial document refresh. These calls must each be evaluated to assess the impact. A save or refresh call at the end of a function is likely to be fine and easily migrated, but will require work to be done when these calls occur mid-function.

(3) are not supported in JavaScript (goto, on error, viewnavigator, richtextnavigator)

Javascript does not support goto and on error commands. These have to be replaced by try{} catch{} or some similar type of error handling. ViewNavigator and RichTextNavigator are specific to Notes constructs and don’t have a direct migration path in Javascript. These calls need to be assessed and converted to lookups, or DOM document search type actions.

Here is sample output from the DOCOVA Notes Application Analysis tool, showing a listing of problematic code elements for a particular application:

Challenges1

The DOCOVA Analyzer looks through the individual applications for these various elements, and the number of occurrences, to come up with a complexity ranking. We call this the complex code number, or CC#.

Most customers have many applications, and the complexity can vary considerably from one to the next.  Here is an example of several Notes applications and their associated C#.

CC#

Go to our DOCOVA Migration page to register to receive a copy of our DOCOVA Notes Application Analysis tool.  There is more info available regarding DOCOVA V5, which you can use to migrate or modernize your custom Notes applications or migrate them to the SQL platform.  Access the page here.