Now that the client is gone - what to do with all that notes:// links?

In your mind you drank the cool-aid and got onto IBM Verse or went to the dark side. You web enabled all of your applications ( smartly) and you are ready to turn off the Notes clients.
But then you realize: there are notes:// URLs (or their file equivalents ndl files) and doclinks spread all over your organisation: in eMails, in office documents, in applications in personal information vaults.
So you wake up and go back to the drawing board.

What is the issue at hand?

Lotus Notes was one of the first applications (as I recall, the first commercial) that made large scale use of Hyperlinks (Yep, hyperlink doesn't mean it starts with http).
Creating, storing and exchanging links to information was one of the key success components of groupware and later the world wide web (which Notes predates). A hyperlink is unidirectional, so the link target has no knowledge where hyperlinks are located pointing to it. So inspecting a target gives no indication of a potential source.
When you move a target, e.g. change or decomission the server, then you create Link Rot, the digital equivalent of Alzheimer's disease.
Removing the Notes client adds a second problem. Each Hyperlink not only has a target, but also a protocol. That is the part in front of the colon.
Most of the time you think you deal only with http or https, but there are many more: mailto (for eMail), ftp (for file transfer), cifs (for file servers), ssh (for secure shell connections), call (for VoiP), chat (for chat), sap (to call the SAP client).
Each protocol has a handler application. When you don't have a handler application for a specific protocol installed, your operating system will throw and error when you try to use it.
Like a Demo? Try it for youself!
So to replace a protocol handler application (in our case the Notes client)

Solution

You need to do 2 things:

1. In your web enablement / data migration project capture all source and target mappings. For some stuff simple formulas (regex) might do, but in most cases a key value store is required. Playing with different web technologies on wissel.net and notessensei.com, but rendering the same content, I tested the hypothesis and found key value stores suitable.
   In a nutshell: links need to live forever, come sing along
2. Create a replacement for the notes:// URL handler (and the ndl file type), so any link starting with notes:// will then be looked up in your key value store and rendered by the appropriate application.
   The little special challenge here: when you web enable applications over a period of time, you still might have a Notes client, but that specific URL is gone. When you keep your NSF and just add the webUI, this won't be an issue. But it is a problem you will face when switching the platform

Denial

Alternatively you can claim ignorance is bliss and succumb to digital dementia. The usual aguments not to act:

• the information is old, nobody needs it
• we have great search in the new application, so users will find it
• it is a waste of money and time
• We have it archived, so what's the problem
• We keep one machine with a client around, so users can look it up

If that's the prevalent line of thought in the organisation, wecome to binary lobodomy, if not, read on.

Implementation

On Windows file extensions and protocols are stored in the Windows Registry. After properly uninstalling IBM (or Lotus) Notes, there are no entries for notes:// and the Notes file extensions. For links to work, we don't need to look at nsf or ntf, since you would need a Notes client to open those. We only need to look at the notes:// protocol and the ndl extension.
The easiest way is a small helper application that posts the original URL to a web server which then would process it. To get Windows to recognise the protocol, you need to add it to the registry. The following snippet defines the protocol tango:// which you can adjust to notes:// or whatever need you have:

Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOT\tango]
@="URL:Tango Protocol"
"URL Protocol"=""

[HKEY_CLASSES_ROOT\tango\shell]
@="open"

[HKEY_CLASSES_ROOT\tango\shell\open]

[HKEY_CLASSES_ROOT\tango\shell\open\command]
@="\"C:\\bat\\test.cmd\" \"%1\""

There is a sample how to use the NSIS installer to deploy such a registry setting. Now all that is needed is a mechanism that launches your lookup to retrieve the new location. Presuming your new application would be web based, it makes sense to have the retrieval web based too. Details of such an application are subject to another time, I'll only consider how to call it for now. Your command file (in my case C:\bat\test.cmd) only needs 2 lines:

@echo off
start https://urlmapper.yourcompany.com/map?source=%1

The application would then lookup the source in the key value store and either display an 404 error page (with the option to investigate), when you didn't find that link or use a 301 redirect to open the new destination. Such a mapper application is useful not only for decommissioning a client based protocol (notes, sap, chat), but also for web revamps where URLs change in large numbers. It is important that the application reacts on http GET, since the launching of a browser only can take an URL, but not a payload for a POST command.
You might wonder why I muse removing the Notes client? Well, I'm a Domino fan and like local browser access, so I might get to the point fast where I want notes:// to point to an http(s):// URL instead
As usual YMMV.