Finally you decided it is time to move on, legacy no longer means " tried and tested" but " we need to move one" to you. After all you never really liked Cher.
Notes data is available via LotusScript, dotNet (through the COM bridge), in Java, Corba, C++, XML, REST, MIME, so how hard can it be? Actually not very hard, you just need to:

1. Find sutiable replacement application platform(s)
2. Rewrite the applications (don't dream: there is no such thing as "migrate an app")
3. Migrate your users
4. Migrate your data

... and then live happily ever after. Probably the easiest part is migrating the users, after all directories are more or less the same when you look at the LDAP side of them.
Migrating the users' encryption keys and secured documents could be considered "an application function", so you dodge a potential problem here.
Getting the data out, short of that pesky RichText content (yeah, the one with sections and embedded OLE controls), is easy - never mind reader and author access protection.
The transformation into the target format happens in a black box (the same the local magician uses for his tricks), you buy from a service provider, so that's covered, leaves platform and applications. (Bring your own <irony /> tags)
Lets have a look at the moving parts (Listing OpenSource components only, you can research commercial ones on your own):

• Directory : OpenLDAP comes with most Linux distributions and is well understood. It doesn't take you down the propriarty extension hell (and you can remove obsolete schema parts) - it requires an RDBMS to run (not a blue one)
• PKI : PrimeKey
• Sync Server : For the database you could get away with the database, but you need one for mobile: Z-Push
• Document Server : Pick any - or go with: Dropbox, Box, Copy etc.
• Database Server : Notes is the mother of NoSQL, so you want to pick one of those: CouchDB, OrientDB or you go with DB/2 PureXML
• Application Server : XPages is full fledged JSF, you you might opt for TomEE, but you will need some extra libraries. Or you ditch Java and adopt the cool kid on the block
• Mail Server : the venerable SendMail does, as the name implies, send mail. Goes nicely with Mozilla Thunderbird
• Web Server : That's easy. There's NGinX or Apache
• Enterprise Integration : Might be quite tricky. Domino's DECS and LEI shuffle data from all sorts of sources. OpenESB might do the trick
• Task scheduling : You can use OS level CRON (Just find a nice UI) or application level Quartz

Keep in mind, this replaces one server - Domino. Each of the tools needs to be:

1. configured
2. hardened
3. populated with data

The ease of clustering you had with Domino, gets replaced with different methods and capabilities for each of the tools. Today Cloud is the new infrastructure, so you might get lucky with someone else configuring all of the above for you.

Once you got all the moving parts in place, you need to redevelop your apps. Don't be fooled, but run the analysis, to see the full magnitude of that task ahead.
As usual YMMV

In sales school we are taught to sell value. Initially that approach was designed to defang the threat of endless haggling over price, but it took an extra twist in the software industry. Since software companies rely on user's desire to " buy the next version" to secure revenue from maintenance and upgrade sales, a feature war was the consequence.
As a result, buyers frequently request feature comparison tables, driving the proponents of "value & vision" up the wall. It also creates tension inside a sales organisation, when a customer asks for a specific feature and the seller is reprimanded for " not selling value". How can this split in expectations be reconciled? As learned in Negotiation Basics, we need to step back and see beyond positions at the interest that drives them:
The seller doesn't want to do feature to feature comparisons, since they never match and are time consuming and tedious. On the other hand showing how trustworthy, visionary and future-prove the product is, makes creating confidence much easier.
The buyer is very aware, that software doesn't have any inherit value, but only its application has. Using software requires invoking its features, so the feature comparison is a proxy for the quality of workflows it can provide in the buyer organisation. The challenge here is that any change in feature set will break somebody's workflow.
An example:
Outlook users quite often add themselves as BCC into an outgoing eMail, so the message appears in the inbox again. From there it is dragged into a folder in an archive, so it is kept in the local, not size restrained PST file where it can be found. IBM Notes doesn't allow to drag from the inbox into a specific folder in an archive. The equivalent workflow: The user doesn't need to add herself to BCC, but simply uses Send & File on the original message. The automatic scheduled Archive task moves the message later without user action required. The searchbox will find messages regardless their location in the main mail file or in one of the archives - same result, IMHO less work - but a different flow.
The solution to this is consultative selling, where a seller looks at the workflows (that are mapped to features of existing tools or practises) and proposes improved workflows based on the feature set of his products and services. A nice little challenge arises, when the flow isn't clear or the proposed product has no advantage.
A little story from the trenches to highlight this: Once upon the time, when files still were mainly paper, a sales guy tried to sell one of my customers a fax server, stating that having the fax on screen, thus eliminating the need to walk to the fax machine, would be really beneficial. He looked quite dumbfounded when the manager asked: "And how do I write on this?". The manager's workflow was to scribble instructions onto incoming faxes or document that it had been acted upon. The software couldn't do that.

In conclusion: there is a clear hierarchy in software: To have a goal and destination, there needs to be a vision, that vision needs to be supported by software that has value in implementing this vision. Value is generated by supporting and improving workflows by that software. Workflows use one or more features of the application. Comparing features is aiming one level too low, the workflows are the real value generators. A change in software most likely requires a change in workflow.

Quite a challenge!