Skip to main content

Our Domino State of Play 2022

It's been five years since a decision was made to kill Notes and Domino at our organisation. Like many other organisations, we left for the Azure shores of Microsoft. Several changes of leadership later and Domino is still at the heart of our organisation and we're moving towards tighter integration with it than ever. 

It occurred to me that now is as good a time as any to reflect on how our journey went. 



The Low Hanging Fruit

The low hanging fruit of any domino migration is mail. Email is an easily identifiable application which can generally be swapped out one-for-one. In our case, Notes client (and the lesser used Verse web application) for Outlook and Outlook Web Application (OWA). 

We investigated several applications before finding one that worked and converted all of our .NSF mail files into .PSTs, then we imported these into outlook. Along the way, we discovered that Verse didn't safeguard our older mail quite as well as we'd hoped and we discovered that folders didn't always translate across. 

I documented our journey in two posts back in April 2017.

The upshot is that we quickly got across to Outlook. 

Did we close down Notes mail? No. We still have agents running in applications which use Notes Mail for broadcasts. Additionally, we have semi-manual notifications systems which I've tried over the years to encourage people to use Outlook for but those same people who wanted Notes gone still won't do their broadcasts via outlook. 

Address Books

The address books turned out to be much harder to move than expected. We deliberately resisted moving to on-prem active directory. After all, we had only needed the on-prem active directory for our file servers and once all the files moved to SharePoint libraries, it was no longer necessary. 

The only problem was that the cloud implementation of AD did not have all of the nesting and embedding functionality of Notes address books, we didn't have a custom-built CRM to drive it and we still needed to keep our domino address books up to date for the databases we were yet to migrate. 

We looked for alternative solutions and investigated several very expensive products but in the end, a couple of our guys came up with a solution. 

We decided to let our existing CRM continue to drive the address books in Domino and to expand that to include the distribution groups in the Cloud AD. To do this, we built a custom database that would output a list of people in the address book every day and compare it with the previous day. This gave us all the additions and deletions as well as most of the changes. The change exceptions were when the primary key (email address) got changed, though that could be easily solved by comparing UNIDs. With this data, we were able to develop PowerShell scripts to run daily which would update the CloudAD. 

We used the same approach for groups, except that since Domino had many more groups than Office 365, our custom domino database contains a mapping for each group. In the picture below, we reference the Office365 group on the left and the Domino Groups on the right that we want merged into it. This gives us a lot more flexibility than a straight 1:1 group migrator would.

Again, the groups are exported daily and compared with the previous day. This generates a CSV that is used for import via a PowerShell script that runs on schedule and migrates the differences to Office365. Note that we rewrite the entire group in PowerShell, not just the differences. That's something we learned a long time ago. It's the safest way to ensure that everything keeps in sync and that missing a day doesn't screw anything up. 


The consensus on the address books is: provided you don't need them in Domino anymore, it's easy to migrate them but  you'll need to flatten them because nesting isn't really an option. It's possible but doesn't work very well. If you need  your groups in both systems, there's a cheaper way than buying dedicated synch software. 

One final note. We used PowerShell at the time but the recommendation going forward would be to move this to Microsoft Graph which gives you a lot more power and flexibility.

The Obvious Applications

Apart from mail, we have a bunch of applications which are obvious candidates for migration to Teams and SharePoint. There's no doubt that they can do the job just as well, if not better than Notes (minus of course, a few features like added security options, which are peculiar to our organisation).

We very quickly got these systems up and running and assembled an Office 365 proof of concept but five years later, we still haven't migrated these systems. 

As it turns out, the circles we work in are quite competitive and concerned with privacy and security. Our domino systems live on specific servers in a specific domain. The only people who access those servers are people who are authorised by our company. It's communication over the internet but the boundaries are quite specific. 

Office 365 is by contrast, a system without boundaries. You could put a file up on Office 365 and share it with your neighbour as easily as you could someone in a different country. What this means is that from the point of view of a security conscious organisation, Office 365 represents an insecure endpoint. 

It's not our company, the facilitators, who our customers are worried about. They're worried that if they let their own people have access to Office 365 systems, then they could export company secrets to competitors. Sure, email is routinely scanned for unapproved attachments but how do you police "collaboration" in general. 

To close this potential security hole, many of our member organisations decided to block access to the Office 365 cloud entirely. For this reason, we're finding that Domino is still the trusted system that we need to rely upon for collaboration.

The Complex Bespoke Applications

We moved one application away from Domino and put it onto Azure. It's not a particularly complex application but there was no off-the-shelf equivalent. We ended up having to get it externally developed. 

The costs quickly spiralled out of control and we had to de-scope it and then do a second phase of the project a few years later to add some of the missing functionality. The new interface is marginally nicer than it was but it still lacks a lot of the functionality of its domino counterpart. 

More importantly though, the costs of building the application were more than the hosting and license costs of three domino servers for 12 years. The ongoing running costs of the single application are still double that of the running costs of our entire domino infrastructure. 

