2.  Write a routine to copy (duplicate) all the data from old classes to new ones. (which is not trivial at some point)

Why is it not trivial? If you're not changing class definition  three merges per class should be enough.

Also check that storage definition in the new class is the same as in old class, only pointing to the new globals.

MANAGEDEXTENT=0 may be easier to do, but it raises the risk of accidentally deleting old globals (what are these globals not corresponding to any class? Let's free some space)

Check that your XML declaration (encoding) corresponds to the actual stream).

I have a Cache-compatible sql script file and each query is separate by white space.

How do you escape white spaces in a query?

Anyway, the general approach is:

set file = ##class(%Stream.FileCharacter).%New()
do file.LinkToFile(filename)
while 'file.AtEnd {
  set query = file.ReadLine() // ???
  set rs = ##class(%SQL.Statement).%ExecDirect(, query)
  set sc = rs.%DisplayFormatted(format, outfile)
}

Where:

• filename - file with queries
• format - one of  XML, HTML, PDF, TXT or CSV.
• outfile - file to write results to

I assumed query separation by newline.

Also outfile needs to change between queries as %DisplayFormatted recreates it.

Duplicates are very similar.

You can try to use %SIMILARITY function available in Cache SQL.

You can use Session Events for logging, it provides OnStartRequest and OnEndRequest callbacks.

 Is it possible to know the user through the session, in the broker, or in the triggers?

Yes, you can store data  in %session object and retrieve it on a later date.

Also, check out my series of articles (part1, especially part2) on web debugging.

@Murray Oldfield wrote a great series of articles focused on performance and detecting bottlenecks. Check it  out.

Only after authenticated.

You'll need to:

• write authorization code
• control current authorization state 
• check that it all works as expected so  you don't consume more that one license per user

There's no reason to do that, as standard Caché tools, such as Login page provide all required capabilities.

Do you mean web-app settings like in the following screenshot?

Yes.

But why not using basic authentication? Can I consider using it?

It's way better to use CLP because this way Caché tracks authorization and licenses and you don't need to think about it in your app.

Here's some recommendations on securing REST + CSP web apps:

1. All brokers effectively have Parameter UseSession = 1;
2. REST web application and client web application allow only authenticated (i.e. password) access.
3. REST web application and client web application have reasonable Session timeout (i.e. 900, 3600).
4. REST web application and client web application have the same GroupById value.
5. REST web application and client web application have the same cookie path.

Client web application can have a custom Login Page (or just use default login page, that's okay too).