Thank you all for the quick responses, but: from all the server-side source control functionality I used only the possibility to extent Studio's menu by adding items to the source control menu. E.g.

XData Menu
{
<MenuBase>
<Menu Name="%SourceMenu" Type="0">
<MenuItem Name="My item 1" Save="100"/>
<MenuItem Name="My item 2" Save="100"/>
...
</Menu>
<Menu Name="%SourceContext" Type="1">
<MenuItem Name="My item 1" Save="100"/>
<MenuItem Name="My item 2" Save="100"/>
...
</Menu>
</MenuBase>
}

Can I implement something similar with VS Code?

Methods how these macros are defined are quite different: $$$ISWINDOWS is calculated using system call and always 1 on Windows platform, in contrast $$$WindowsCacheClient is defined manually, so it and can be easily set to 0 if needed.

Many years ago I faced a problem with LDAP which was solved this way (I didn't change ISC code, it was my own "fork"). Don't remember other details, only the fact.

If I could explicitly set authentication method for various parts of our instance

Apparently you can do it for each part of your instance represented as a web application. Just look in System Management Portal (SMP): System > Security Management > Web Applications: all the /csp/sys/* stuff is nothing else but SMP's function groups starting pages.

Just a small fix that makes the PublicList unnecessary:

ClassMethod Flatten(reference, Output flat)
{
    For {
        Set reference = $query(@reference)
        Quit:reference=""
        Set value = $listbuild(@reference)
        For i=1:1:$qlength(reference) {
            Set value = value_$listbuild($qsubscript(reference,i))
        }
        Set flat($i(flat)) = value
    }
}

The fixed method should be called in a slightly different way:

Method SomeMethod(...) [ PublicList = agg ]
{
  ...
  Do ..Flatten($name(agg),.summary)
  ...
}

Giving a developer the opportunity to turn off an auditing event deemed important to capture kind of defeats that purpose.

Agree with you that disabling audit events is basically a bad practice. 

The frequency and the purpose of those external calls were checked, and they are OK, while it's worth considering change $zu(-100) to something else, e.g. to command pipe, whether access to pipes is not logged to Audit.

@Robert Cemper

Agree with you, "in-place conversion" is not of great aid in real cases. Its pathos name sounds a bit confusing, isn't it?

During my first tries to transfer our Caché APP to IRIS I took an approach similar to yours, although I preferred not to use ECP as it was possible to avoid running both instances concurrently.

The funny thing I noticed: if one creates a database in Caché, renames it to IRIS.DAT, stops Caché, and starts IRIS, it will be mountable, but the reverse is wrong: renaming IRIS.DAT has been created in IRIS to CACHE.DAT doesn't make it compatible with Caché.

upgrade to 2016.2

What is the reason of this step? If OP's Cache version allows direct upgrade to 2018.1, it can be easily omitted.

OS Compatibility can be a stop factor for in-place conversion. E.g., preparing IRIS instance for a prospect, we faced a small problem with it: Cache 2017.2 (our App's supported version) turned to be incompatible with Ubuntu 18, which was chosen as on OS for IRIS.