Better to use command JOB INT^SHUTDOWN instead of DO. When you use DO, the task will not be finished and will be marked as suspended, and you will have to resume it manually.

I found it many years ago. And last versions contains even much more than just a colorer. The complete parser also available there, but hidden. It would be good if InterSystems will open it to use for everybody. What would be great if InterSystems will make LanguageServer based on this parser?

The example in the documentation to %XML.Reader, does not work for you?

    #include %occStatus
    // Create a new XML Reader class
    Set reader = ##class(%XML.Reader).%New()
    // Begin processing of the XML input
    Set sc=reader.OpenFile(filename)
    If $$$ISERR(sc) Do $system.OBJ.DisplayError(sc) Quit  
    // Associate a class name with the XML element name
    Do reader.Correlate("Person","Sample.Person")
    // read Sample.Person objects from xml file
    Set Count=0
    While reader.Next(.person,.sc) {
        Write person.Name_" imported.",!
        Set Count=Count+1
        Set sc=person.%Save()
        If $$$ISERR(sc) Do $system.OBJ.DisplayError(sc) Quit  
    }
    If $$$ISERR(sc) Do $system.OBJ.DisplayError(sc) Quit  
    Write Count_" Sample.Person instances found."

ROLLBACK should revert any changes in data which was done in a transaction, with some exceptions like $increment on Global.

You can look at this example.

Class User.Test Extends %Persistent
{

Property Name As %String;

Property CalcName As %String [ Calculated, SqlComputeCode = { set {*} = {Name} }, SqlComputed, SqlComputeOnChange = Name ];

Index ByName On CalcName;

Storage Default
{
<Data name="TestDefaultData">
<Value name="1">
<Value>%%CLASSNAME</Value>
</Value>
<Value name="2">
<Value>Name</Value>
</Value>
</Data>
<DataLocation>^User.TestD</DataLocation>
<DefaultData>TestDefaultData</DefaultData>
<IdLocation>^User.TestD</IdLocation>
<IndexLocation>^User.TestI</IndexLocation>
<StreamLocation>^User.TestS</StreamLocation>
<Type>%Storage.Persistent</Type>
}

}

Let's create first object

USER>s o=##class(Test).%New()

USER>set o.Name="testname"

USER>w o.%Save()
1

check saved in globals

USER>zw ^User.TestD,^User.TestI
^User.TestD=1
^User.TestD(1)=$lb("","testname")
^User.TestI("ByName"," TESTNAME",1)=""

and now open transaction, and do some changes.

USER>k

USER>TSTART

TL1:USER>set o=##class(Test).%OpenId(1)

TL1:USER>s o.Name="testname2"

TL1:USER>w o.%Save()
1
TL1:USER>zw ^User.TestD,^User.TestI
^User.TestD=1
^User.TestD(1)=$lb("","testname2")
^User.TestI("ByName"," TESTNAME2",1)=""

So, changes there, let's do rollback, and check data again.

TL1:USER>TROLLBACK

USER>zw ^User.TestD,^User.TestI
^User.TestD=1
^User.TestD(1)=$lb("","testname")
^User.TestI("ByName"," TESTNAME",1)=""

I think it will not be possible to restore backups from Caché/Ensemble to IRIS.

I'm sure that in most cases, it is possible to just rename CACHE.DAT to IRIS.DAT, and configure it exactly as it was in Ensemble, should work. And maybe it will work for you as well.

If you can easily repeat configuration on any just installed Ensemble server, do it in the same way for IRIS.

I think we don't have any other possibilities how to catch changes in source code. Do you know how to catch if any object in any class was changed, outside of this class, if you don't have any triggers there? No easy task. But I think it is possible to find some tricky ways if you don't care about just in time notifications. You can monitor any changes in the data, and filter by changing particular globals and subscripts. 

If you will describe what are you going to achieve exactly, it will be easier to help you.

1. It is possible to develop and never use ObjectScript, but you will be limited with used language and will not most of the breakthrough features we have in Caché/IRIS. Likely with IRIS you have more capabilities, and even almost as in ObjectScript.
2. Yes, you can move from Caché to IRIS, maybe you will need some changes in your code. But it's not so much work.
   But if speaking about conversion to any other language. How do you think, is it possible to convert let's say, C# application to Python, or to Java or vice versa? This, of course, depends on, how big is your application, and how much time you ready to spend on this process. No easy way, just complete rewrite, no other ways.

Evgeny already mentioned just released preview version of IRIS 2018.2. And fortunately documentation from this version already available online,  and they offer to use new dialect  org.hibernate.dialect.InterSystemsIRISDialect. You can try to use it.

Very interesting question. Actually, it mostly depends on your application and how do you work with private data there. 

You can make application for any number of customers working in one database, with good security which does not allow to access data from one customer by another.  But in this case mostly means, that your application should be designed so, from the beginning.

Another and maybe simplest way is making separate databases for each customer. In Caché you can create multiple namespaces with different databases for each customer, but with the same database for a code of your application. So, you can update all sites at the same time.

Nowadays, I would recommend looking at containerization of application. And with kubernetes you can very fast deploy any new site with completely separate code and data between customers. But it means some work on how to prepare your application to be deployable with kubernetes.

%CacheObject was replaced with %Compiler.Type.Object. But this class was and still for internal use, how do you use it?

Why do you need so? By default with silent install, will be installed all components. But if you need to switch off some packages, you can configure really custom installation. More details in the documentation.

This rouitine should be available from %SYS namespace, and stored in CACHESYS database. All routines and globals which starts with Z,z from %SYS namespace, or %Z,%z  from any namespace will be stored there.

Well, how I would dive into this issue.

1. Run %SYS.MONLBL in production, for a relevant time gap, at least 1 hour. You can filter it by classes which you care, and get the only line counts, to decrease impact on speed.
2. So, you can collect summary time for all such Methods.
3. Change a few of them to the new way as a ClassMethod, from MONLBL you can find the list of frequently used ones. So, will be easy to find what to change.
4. Run %SYS.MONLBL with the same conditions as in the first time.
5. Compare results.
6. Decide

Of course, this way not so easy to realize, and depends on how you deploy code in production. Or maybe it even possible to measure in the testing environment.