Hi Brandon,
I am currently working on Cloverleaf 5.7 upgrade (also running on physical Windows 2003 server) to 6.1 on virtual 2012 server.
From my experience it is feasible if you can dedicate enough time to this and the deadlines are not too tight.
My biggest problem in this process is that we are in process of moving from Paragon to Epic and started building new interfaces. I also have other responsibilities, not only the interfaces, so I have to switch to other development projects and maintenance problems. As result I am not able to dedicate more than 0 – 20% of my time in a week. Hopefully you can dedicate all your time to the upgrade project.
Things to look for:
CL 5.7 was still using gdbm database and we had several packages developed over time that use it. All these packages had to be reprogrammed to use SQLite. It may not be a problem for your environment if you don’t use gdbm in your code or already migrated to SQlite (if I’m not mistaken migration to SQLite started at CL 5.8 ).
This is how I do it (this is also my first upgrade of CL and I am not sure this is the best approach, but I used similar technique 6 years ago when we were switching from Siemens MSA4 to Paragon and it worked for me).
I set up 2 test sites (for each of production sites) in 6.1 for my testing.
One site (let’s call it receiving site) mimics our production site with all outbound threads changed to local file threads to save translated messages in SMAT files.
Second site (Sending site) has inbound file threads and outbound threads pointing to the inbound threads on the receiving site. I could get away with just one site but I wanted to make sure that my receiving threads send ACKs.
I send production SMAT files from the sending to the receiving site.
I created a couple of very sloppy Tcl scripts for testing. First stores translated messages from the outbound file thread to a SQLite database in two tables – header used for searches and segments.
Second script reads production translated messages from SMAT file, searches in the SQLite database for corresponding translated messages using keys like thread name and message id from MSH-8 and compares these two messages field by field.
If any difference found the script outputs which fields are different and values of each mismatching fields. It also outputs both messages, so I could look at the mismatching messages without looking for them in corresponding SMAT files.
The whole process is quite time consuming – I need to pick correct SMAT files and send one of them, then load results into database and run comparison and then go through the results and figure out why they are different. Our SMAT files usually have 8000-12000 messages depending on the thread.
Some of our threads run SQL queries against our Paragon database to pull additional information (Paragon not always provide all necessary data in their HL7 messages). What that means that by the time I run my process through CL 6.1 the data in Paragon database may have been changed and my results won’t match. In these cases I go to Paragon and verify that the mismatch is not caused by translation.
If any mismatch found that is caused by incorrect conversion I do fix the error and then re-run the whole process again for that thread. I repeat the whole process for each thread until all results match or I am sure that all mismatches not caused by incorrect translation.
As our production system sometimes require changes I need to apply these changes and repeat the process.
I am not sure that I am giving you a good example of workflow but this is how I do it.
Thanks,
Sergey
.
