With IBM Notes and XPages having reached an apparent end of life most companies are now giving serious thought to what they do with their Notes applications. This usually leads to a serious consideration of migrating Notes applications to another database platform such as SQL, SharePoint, SalesForce, or Mongo DB. The future of Notes Data is perhaps the one question we are asked about the most at Red Pill Now so we have decided to share our typical answers, starting with our recommendation against rushing to Migration.
The next promise to be careful of, is the one promising “out-of-the-box” solutions. These often consist of a handful of templates that can be applied for discussion databases, document libraries and team-room database. And yes, there was a time when many organizations had lots of these, but now not so much…
It is rare to find an active Notes discussion database these days. The needs of applications of this type are now better addressed through software such as Slack, Skype, Yammer, or HipChat. Providing a new web interface for a Notes discussion database is a bit like sticking a hydrofoil on the rear end of a horse and calling it a Porsche.
Like discussion databases, document libraries have also gone out of favor as Notes solutions, being replaced by specialized products such as Google Drive, One Drive, and Drop Box.
The Lotus Notes TeamRoom was in many ways an early version of what we now know as “Social Software”. Rather than extend the capability of its Social Collaboration tool (Notes), IBM instead chose to develop and sell new tools such as QuickPlace/QuickR and Connections. Other companies such as Microsoft have developed their own solutions such as SharePoint/O365. Because of this, active Notes Team Rooms have become rare in many organizations as the lack of innovation of the base template over the past ten+ years has left its capabilities well behind alternatives.
An analysis of a Notes application portfolio may suggest that a lot of existing Notes databases inherit from these basic Notes templates and good candidates for out-of-the-box solutions. Analysis of the data may suggest few of these are active, and hence the business value from keeping these applications alive is often minimal. Most organizations would be better placed migrating the underlying data directly to the 3rd party solution of choice rather than continuing to treat them as applications.
Migrations involve the transfer of data from the NSF to another database structure. Because it is rarely possible to synchronize data back to the original Notes database it becomes necessary to have a cutover from Notes to the new system. The data migration must be carefully coordinated with the adoption of the new application to minimize the disruption to the business. If more than one Notes database is integrated into the application it becomes necessary to coordinate the migration of all the associated database/applications at the same time. The potential exists for problems to occur with the data that is migrated. There is the possibility that data gets lost during the migration process. And there is the very real risk that not all the functionality contained in the original application has been found and reproduced error-free in the new application. It is often very challenging to find all the code contained in a Notes application, identify what is still being used, and then to fully understand what the code is trying to do. This is especially true if your application was written a long time ago by somebody who didn’t document what he/she did (oops).
If your organization’s Notes applications are starting to age it is almost certain that your customers are looking for an improvement in the UI/UX of the application itself, and not the underlying database. If your CIO has concerns about his/her ability to maintain these applications it probably has more to do with the fact the logic is stored in a combination of @Formula, LotusScript, and SSJS, and not that the the underlying data is stored as Text, Numbers, and Dates inside a no-SQL database. If your customers and support staff have a low opinion of Notes, it probably has more to do with the limitation of the Notes client than it does the limitation of your Domino servers.
Data migration doesn’t give you much that you don’t already have. The difference becomes even less when the data is viewed via a REST API. At that stage it hardly matters what the underlying data structure looks like. If all a data migration provides is to move the data from an NSF to something that is not an NSF you have incurred a cost and assumed a lot of business risk that doesn’t achieve a lot to address the underlying needs of your customers – how the applications look, feel, and behave.
That doesn’t mean migration is always the wrong approach. In many cases it definitely makes sense to do so. What it does mean is that you should consider carefully the total cost of getting your applications to where you, and your customers, would like and the extent to which data migration contributes to that effort. You should also consider carefully the timeframe in which you move. There is no rush, most Notes applications still run reliably. In fact, that is often the problem. If it ain’t broke don’t touch it has meant many Notes applications haven’t had to be touched for 20 years.
In my next blog article I will consider the case for keeping your data in a Notes database as a short-medium term strategy.