The analysis component of *Notes Migrator for SharePoint *calculates several complexity metrics for each database, including Microsoft’s Design Element Index (DEI) method. These are described at a high level in the documentation, but we sure do get a lot of questions about *exactly *how those numbers are computed. I will attempt to give an answer here, and then at the end of the article I will describe why you should NOT take these numbers too seriously.

Microsoft’s DEI method is really simple. (As I have said many times, it is currently TOO simple.) We just count up each type of each element and decide which DEI column it goes into, according to Microsoft’s guidance.

switch (Type)

{

case “Form”:

if (Net < 2)

return 1;

if (Net < 5)

return 2;

if (Net < 11)

return 3;

if (Net < 15)

return 4;

return 5;

case “View”:

case “Folder”:

if (Net < 5)

return 1;

if (Net < 10)

return 2;

if (Net < 20)

return 3;

if (Net < 40)

return 4;

return 5;

case “Page”:

case “StyleSheet”:

if (Net < 1)

return 1;

return 3;

case “Agent”:

if (Net < 1)

return 1;

if (Net < 5)

return 2;

if (Net < 10)

return 3;

if (Net < 20)

return 4;

return 5;

case “DatabaseScript”:

case “Subform”:

case “ScriptLibrary”:

if (Net < 1)

return 1;

return 3;

default:

return 1;

}

Based on these formulas, we get a DEI ranking for each type of element:

The max is 3 in the above case (in blue) and the average is just a simple average of the six 1’s, one 2, and five 3s (in red). (6×1 + 1×2 + 5×3) / 12 = 1.9. In version 5.0 and 5.1 we always rounded down (to 1 in this case) but in 5.2 we round up or down (2 in this case).

Quest’s complexity algorithm is probably a little more realistic than DEI, but is still suffers from the above limitations and again should be taken as a first approximation for now. One cool thing that out algorithm allows you to do is focus your manual analysis work on the templates and then let our tool calculate the INCREMENTAL complexity (based on the deltas from the template). Incremental complexity only considers the design elements that were new or modified from the associated reference database.

Plus we have Data Complexity (rich text with embedded ole objects is more complex than plain text fields, etc.)

You can decide how you want to weight the above three complexity numbers using our configuration settings.

At the end of the day, none of these algorithms look inside the actual LotusScript code to see what it does, etc. Until we start doing that (in a future version) we definitely tell people to take this as a first approximation that will tell you where to start doing manual analysis. Our tool allows you to override the automatic calculations with the results of your analysis work.

For a lot more detail on what I believe is the RIGHT way to think about application complexity, see the white paper described here: [Streamline Your Migration of Complex Notes Applications to SharePoint].

### If you like this, please share

*Related*

Thanks for the information. FYI: the document link at the end isn’t working

Fixed, thanks.