How do you know your migration worked?

Not only do migrations give many organisations the heebie-jeebies but, even after they’ve completed them, lots of companies are scared to death at the idea of turning their old system off, so they keep the new and old systems running in parallel for months or even years. In this article I want to discuss a tool called TRUcompare from Valiance Partners, which provides a test and validation environment that can reassure users, and regulatory bodies, that migration has been completed satisfactorily. Note that TRUcompare is not used within the migration process per se, only for testing its success.

First a word about Valiance Partners: this was originally established as a specialist migration consultancy and it has implemented over 200 migrations for or alongside its clients. It built TRUcompare precisely so that it could prove the success (or otherwise) of its migrations, particularly for firms subject to auditing by regulatory bodies. However, the company is now in the process of spinning out any revenues not directly associated with TRUcompare so that Valiance becomes a pure product company. Currently the company only has offices in the United States although it has customers in other regions.

Before I go on I should explain why I have referred to regulatory bodies. This is not something that normally crops up when dealing with pure data migrations. However, if the migration purely or partly involves content (as opposed to data) then compliance issues occur frequently when bodies such as the FDA (Food and Drug Administration) and SEC (Securities and Exchange Commission) have an interest in ensuring that migration has been correctly achieved.

TRUcompare works with both data and content and you start by profiling these, then defining the transformations that will be required (from which a specification is generated) and then, once migration is complete, the software compares all the data and content in the new system with the original data, taking into account the transformations that have occurred during the migration process. Notice that I said that it compares “all the data and content”: TRUcompare does an exhaustive test rather than relying on sampling that can be unrepresentative, thus eliminating the need for QA teams to do manual sampling.

Now, there are a couple of issues here. The first is that anybody from the data management world will question the duplication of effort in profiling and transforming data compared to using data quality and ETL (extract, transform and load) tools. However, nobody from the content management space would raise such issues because these sorts of tools simply do not exist in that arena. Secondly, profiling is an automated process so it isn’t necessarily onerous to do this twice (and, in any case, in TRUcompare it is not as detailed: it is not interested, for example, in discovering redundant columns). And, thirdly, it is arguable that for testing and validation purposes you actually should have a separate system for quality assurance and compliance reasons, otherwise you may get self-perpetuating errors.