Methodology Overview: Migration Preparation

In most cases, migration preparation will primarily be the responsibility of the organization that has decided to purchase a new system and migrate the data in their legacy data stores into it. In some cases, they may employ an SI to carry out much of this work on their behalf. Migration preparation can – and ideally should – begin before the new system has even been selected, which means that system suppliers are much less likely to be directly involved in most of these activities.

Migration preparation will begin with a set of initial requirements, which will be followed by a series of activities, as shown in the following diagram:

It is not necessary to carry out the preparation activities in a set order. The diagram shows some relationships and dependencies between the activities, but it is often best to start wherever is easiest.

Landscape Analysis

This is often the largest single task during migration preparation. It is where relevant legacy data stores are identified and analysed using modelling and profiling techniques.

• It is unusual for system suppliers to undertake this activity, but organizations may commission an SI to carry out this exercise on their behalf.

Legacy Data Store Register

Legacy Data Stores discovered during Landscape Analysis should be catalogued in a register. The information held in this register will be an extremely valuable resource both for the data migration workstream itself and for the wider project, to support the benefit realization of systems that can be decommissioned after go-live.

Migration Issues Log

Landscape analysis will start to identify issues that will need to be addressed by the data migration workstream. These will need to be recorded in a migration issues log. The migration issue management process is fundamentally central to the management of the entire data migration workstream. Therefore, it should remain independent of any other risk and issue logs, including the project risk and issue management and any IT fault management systems in place.

Key Data Stakeholder Register

It is important that the data migration team knows who are the key people that they will need to work with to deliver a successful data migration. These will include:

• Data Owners
• Business Domain Experts
• Technical System Experts
• Data Architects
• Data Management / MDM Experts

The list of these people should be maintained in a register. The initial requirements will probably identify some of these people, in particular the Data Owners for the main systems being replaced. Landscape Analysis should quickly start to identify others, especially the Business Domain Experts and Technical System Experts.

Establish Data Task Group

The data migration workstream will need to establish a Data Task Group to manage the Migration Issues Log. This will consist of appropriate Key Data Stakeholders who have the delegated responsibility to be able to make decisions about how to deal with the issues logged.

The Data Task Group will be chaired by the lead migration analyst in the data migration team.

• Where an SI has been commissioned to deliver the data migration, this will be their senior migration analyst
• The new system supplier’s data migration consultant will be a key data stakeholder with a place in the Data Task Group as a Technical System Expert

Project Decomposition

This is necessary to organize the work of the data migration into manageable parts. This will commonly be organized along functional business area lines. It is often useful to ensure that each area has a single Data Owner (although the same Data Owner may be responsible for more than one area).

• For a system supplier, it makes sense to ensure that the project decomposition aligns with the functional modules of their product.

Migration Sign-off Requirements

When the scope is understood and Data Owners have been identified, migration sign-off requirements can be agreed with them. Data Owners will eventually be asked to sign off that they are ready for the new system to go live, so a good way to capture their requirements is to ask, “What would stop you from allowing your current systems to be turned off?” The answers to this question can then be turned into testing specifications.

• System suppliers will have detailed knowledge of their system, so should be able to provide a comprehensive list of testing requirements. It is usually beneficial to bring a suggested list of requirements to the first meeting with a Data Owner.

Data Migration Strategy

Everything learnt during migration preparation should feed into the data migration strategy. This will be a key project document that will also explain how the data migration workstream will relate to the wider project. This will include a data migration plan that is aligned with the wider project plan.