Expect Things to Get Lost in Migration

(Ref Id: 1342539826)

Migrating from one LIMS to another (one from a vendor that has gone out of business to a new system) is not a trivial task. Anyone that tells you that it is either is suffering from some form of delusion; has very little experience in the task; or is lying to you.

In the non-LIMS world migrations might actually be relatively simple. Let's take an application that we all probably already know, a Microsoft Access database. Let's say you want to port the back-end to Oracle or PostgreSQL. You try and move the data to find that the datatypes in the database are not equivalent, so you have to make accommodations that may entail making a few changes in the application because you cannot expect the database to do it for you. You then connect the front end to the new back-end via ODBC or some other database access technology and you are (mostly) done. This is known as database upsizing.

This is not the same thing as migrating to a different LIMS.

A LIMS is not a database. There are tons of application-level logic tools that are not inside of the database. The data itself is fairly useless without these tools and other LIMS have no idea what to do with that data.

In applications where many vendors have been in close competition with one another the tools will not only look the same on the outside but will operate similarly underneath. Consider CMS (Content Management Systems). They are all working against similar standards that are publicly defined by organizations like W3C and the IETF. So at least the output will meet expectations. Migration then involves mapping the data processing tasks of product A to product B. In LIMS this is a far more complicated task. The two systems are not always producing the same results. There are barriers to Vendor A learning anything about Vendor B's implementation, so they are can be very different both in form and function. For instance, LIMS A may have an SQC module that looks like LIMS B but may differ in very subtle ways such that the end results may differ wildly. Now your migration has to include a fairly sophisticated testing regimen to ensure that both utilities produce the same results in the myriad of scenarios that occur in the business day. If you are familiar with LIMS migrations you will realize that you cannot always rely upon the business to perform comprehensive testing of migrated functionality. There is just too much of it to test; too many conditions to consider. You will have to perform a significant part of the testing yourself as a part of the migration. Likely you will be doing this by using the data from the previous system and by re-running the calculations (3 out of 5 above the 3rd standard deviation upper limit -- feed it the last 100 points and see if it fails in the same place, for instance) for a large subset of the overall data to be migrated.

This is why I basically recommend that organizations that have a legacy, deprecated LIMS product just start from scratch with a new system and lock down the old one in read-only mode. Migrate what you really need like samples, relevant static data, etc. but do not look for a 100% migration from the old system to new unless your pockets are fairly deep.

Go Back

Citation: Expect Things to Get Lost in Migration. (2012). Retrieved Sat Jun 23 10:16:19 2018, from http://www.limsexpert.com/cgi-bin/bixchange/bixchange.cgi?pom=limsexpert3;iid=readMore;go=1342539826