Execution and In-Time Assessment

Once the executables to perform the data migration has been specified and developed, they must be put to work in an execution context to migrate the data. During execution, events will occur that needs to be documented. Some events are benign and of purely informational character, while other events to some extent may invalidate the migration results. In the latter case, it may be necessary to go back, perform some correctional measures and re-iterate the parts of the migration that were invalidated.

A key concern in any migration project is the way this type of re-iteration is done. Aggravating the problem is the probable presence of dependencies in the data. As an example: If the problem at hand raised the need for a set of Accounts to be re-iterated, this may very well result in the need for a recursive re-iteration of data dependent on these Accounts.

A worst-case scenario is an execution structure bringing the entire mass of data forward in a waterfall, batch-like process of steps. In this case, it can be difficult or even impossible to separate the data relevant to the events in question, in effect forcing a complete iteration of the total migration. A complete re-iteration may be problematic if there is limited time available. In addition, it may introduce unnecessary risks, as data not affected by the problems at hand nevertheless is included in the re-iteration.

The Business Object approach of hopp renders it completely trivial to point out a precise subset of Business Objects to be re-iterated. In addition, the integral handling of dependencies between Business Objects points out the dependent business objects that need to be re-iterated as a consequence. In fact, Runtime can automatically resolve dependencies and recursively re-iterate all dependent Business Objects. 

Another key concern is at what time in the migration execution information concerning the quality of the migration result surfaces. If this information surfaces late, time is lost. In addition, a greater part of the migration may need to be iterated in terms of dependent data than if the information was available immediately when the problem occurred. 

In many migration solutions, events occurring during the migration execution do not surface until a part of the migration actively aggregates and surfaces the information in some way. Delays of this kind may introduce unnecessary risks.

It is common that severe problems surface indeed very late - even after the migration as such is finished and has delivered the migrated data. This is the case if the migrated data is erroneous in a way that went unnoticed in the migration but nevertheless renders it impossible to place the data in the target system.

hopp meets these concerns in two ways. On one hand, the software creates Events in real-time as the migration executes, there is no unnecessary delay at all. In this way – in case of serious Events – the migration execution may be immediately paused, the causing problem corrected, surgical re-iteration of affected Business Objects executed, and the overall migration execution resumed, with minimal risk and loss of time.

On the other hand, hopp contains rich support for integral runtime validation as part of the migration, making it possible to implement validation rules uncovering problems that would arise when placing the migrated data in the target system. In this way, the software is able to show this kind of problem as Events – early and real-time as all other Events.

The inherent, iterative nature of the entire migration process results in the constant improvements of these validation rules over the lifetime of a migration project greatly enhancing the overall quality of the target data resulting from the migration.

In scenarios where migFx is used repeatedly in different projects migrating to the same target system, the number and quality of these validation rules will continue to grow and improve even between projects.