Migrating HS 2016.2.3 to new Data Center, tips/guide/etc?

Question

Question

Brad Klein · Feb 25, 2020

Hi,

I was wondering if there were any guides, similar to the ones for an upgrade, that walkthrough at a high/medium level the process for migrating an Ensemble Instance.

I am presuming that the general flow would be to install a fresh instance in the target environment, and migrate items over.. but any specific order? gotchas? things to avoid? Some things that should/shouldn't be im/exported (ie, must be manually migrated) ?

Doing some googling I found this page, and i have confirmed I don't need Endian xlation or DB Extent conversion.

We're going from Windows -> Windows , physical to VM (considerations or gotchas on this?)

I have only inherited support of this environment for the past ~year or so, but i know there's a hefty dose of customizations in the environment.

I am also considering doing an upgrade at this time (to at least 2017.2), but I presume the decision as to whether to do so at this time is more a function of site-specific needs and timeline than any "Best Practice" or ISC recommendation ?

I apologize if this question(s) is a bit n00bish - I have a little bit of experience upgrading instances in-place, but none doing a proper migration :)

Other notes: I plan to involve our Account reps but I wanted to do some pre-research / investigation first.
The client is technically on Healthshare but is really only using Ensemble functionality - possibly no HS functionality at all, AFAIK.

Thanks!

Discussion (2)3

Log in or sign up to continue

Enrico Parisi · Feb 27, 2020

Hi Brad,
we have done quite a few similar project migrating, cloning and "splitting" Ensemble/HealthShare systems to/from different sites or systems.

In fact we are working on one migration (with some change in the target site) right now.

The actual recipe depends on the environment and the requirements, in your case is a "simple" move, and that simplify the job.

It is indeed possible to upgrade during the migration, but of course it adds a little more complexity and planning (AND TESTING!!).

One important aspect is the down time you can afford, if any. I've never done a migration with zero down time, I would say that around 30 minutes to one hour is feasible, in your case that does not require any modification maybe in less that 30 minutes it can be done.

Ensemble is an integration platform, it often connect to many systems and receive connection from many systems, often there are some sort of web/csp app where user are connecting, this must be taken in to account to simplify and speed up switch time.
Ideally you want to have full control of the "communication switch" so when the "new" system take over you can switch (divert) all the connection to the new system.

We usually install a temporary reverse proxy for all the HTTP/HTTPS traffic (soap, web/csp pages, rest, etc.) that "redirect" the traffic to the "old" system and ask all the connecting systems to "point" to the reverse proxy BEFORE (a week or two) "D day" (final migration switch date).
Then we make sure that ALL the HTTP/HTTPS traffic goes through the proxy (we always find some external system that "forgot" to change the endpoint...).
The "D day" you change the reverse proxy configuration to "redirect" the traffic to the new system, so this is under YOUR control.

For HL7 traffic we usually prepare in the "old" system a separate production that simply redirect received HL7 to the "new" system.
You need one Business Service and one Business Operation for each TCP/IP HL7 inbound adapters in all your productions (i.e. one for each HL7 port in your system).
This production can be implemented adding BS's (EnsLib.HL7.Service.TCPService) and BO's (EnsLib.HL7.Operation.TCPOperation) with simple point & click configuration.
When all your production in the old system have stopped and started in the new system, starting this production will redirect all the HL7 traffic to the new system, all under YOUR control.

As soon as the new system is up&runnign you can ask all the connecting partners/systems (HTTP/HTTPS and HL7) to change (at their convenience) the endpoint to the new system.
I believe that having the "main switch" in your control is crucial....particularly when you have tens of systems/partners connecting to Ensemble/HS.

Depending to your environment there maybe more type of connection to take care of...

Regarding setting up and migrating the system, the first goal is to replicate the configuration, usually this involve a fresh installation (better if using same drive/disk letters and structures), a preliminary copy of all the databases and configuration using some sort of backup (there are different options) and as much TESTING as possible in your environment. Are third party test systems available? If not you may need to build some mockup of the external system to perform some basic testing.
We usually take the opportunity to spit code ("routines") databases and globals (data) databases, if not already so.
The advantage of dividing code and data is the ability to change code in the target system and when performing the last migration/copy only data is transferred (actually, the database may contain code no longer used...no problem).
The final migration should only transfer the data (not config) and involve some sort of backup and journal file from backup to "shutdown", this way you can minimize the downtime to the minimum.

Please add in the middle of each step above: test, test, test and at the end test, test and test :)

There are many other aspects I forgot or depends on specific environments and requirements, these are only a few tips from my experience.

If you have any specific question, just ask, I can't commit for an answer, but maybe somebody else will ;)

Ciao,
Enrico

0 0

score 0 · Answer 1 · 2020-03-18T09:55:51-04:00

Hi Brad,

In addition to Enrico's list, these are some of the settings and items I would be wary of.

1. Auto-start on the Productions.

2. Creating any Custom WebApplications in the new environment. These would be applicable if you Client is using SOAP and/or REST based interfaces and Custom web pages.

3. Resource, Role and Users creation/import from the old environment to the new. Please look at the below classes in the %SYS Namespace.

a. Security.Roles
b. Security.Users

4. Once the backup is imported into the new environment, please, please do a compile of all the classes in all namespaces.

a. zn "%SYS"

b. do $system.OBJ.CompileAllNamespaces("u")

c. do $system.OBJ.CompileAllNamespaces("ck")

5. And restart the new instance atleast a couple of times after the import and compile. This should clear any issues with the new installation and monitor the Console log for issues after the restart.

6. And I guess you are replicating the Database size limits from the old system to the new system.

7. Create Tasks in the Task Manager, after Tasks import.

8. Last but not the least, check with the Network Team if all the Vendors/source/destination application system routes have a S2S VPN connection setup or firewall ports opened.

Hope this helps.

Thanks,

Arun