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.
- Migrating Mail from Notes and Verse to Outlook and Office 365 - Part 1
- Migrating Mail from Notes and Verse to Outlook and Office 365 - Part 2
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.
- 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.
- 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.
- 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.
Comments
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.