Hi,

I had to prepare a suitable file

Previous case:  Open Param "RU" /UNDEFINED ignores  line terminators

 
USER>open file:("RU":1000000)
 
USER>use file read x use 0 write $l(x)
164405
USER>write $e(x,*-30,*)
e></xs:complexType></xs:schema>

USER>close file

With open Param "RS" /STREAM  line terminators are honored

USER>open file:("RS":1000000) s l=0
 
USER>use file read x set l=l+$l(x) use 0 write $l(x)," ",l
4126 4126
USER>use file read x set l=l+$l(x) use 0 write $l(x)," ",l
18433 22559
USER>use file read x set l=l+$l(x) use 0 write $l(x)," ",l
61497 84056
USER>use file read x set l=l+$l(x) use 0 write $l(x)," ",l
80343 164399

USER>write $e(x,*-30,*)
e></xs:complexType></xs:schema>

USER>close file

The difference in lenght results from skipped line terminators.
 

There is no option 'NO_JSON' or similar for strings.
so you have to do it by hand.

Assumption according to your description the basic table  looks like this: (except for Name)

select ID, Name, Options from Whatever.Whatever

Then this might do the trick:
You manually mask out the critical characters first and mask it in after JSON Processing.
No help by the system just your own fate.

SELECT top 5 ID, REPLACE(REPLACE(REPLACE(
JSON_OBJECT('ID':ID,'Name': Name,'Options': $TRANSLATE(Options,'{}"','()^') )
,'"(','{')
,')"','}')
,'^','"')
FROM Whatever.Whatever

Not funny but working

You could as well compose your 'personalized' JSON result in a Classmethod and project it as SqlProcedure 

1)  YES, you can! 
And it will not affect stability and usability. Though understanding COS is definitely an advantage in understanding what is going on. Similar to all other DBs: Understanding concepts and internals is always a benefit. Other DBs are just not as open to investigation and not as flexible doing the "undoable".

2a) Importing and running a Caché DB into IRIS works for 98% at least.
For the remaining 2%, ISC engineers are very open to assist you and solve the issue.

2b) Converting COS to anything else depends mostly on the COS code you have in hands. I know of no converter to do it for you.
As COS allows coding style that was used 40yrs back the range of styles is a very broad and unpredictable field without touching it.
#1 You depend on the quality of external documentation.
#2 You depend on inline documentation, comments, remarks in code. This can be excellent or just not existing, 
#3 You depend on how tricky the code is designed and written.
At that point just knowing COS might not be enough and even experts could get their headache on what I call "dirty coding". 
#4 ISC has experts also to read and understand old style and its side effects.
#5 You have this bright community to ask.
#6 You have excellent online training facilities to learn COS. I've done this with ~12 people over the last few years.
If they understand Objects, SQL, Java (or generic OO programming concepts) it's a matter of a few weeks to be inside COS.
And they have to be willing to break out and see something new with other limits and other possibilities other horizons.

HTH 

The key issue in a DR scenario is network performance between the instances.

You will run most likely an Async Mirror to have a reasonable distance between production and DR site.
I wouldn't suppose enough bandwidth for a sync Mirror.

The other issue is the performance of the DR site.  You require enough performance to process all the synchronization within a reasonably short delay. This is often underestimated, Production servers grow and leave their DR site behind.

Not specific to the cloud but not less important: How can you verify that the content of your DR site is really identic to your production.
For a heavy transactional operation, this can be a real tricky exercise.

And last not least if you don't train your team for a disaster situation and verify your instructions step by step at least once a year all your investment could be wasted money.

Especially this last point is skipped quite often as it means in most cases a lot of effort with no immediate ROI.