Execution

If a project is to use the Planning Module the data migration project will be established in the Portal Runtime infrastructure.

The Portal becomes available and ready to display all the Events that will occur when the migration starts to execute.

At this point, the Plan in the Planning Module enters execution mode and will be linked to the migration project in the runtime infrastructure.

Access

In the previous stages of the planning process (Template and Plan) only authorized members of the migration team had access. They will work on establishing the Plan.

But now – in Execution mode – the Plan should also be visible to the all business users involved in the migration. This is done by displaying the Plan in Portal. In this way, the Plan shows up for the business users next to all the other stuff they are handling in relation to the migration (Events etc).

In this execution view – integrated into the Portal – only state and progress-related information can be edited, not the business areas themselves (Name, Description, Test Outline etc).

What remains open for edit is the state of each business area of the Plan under execution.

Milestones

When a migration project executes using hopp, it will start out in an internal state where the data migration team is maturing the migration to achieve a level of quality necessary before it makes sense to actually load the migration result into a test instance of the target system and ask the business users to test.

Once through this initial state, a migration project typically progresses through a set of milestones. For instance

• Test conversion 1
• Test conversion 2
• Test conversion 3
• Dress rehearsal
• Go-live

Partitions

In some (rare) cases, more than one business may be migrated as part of the same project. A typical example is when multiple separate organisations are to be migrated at the same time. In this case, all the businesses are exported from the current systems together and migrated by hopp in one single project.

Each separate business being migrated in the same Project in this way is called a Partition.

(A side note: Even though 2 businesses can be said to be involved in a merger migration because one business is merged into the other, a merger only involves 1 partition).

Migrations involving more than one Partition are rare. Nevertheless, it is paramount that the entire migration setup can handle them when they do occur. For instance, the migFx migration framework separates the data and events concerning each partition and has authorization mechanisms in place to control that business users from one Partition (bank) cannot view data from another Partition (bank).

Likewise, it is important that the Planning Extension is ready for the concept of Partitions.

State

Different state aspects state of a given business area are edited at different levels

1. Business Area level
2. Partition level
3. Milestone level

Business Area level - Development State

For a given business area, the migration team can communicate a development state:

• Not started: The migration team must do some work before the area is ready to test. This work has not commenced
• Active: The migration team is actively working on the area
• Ready to test: The area is ready to be tested by the business users

This state is relevant only for the business area itself and is the same regardless of Partition or current Milestone.

Partition level – Test Relevance

For one Partition (bank) a given business area may not be relevant for test while the same business area may be relevant for another Partition (bank).

For a given business area, users can for each Partition can mark if this business area is

• Relevant for test (default)
• Not relevant for test

Milestone level – Test State

For a given business area, users from a Partition can communicate that the business area has been tested – and the result of this test. This Test State is registered per Milestone, so the Planning Extension can display at which Milestone a given business area was tested last.

For a given business area and Milestone, users can for each Partition mark the Test State of the business area:

• Not tested
• Tested ok
• Failed – a comment is mandatory