The manual says I should (in short):

1. Stop journaling with ^JRNSTOP

Which manual does it say? Any manual I've read last 20 years says quite opposite: never stop journaling unless you want to get your system in troubles.
It seems that you should not bother on the subject at all: during the database restore it can't be involved in any users' activity, so there would not exist any journal record on its change.

Evgeniy, thank you for sharing your experience.

there is one table that contains 11,330,263 rows at the time of writing. Not so critically much, but it creates delays. Even the query to count the number of rows takes almost 30 seconds

Looking just at the number of rows, one apparently can't consider such a table to be a big one.
What was the size (in GB) of the underlining global?

Alas, it has the similar problem as my original solution: 

w ##class(z.Scratch).Detector("azazz","zaaza") ;should be 0
1

So, my feeling was right... It's time to quit this golf club for now, at least for me )))

Yes, it can be, while this approach can't win, as I already understood. Size = 67: 

ClassMethod Detector(a As %String, b As %String) As %Boolean
{
 s a=$zu(28,a,6),b=$zu(28,b,6) q $tr(a,b)=$tr(b,a)&($l(a)=$l(b))
}

size = 83

ClassMethod Detector(a As %String, b As %String) As %Boolean
{
  f c="a","b"{s @c=$zstrip($zcvt(@c,"U"),"*W")} q $tr(a,b)=$tr(b,a)&($l(a)=$l(b))
}

This change seems to be applicable to IRIS only.
In Cache log data is still in ^%ISCLOG("Data"); just checked in Cache 2018.1.6.

If you are interested in global moving without downtime there is (live-global-mover)

Thank you, already not as new deployments of our HIS use separate document storage from the very beginning. 

Your solution is beautiful as it allows placing the ECP enabled "moved data" server to some less expensive disk storage. In our case that I've briefly described ECP & Mirror were already in use, so we couldn't place document DB on a separated data server as having several independent data servers would be a bad decision for many reasons.

To reduce the backup time, it could be interesting to move these data to a database dedicated to the archive and make a backup of this database only after an archive process

...

Copy data older than 30 days to the ARCHIVE database

Hi Lorenzo,

We had the similar problem with our largest customer's site which summary database size overgrew 2 TB those days (now the have more than 5 TB). Our solution was more complex than yours as the data move process lasted several days, so we can't stop users for such a long time. We placed a reference to the new storage of (already moved) document data instead the document itself. After the data move was finished, namespace mapping was changed. References were left in the original DB because they took much less space than the original documents.

This rather sophisticated approach allowed us to move the document data without stopping the users' activity. And what was the total win? Should the document data be backup'd? Yes. Should it be journalled / mirrored? Definitely yes. The only advantage achieved with this data separation was no more or less than the ability to deploy testing and/or learning environments without the document database. That's all.

Set LocalTimestamp=$now()

And to launch IRIS do...

Thanks, Evgeny.

Can't notice a difference between the lines: 1 and 3, 4 and 6. Just a typo?

you should perform the one-liner as an argument of Xecute command

Bonus: you can New other variables if you want, e.g. 

x "new $namespace,P set $namespace=""%SYS"",P(""Globals"")=""%DEFAULTDB"",sc=##class(Config.Namespaces).Create(""%All"",.P)"

Or add 

n $namespace

before the call. Once you go up in the stack the namespace will be switched to your current namespace automatically.

It would not unless you exit the current stack level. To achieve it, you should perform the one-liner as an argument of Xecute command, making it less pleasant, e.g. 

x "new $namespace set $namespace=""%SYS"",P(""Globals"")=""%DEFAULTDB"",sc=##class(Config.Namespaces).Create(""%All"",.P)"

...make sure all integrations should work fine

Hi,

That's very important note.

As to our experience of moving to IRIS our company's main development server, the most of the problems occurred outside IRIS: a "forgotten" Gitlab runner, or Ansible script, or other integration stuff. Those problems were mostly faced after the new server had been "lifted and shifted", as the correspondent pieces of software were the parts of our development cycle and could run on working environment only.

In contrast, we had virtually no problems inside IRIS as our COS code had been preliminary converted and partially rewritten to achieve IRIS compatibility; the developers' local instances had been converted to IRIS beforehand as well.

48! while all applauds are still to Vitaly.

ClassMethod Solve(o As %String) As %Integer
{
a s c=$p(o,",",$i(i)) q:'$lf($lfs(o),-c) c g a
}

Even if correct the syntax error occurred due to COS Syntax highlight: 

 s res=0 f i=1:1:$l(o,",") s res=$p(o,",",i)+res
 q res

it fails on Ed's samples #3, 4, 5 as it summarizes unpaired numbers:

1,-1,2,-2,3,3 returns 6 vs 3
-110,110,-38,-38,-62,62,-38,-38,-38 returns -190 vs -38
-9,-105,-9,-9,-9,-9,105 returns -45 vs -9

Straightforward one of 85 characters: 

ClassMethod Solve(o As %String) As %Integer
{
  f i=1:1:$l(o,","){s x=$p(o,",",i) i $d(y(-x)){k y(-x)}else{s y(x)=1}} q $o(y(""))
}