Introduction to application complexity in Migrator for Notes to SharePoint

Hi. My name is Randy Rempel. And I'm a Senior Product Manager. Today, I'm going to briefly review application complexity in Migrator from Notes to SharePoint. Then I will briefly describe a more advanced manual approach to analyzing application complexity. Measuring application complexity can help you with your application analysis effort. There are three components to application complexity within MNSP. First, the Microsoft Design Element Index, or DEI, is based on design element counts. You can set the index to use the worst case or average index. However, I find that this index is too generic. For example, it could indicate that a document library or discussion database is very complex. Second, the data complexity index helps me understand the content of a database. For example, rich text with embedded OLE objects is more complex than plain text fields. Thus, a higher index will indicate more complex data. Third, the design complexity index uses a different algorithm than the DEI. I prefer to use the Delta setting when a reference database is used. I can use the incremental complexity index of a database to weigh the design elements that are new or modified from the associated reference database. This index is also based on design element counts. In the near future, MNSP will include the ability to search for words or terms within the code of a Notes database. Now I'd like that describe how to enhance the technical analysis details with a more manual approach to analysis of your Notes applications. I recommend that you our white paper titled, "Streamline Your Migration of Complex Notes Applications to SharePoint." The white paper details best practices for reducing the risks and costs of migrating complex Notes applications to SharePoint. Now I use information from the MNSP tool and manual analyzes of Notes applications to further categorize applications. There are three types of categorizations that I use. The first is based on technical features that are needed on the target platform. The Notes application Category Table comes from the white paper. The second categorization that I use is the Business Application type. This helps to identify the primary business purpose of the application. You can see the table for examples of business application types. The third categorization is that business application owner. This helps me to understand who owns the application. The third categorization is the business application owner. This helps me to understand who owns the application. Sometimes the business application owner prefers to use a different application platform based on their own business needs than the one that seems the best fit based on the business application type. In addition, I usually serving the application owners about each application to understand more about what needs to be migrated. It typically comes down to two questions. Do you need to use the application into the future? Does the legacy data in the application migrate to the new platform? And even does the legacy data in the application need to be archived? Thus, you will likely need a spreadsheet that contains at least the following information. I highlighted the columns in yellow that you need to enter details into. I also export the data from the MNSP tool to include at least the following supported technical details. I highlighted the columns in green that you can export from MNSP. And there are more columns that I can add to the spreadsheet. For example, I may want to indicate if the database has a parent child document hierarchy, or if the documents contain many file attachments. Or perhaps it is helpful to indicate how critical this application is to the business.