Data migration is a profession in its own right. This article discusses a number of risks that we recognise in a data migration and the sometimes special measures we take for this.
About the author: Robert Pauw is a designer/project manager and knows the financial domain especially well.
Robert Pauw, designer/project manager
Financial risk
We lost money along the way
When migrating data - especially in the financial domain - the most important thing to check is that no money has disappeared during the migration. Whether it’s the principal sum of mortgages or the balance of checking accounts - these amounts should be the same after migration!
You often check first at a high, aggregated level - for example, the sum of the principal sums of mortgage contracts. An excellent check that also provides immediate insight if something has gone wrong.
However, it offers no protection against mix-ups: for example, a loan component being linked to the wrong customer. In that case, the total is correct, but of course you do have a problem!
We tackle mix-ups by taking not a total, but totals within a certain dimension. For example, the total of the principal sums within a postcode area must be equal. You get even more certainty if you check the same thing twice with different cross-sections. For example, principal sum per postcode area and principal sum per year of birth of the contract holder. Then it is theoretically still possible something was mixed up during migration, but the chances are very small!
These checks are generally made on recognisable quantities in the domain. This recognisability is important because the stakeholders accept the migration partly on the basis of these checks.
Reducing financial risks is seen as the most important thing by customers, so it is essential to implement checks for this.
Figure: various checks on the quantity ‘Principal sum’: aggregated in total, cross-section by postcode area and cross-section by age. Example is illustrative - amounts are fictitious.
Going live
We overlooked something during the migration
Performing a data migration - as part of the overall migration - is a complex process. If this process is not done properly, the go-live will be jeopardised or - perhaps worse - the target system will not function properly.
One of the measures we use to reduce this risk is a migration script. This script contains all actions that need to be performed during the migration.
The script is continuously supplemented and expanded during the project. On average, it contains several hundreds of actions that must be performed. The script is the responsibility of the script manager, who is responsible for the development of the script, as well as for the eventual implementation.
The migration script includes more than just the data migration - for example, activities to stop processes in the source environment, informing the contact centre about the unavailability of an environment, etc.
The data migration by DX within the script is performed by the script operator and is checked and logged by quality assurance. The operator independently controls the entire migration in the data migration factory. The lead designer of the project is on standby to assist in case of issues.
The script is an important project result for the customer. The script itself is also tested several times. Testing is important to ensure the script is complete and fills in different (fall-back) scenarios correctly. In addition, the project team is prepared to implement the script.
Data eXcellence is ISO 27001-certified. This certification requires that the organisation:
- systematically examines the organisation’s information security risks, taking into account the threats, vulnerabilities and consequences;
- designs and implements a coherent and comprehensive package of information security controls and/or other forms of risk treatment to address those risks that are considered unacceptable; and
- implements an overarching management process to ensure that information security checks continue to meet the organisation’s information security needs.
Long-running processes
Post-migration issues
Long-running processes are processes that cannot be aborted when a new system is introduced but are continued. One example for payments is the reversal of a direct debit. This means that a direct debit can be reversed up to 8 weeks after payment. Another example is the renewal of a mortgage. For example, each domain has to deal with specific long-running processes.
If you overlook these processes, it can lead to major problems after the migration. These kinds of problems are often difficult to solve. For example, if a customer wants to cancel a direct debit, the direct debit must of course be known!
At the start of the data migration, an analysis is therefore always made of the long-running processes. These can have an impact on the migration scope and also the migration strategy!
Each domain has its own long-running processes. At Data eXcellence, we have extensive knowledge of finance, government, education, utilities and industry - and know the problem processes in these domains.
Run-out risk
It takes a while...
A risk arises when data migration is only tackled at the ‘tail’ of the implementation of a new system.
When working out the data migration, a level of detail is required in which gaps may occur. One example is a group of contracts that cannot be made to fit in the new system. Or data required by the new system that is missing from the source system.
This often has an impact on a project: the target system still has to be adjusted, an extra process has to be set up, etc. If this insight does not arise until late in the project, it means overrun in time and/or money.
How to avoid this? Simple: start the data migration in time.
Conclusion
A profession in its own right...
This article looked at various typical risks associated with data migrations and how we deal with them. Curious about the risks in your situation and what measures we can take? Contact us!