Best Practises to follow to lift and shift migration form cache2017.1 to iris2020.1

Question

Question

prashanth ponugoti · Feb 5, 2022

Hi Community,

We got requirement to Migrate whole interfaces from prod instance (cache2017.1 ) to new instance iris2020.1.

Currently around 100+ integrations (health share and health connect) up and running in prod instance (cache2017.1 ) , we need to migrate this live server to brand new server with iris2020.1.

Could you please suggest me guidelines and best practises while doing this migration.

Please ping me any document reference for this kind of Lift and Shift Migration.

After migration done, we will use new Live (iris2020.1 )instance only.

Thanks,

Prashanth

Product version: Caché 2017.1

Discussion (6)1

Log in or sign up to continue

Eduard Lebedyuk · Feb 6, 2022

Check out:

InterSystems IRIS Migration Guide
How to Migrate to InterSystems IRIS

from WRC (Downloads - Docs).

1 0

Alexey Maslov · Feb 7, 2022

...to brand new server with iris2020.1

It's up to you, but why not install brand new IRIS on your brand new server? As you may notice, InterSystems is actively develop IRIS and usually doesn't release minor updated versions as it was in the case of Cache (e.g. IRIS 2020.1.1 vs Cache 2018.1.5). Choosing 2020.1, you are going to install the version which is near the end of its support cycle, see Minimum Supported Version Rules.

1 0

Steve Pisani · Feb 7, 2022

Hi

For existing documentation, I believe others have already directed you. If, however, you are not doing an in-place migration (that is, you are installing on a new server), then one needs to get a bit more creative. (There are several reason why you may choose to switch to new servers - for example wanting to move to a different OS, or a version that is supported by IRIS which you cannot simply upgrade to.)

Your InterSystems Sales Engineer or even the WRC, are able to provide the detailed advice you need which is often specific to your situation. The main things to consider is the downtime you can afford when you failover to IRIS, and the architecture you have (do you have multiple Cache nodes, ECP, mirrors, etc ?).

In general however, what I have done successfully is create IRIS Asynchronous Mirror servers of the Cache nodes, then, (on switch over) shutdown Cache and promote the IRIS servers to active mirror failover members etc. You obviously need to ensure that the IRIS set of servers is readily configured with security, memory etc to take over as a valid Async DR node.

Finally note that this creation of IRIS nodes as async mirror nodes to Cache servers is not supported as a production configuration but only allowed for migration.

Please reach out to InterSystems WRC or Sales Engineering for more in-depth discussion and planning.

Steve

0 0

score 0 · Answer 1 · 2022-02-07T06:19:15-05:00

prashanth ponugoti · Feb 7, 2022

Thanks Alexey,

I will suggest your recommendation to my management.

thanks

0 0

score 0 · Answer 2 · 2022-02-07T15:43:14-05:00

Thanks a lot Steve ,For this migration we have different teams (vendors) working. My team is responsible for lift and shift and make sure all integrations should work fine.

I will make use of your valuable inputs.

Thanks,

Prashanth

score 1 · Answer 3 · 2022-02-08T00:02:36-05:00

...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.