Don’t Forget About the Data!

There are two parts to every migration planning estimate for a production Domino application. Number one is to know the business processes, workflow, and functional design of your application so you can redevelop it on the best target platform. That part was covered in detail by the seven-part blog series earlier this year. You can read all about it here, Master Your Domino Application Migration Challenges. Now we are going to discuss the second part of the story in this blog, which is titled, “Don’t forget about the data!”

Successfully migrating your business applications off Domino will require transitioning the data to the new platform. Maybe not all of the data, but most likely a big chunk of it. Understanding what needs to be moved to the new repository, and how to migrate it with complete data fidelity is a key component for every migration planning project. The same is true even if the platform does not change. New UI technologies or 3rd party solutions will have their own restrictions that need to be validated.

Application migration and modernization projects are hugely expensive and can quickly run off the rails by making assumptions and underestimating the complexity of moving the historic data. So how can you pull back the curtains and inspect the data stored in your Domino apps so you can complete an accurate migration project estimate? Let’s see how our customers address the challenge with our iDNA Applications solution.

Topic 1: How many attachments? And how big are they?

One of the biggest mistakes that migration rookies make is to forget about all the attachments stored within Rich Text fields. They just count the number of records in the Domino application and don’t bother about the thousands of PDF, JPEG’s, or Excel files that require a separate migration effort to move them into the appropriate target storage format or document management system.

Deciding where to transition these files is an important consideration during the migration planning effort. And that decision might rest on different factors, such as the type of files, or the size of the files.  Domino doesn’t have a file attachment size limit, so video files or large CAD drawings could be attached to a Rich Text field inside a record.

Example Report: File Attachments by Size

Understand your attachment types

iDNA Applications maps out the file attachments by document type and size, as you can see in the associated example reports above and below. By analyzing their extension name you will quickly be able to determine the use cases for these files and where they might best be stored for simple integration with the newly designed application.

Example Report: File Attachments by Extension Name

Topic 2: How many records are we migrating? And how old are they?

The next important item for data migration planning is the number of records you need to transition. Included in this topic is a common decision point for a date cutoff to migrate records. Most organizations would like to migrate only a subset of historic records based on the date they were created. The remaining records can be kept in archive.

It’s important to be able to judge content age from multiple viewpoints (e.g. creation or modification history). This empowers your migration planning team with exact details on the amount of information they will need to migrate, along with their size references for the total data volume.

Example Report: Number of Records by Creation Date

Topic 3: Identifying the Correct Forms In-Scope for Redevelopment Effort

Another benefit of analyzing the data stored within a Domino application is that it identifies exactly what Forms are being used in production to store and reference the records. Each record in a Domino application dictates what Form is used for that record. This provides the planning team with specific insights on what Forms and Views need to be redesigned to display, create and edit the data records.

This applies to both modernization and migration projects. It doesn’t matter if you are preparing your move to a new platform or if you are putting a web or mobile interface on your applications. When a Domino application could have 100 Forms included in the design, but only 10 are being used to interact with the data, then you can reduce your redevelopment scope considerably.

Topic 4: Are there Special Rich Text Objects that Complicate Redevelopment?

Rich text fields in Domino are very flexible data types. Anything from simple text to attachments to embedded objects can be found in these fields. That same flexibility also makes it hard to display their data in an interface other than native Notes/Domino, let alone migrate the content intact to a new repository.

Seemingly trivial things like nested table structures can add a lot of complexity to redevelopment. Other things like Doc-, View- or Database-Links may require 3rd party software to make a transition seamless to the new target platform. Embedded content like OLE objects might even be a complete no-go when it comes to migration or modernization, since very few target platforms or modernization solutions can work with them. Identifying how widely these different elements are used throughout the content of a Domino application can be pivotal when choosing the right target platform and estimating the redevelopment effort.

Example Report: Special Object in Rich Text Fields
Example Report: Special Object in Rich Text Fields

Topic 5: Are there any special security considerations or access restrictions?

Finally, there are some additional considerations related to data security that can be answered through content analysis. Domino allows for several extra levels of data security beyond the simple access rights defined in the Access Control List (ACL). The two most important ones which cause issues for migration teams are Encryption and “Reader Fields”.

Encryption completely scrambles specific fields in documents, making their content inaccessible unless the key for decryption is present in the Notes ID accessing the document. “Reader Fields” work differently, but with a similar result. If you are not included within the “Reader Names” list for a specific document, then it will be hidden from view. These special security challenges should be identified before migration planning and will need to be evaluated during data export testing to assess the migration tools and ID files used for processing.

Example Report: Security Requirements for Reader Names Fields

CONCLUSION: Understand Your Domino Data, then Scope Your Migration Effort

Can you handle the truth? To make accurate, well-informed migration estimates for your Domino application environment it is important to get all the details. Don’t forget about the data. Combining the knowledge about the application design with the details about the content stored within the application will provide you with a complete understanding of what is involved for the successful transition to a new platform. These migration projects are highly visible to upper management, especially for critical business process applications that drive revenue for the company. Make sure you analyze these from all angles, so you understand the truth.

If you are interested in finding out more about our iDNA Applications solution, now with content analysis, please visit our overview page online, or sign-up for a trial at https://www-test.panagenda.com/products/idna/