The application is difficult to maintain and the frameworks it relied upon quickly went out of date necessitating some expensive upgrades and rewrites. There's just no challenging Domino's TCO model.

We're not so sure whether we'll be migrating anything else in the near future. 

The Reasons for Moving Away from Domino

I think this all comes back to the reasons for moving away from Domino in the first place -- and it's time to re-examine them. 

  1. Security: There's a feeling that because of its age, Domino must be a less secure system. We've had it audited frequently by external parties and we've put fixes in place and we're now back to maintaining it on the current version. Domino is very secure and supports modern security protocols. It also has security built-in at lower levels (for example on form and database controls) than Microsoft's systems. 

  2. Support: In 2017 it was hard to see that Domino had a future. IBM hadn't been forthcoming and wasn't actively developing it. There was a feeling that version 9 might be the last. Five years later and we're on version 12. The future with HCL seems rosy. 

  3. Standards: We were told that it would be difficult to find people who could develop domino applications because it wasn't a standard language. Thus far, this hasn't presented us with any problems and we've also proven that domino supports modern languages. Our experience with the frameworks on our bespoke database project has shown us that modern standards come and go just as quickly, perhaps even more quickly, than some of the domino standards. Every development project will incur some kind of learning curve. We're convinced that the Domino curve is easier than most. 
So, where to from here? We don't rightly know yet but one thing we do know. Domino will still be a big part of our future. One of our most recent projects has involved having Domino grant access to an Azure application using JWTs - but that's a story for another post. 

Comments

Interesting story. Thanks for sharing. I will blog about this on NCUG's web site.

However, there is one point here that I don't think is quite right:
"Office 365 is by contrast, a system without boundaries. You could put a file up on Office 365 and share it with your neighbour as easily as you could someone in a different country. What this means is that from the point of view of a security conscious organisation, Office 365 represents an insecure endpoint. "

This is not the case. In my organisation we can't share a file with anyone from the outside who hasn't been invited into our Microsoft Teams environment as an external user. So just like Domino, this can be controlled in a very detailed fashion by the administrator.

Also: In general, you can't share a file with anyone who hasn't got a Microsoft-related address. This can be a hotmail, outlook, Microsoft 365, Xbox or similar. But it must be linked to Microsoft. If you try to share a file like you can in Dropbox, with someone who hasn't got a Microsoft related address, they won't have access. Whether this is a good or bad thing depends on your point of view I guess.

Anyway, thanks for telling the world, again, that staying on Domino is most of the time the least expensive, and safest, option.

Popular posts from this blog

How to Create an Auto-Response Mail Message in Lotus Notes 8.5.3+

Why would you do this? Suppose that you have an externally accessible generic email address for your company; support@mycompany.com or info@mycompany.com. You might expose this to the web and allow people to send messages to you. Setting up an auto-response email will tell the senders that their message reached its destination and that it will be dealt with accordingly.  It's also good practice to include links to FAQs or other useful information. Why 8.5.3 The techniques we'll be using here work in older versions of Notes but some of the options seem to have moved around in 8.5.3.  I figured it was a good time to show you where they've moved to. The Procedure Start Domino Designer and open the Mail file to be modified.  A really quick way to do this is to right-click on the application tab and choose "Open in Designer". In the Left hand panel of designer, expand Code and then double-click Agents.  A new window should appear. Click the action

How to Change Your Notification Options for New Lotus Notes Mail in version 8.x

Don't worry, I'm not patronizing you (my readers), I just decided to re-document this for one of our internal users and thought you might want to be able to use it in your own user documentation. WHAT IS THIS DOCUMENT ABOUT? Some people who don't get a lot of mail, like to be notified when such an event occurs. Notification can be; via a sound via a pop-up box via the system tray (where the computer clock is) The pop up box looks like this; Other people, who like myself, get too much mail would rather not be notified. The aim of this document is to tell you how (and where) to turn these options on and off. CHANGING YOUR SETTINGS To change your settings from the Notes 8.x client; On the Menu, click File , then Preferences... On the left hand side , click on the little plus sign to the left of Mail to expand the options. Click on the option marked Sending and Receiving . In the middle section, under receiving, you can control your notifications. If you untick the

How to Do a Mail Merge to Email using Lotus Notes

Why do one? In today's "green" world, it makes much better sense to send out emails than letters but you still want to personalize them. Sadly, by itself Lotus Notes doesn't support mail merge to email. Of course, we know that outlook does (but then it lets anyone and anything send emails for you - even when you don't want them to). So, how to do it in Notes? OpenNTF The first port of call is OpenNTF ( http://www.openntf.org/ ). This place is full of great things but most of them are really badly documented. Still, these guys give things away for free and they develop in their spare time, so we should be grateful for what we get. There's a great little project there called MailMerge Excel to Notes . Go there, click on releases and download the ZIP file. Getting to the Code The installation is tricky though I've noted that since I asked the author about the install, it's been updated (so maybe these steps are less necessary). Unzip the files to som