hopp Components

In this article, we introduce the main components of hopp data migration software. The main components make up the core software required to execute a complex data migration project using our software. In addition to the core components, we offer optional modules that support project management and scoping, and testing. 

hopps data migration software is made of a set of linked and collaborating components. Each component is a feature-rich application and the combined suite of components provides a complete foundation and support for all aspects of the data migration process.

Built on the Business Objects at the center, our application or our toolset or framework, whatever you want to call it, is built out of four separate components. 

If we start at the top in the figure below, we have the Studio application. This is where you produce the target map and you produce the source map. 

Figure: hopp Components

Studio is a Windows application dedicated to describing how the transformation and validation requirements in the migration must function. It's a very structured interface with all the features you will need for any complex data migration to be specified correctly. 

Studio requires you to be precise and structured in how you describe the mapping. It's a well-designed Windows application, focused on being user-friendly and helping the user to be productive and efficient. 

A team can work together to produce the maps, with each team member working within Studio to produce, for instance, their part of the Target Map. A user can have Studio installed locally, on a PC, and will be checking items in and out of a common repository. This means that you can efficiently collaborate across a team because you are communicating via a common repository. 

The maps that you produce with Studio are so structured and so precise that they can be given to the Engine. The Engine contains a code generator that will generate C# code that does exactly what is described in the maps that we are generating the Engines from. 

Whereas Studio is meant to be used by users who do not necessarily have a deep technical or programming background. Studio is meant to be used by people who know about the data and the business logic being moved across. Studio is aimed at a functional consultant rather than a technical consultant. When we get to the engine code, of course, this is more the technical people that will be working on this. 

A migration project will have some people who are concerned with specifying what needs to be done. In projects not using hopp software, these people will be using, for instance, Word and Excel spreadsheets to kind of specify how you want the fields in the source system to be mapped and transformed to fields in the target system and what validation rules to apply and so on.  

When the specification in Studio is done and the corresponding code generated by the Engine, we will leave the metadata world and enter the operational world where we're executing the migration. First, we get an engine from the code generator and deploy it into the Runtime environment. The Portal Operation remotely controls the Runtime environment where job processes run. It can run locally on your own machine, but it can also run on a different machine in your network. So you can have a powerful migration server that is dedicated to that kind of thing. 

The Portal Operation is targeted to roled - like one or two operators. Quite often, the same people who would be doing the manual rule implementation will do the operational tasks in the Portal Operation. Once you have achieved some level of quality, a state of your migration iterations that you think is presentable and makes sense, you will then publish it to the Portal.  The Portal is meant to reach out to the broadest audience, namely, of course, the migration team itself, as well as the business users involved in the project. 

Here, we are talking about the real users from the business who are involved in testing and verifying the migration results. They can see whatever happened in the migration and compare it to what they expect, as well as the events created and flags raised as specified. Management that wants to have some idea of the quality and progress of the migration can also benefit from looking at the tracker application. So these are the components that make up our solution. 

Below is shown a short description of each principal component.