Welcome to the #dominoforever Product Ideas Forum! The place where you can submit product ideas and enhancement request. We encourage you to participate by voting on, commenting on, and creating new ideas. All new ideas will be evaluated by HCL Product Management & Engineering teams, and the next steps will be communicated. While not all submitted ideas will be executed upon, community feedback will play a key role in influencing which ideas are and when they will be implemented.
For more information and upcoming events around #dominoforever, please visit our Destination Domino Page
A Domino server knows it's Notes.ini location.
All standard notes.ini operations from formula, Lotus Script, Java and C-API will work in the same way.
On Linux and partitioned servers, the notes.ini location was always in the data directory.
If an application modifies a notes.ini directly at run-time, this is a completely unsupported operation!
Notes.ini operations at run-time of a server should always be performed using standard functionality.
All the functions remain completely unchanged no matter where the notes.ini is located.
As long no Java applications are in play, Domino 14 is an easte migration step.
Only Java applications need to be really tested in very detail because of OpenJDK 17.
But Domino 12.0.2 current fixpack is a good release to migrate to and still is on OpenJDK 8.
Customers can buy extended support. It's pretty expensive for a vendor to support this amount of code streams.
We are not sure if this is a problem specific to Japanese customers, but customers do not consider the upgrade is easy.
It takes a lot of time because hundreds of applications need to be tested to see if they will work properly after the upgrade.
For example, several customers needed to modify their applications due to the change in location of NOTES.INI in Domino14.
Upgrading Domino is quite easy, I'm sure you know tha already.
What is preventing customers from upgrading?