I would consider, replacing the lock + and lock - with setting/killing a (temporary) global, which can be mapped to IRISTEMP for better performance, and avoid journaling. It might be easy to implement such in parallel to the current lock mechanism (add those while keep the old in place) then migrate the management page in the application to loop on this global instead of the entries in lock table. The new approach can also have the timestamp for the lock and then have a function that will auto-retain locks (kill) based on a time interval.

on any class that extends  Ens.Request or Ens.Response you may use:

Parameter COMPRESS = 2;
Property JSON As %Stream.GblChrCompress;

On large messages (or in a system with billions of messages per day) the save on storge is huge!
- Visual trace working fine
- You may search within the compressed property (but it will take time)
- Property is visible in SQL queries against Ens.MessageHeader / Ens.MessageBody 
- The "out of the box" purge working fine

instead of having each property stored with its name as a subscript, (e.g. ^Student(1,"Name") = "Alice" / ^Student(1,"Age") = 29 etc.)
its much better to use the same format the class compiler is storing data on the D global:
^Student(1)=$LB("Alice",29 ... )

when having globals with millions (or billions) of records it will have a huge impact on performance and storage footprint.

There are 2 options:

1. access the raw code for classes is stored in ^oddDEF global. all class methods are store in this format: ^oddDEF(className,"m",methodName,11)=sequence
where the sequence is 1,2,3...
If you are going to manually manipulate this don't forget to compile: do $system.OBJ.Compile("className","ckr")

2. using SQL:
SELECT ID,Name,SequenceNumber FROM %Dictionary.MethodDefinition where parent='className' order by SequenceNumber
I'm not sure if you need to compile after an UPDATE to this table (but its easy test).

1. Usually this indicates that the IRIS is sending an incomplete certificate chain
2. The fact that you can access IRIS SMP has nothing to do with the outgoing HTTPS request, which I assume you do with %Net.HttpRequest and using the SSL property that match the SSL config
3. I recommend accessing the  https://myserver.com/api/gap/... from a browser and to check the certificate chain. Usually you will see 3 certificates (root CA, intermediate authority, the certificate itself) - you should put all those certificates (one after the other) in the PEM file that is configured in the SSL config in IRIS. Depending on the CA (which might be public, or company self-generated) you need to ask your sys admin 

As Alexey said, the issue could be with code, not ECP (as usually ECP is backward compatible)
Make sure that code on app. servers in not mapped (no routine, package mapping) to a remote DB (on database server) - all code should be local to app. server

If your 3 app. servers are identical (for HA, LB reasons) then if you can disable access to 1 app. server and still working with other 2 - it will give you an option to to the app. servers one by one without downtime.

Another issue to concern is cached queries - on such upgrades its good to have all cached queries "un-freeze" to make sure all are compiled.