Overview

In almost all data migrations, there is a business requirement for Reconciliation. In general terms, this term covers a mechanism (preferably automated) to verify that the data from the legacy source system was migrated in accordance with requirements.

This is a large topic, and the purpose of this article is not to cover it in depth. The purpose is rather to place the Hopp software in the broader context of Reconciliation and to explain the rationales behind and the limitations of what Hopp provides.

While everybody agrees on the broader concept of reconciliation, it is more difficult to pin down once you get a bit more into the details. 

In broad terms, reconciliation covers:

• That all in-scope data in the legacy source system is either migrated or discarded in accordance with requirements

Easily stated, but what does this actually mean? In conceptual terms, Reconciliation means to reconcile expected results and actual results. 

In some migrations, it is enough to count stuff: "We had x invoices in the legacy source system, y invoices were discarded by the migration as required, z invoices were delivered to the target system. If x minus y equals z everything is ok". For this kind of simple counting, the Hopp Portal is often quite enough to satisfy reconciliation requirements

But in many migrations, this simple approach doesn't cut it. And then suddenly things become much more complicated and for a generic migration tool like Hopp, it becomes impossible to provide a generic reconciliation. The truth is that more advanced reconciliation actually means is completely dependent on what is actually being migrated. 

In addition, the more transformations that are taking place in the migration, the more reconciliation is getting complicated. Given that Hopp is built for complex data migration, extensive transformations is simply a fact of life in any Hopp driven data migration. 

Hopp exposes interfaces to inspect the migrated data and collect Audit data that represents the Actual Result of the migration. By implementing these interfaces, a migration project can collect the Audit Data from each Business Object as it is migrated and and hand back the collected audit data to the Hopp Runtime. The Hopp Runtime will store the Audit data next to the Business Object and take care of all the annoying housekeeping when Business Objects are re-iterated and new Audit data collected.

In addition to the Audit Collect interfaces, Hopp also exposes an Audit Result interface. This is called when an operator initiates an Audit Result job from the Portal Operations interface and will receive all the collected Audit data for all Business Objects.

In this way, Hopp delivers a safe and open mechanism to collect the Audit data representing the Actual Results side of the Reconciliation equation. It is the up to the migration project to establish a reconciliation of the Audit data with the Expected Results from outside Hopp.