4 Reasons for Data Migration Failures

Part two in this series identified some key risk factors associated with a data migration, which underpin the shocking migration failure rates identified in part one. Let’s now consider common reasons why these risks factor are not successfully mitigated. In other words, let’s discuss four reasons for data migration project failures.

Download this entire article series in Curiosity's latest eBook, How to avoid costly migration failures.

1.      You don’t understand legacy system data.

The system being migrated is, by definition, legacy. If it’s a mainframe system, it might be decades old and poorly documented. The team responsible for building the original system might further have left the organization, carrying knowledge regarding the system out the door with them.

This lack of system understanding significantly hinders the developers, BAs, and testers responsible for ensuring a smooth migration. Migrating unexpected or “bad” data from a legacy system risks outages and bugs. Lacking sufficient knowledge of the system, delivery teams cannot mitigate the risks posed by this data, as they might not even know it exists. BAs, for instance, cannot design rules for efficient or bug-free migrations, and nor can developers and testers deliver one.

2.     You don’t understand the new system functionality – and the requirements don’t help

To develop a new system ahead of a data migration, developers further require clear and complete understanding of all the desired functionality. They must know how the system should process the myriad of data that will be migrated to the new system, as well as the transforms needed to get it there.

Yet, testers and developers are typically equipped with incomplete or ambiguous requirements. These are usually text-heavy and poorly suited to the complex system logic. They furthermore rarely depict the system data or its structure clearly and comprehensively:

Text-heavy requirements are poorly matched to the logic of complex data structures.

These suboptimal requirements risk introducing functional bugs, missing functionality, and costly rework. If teams don’t know exactly how a new system should process a piece of data, how can they develop the new system pre-migration?

3.      You don’t have varied data to test the new system

However early or late you start testing your migration, your teams require comprehensive test data. This data must be capable of testing all the new system requirements against the full range of data that the new system will process. It must therefore include unexpected results, negative scenarios, and new functionality.

Yet, organisations often attempt to test a migration using a slice of production data. This unwieldy data typically lacks unexpected results, outliers, and negative scenarios. It is instead highly repetitive, reflecting the “happy path” scenarios exercised by most production users:

Production data typically contains just a fraction of the data needed for rigorous migration testing.

The historical data further lacks data for testing new functionality. For example, if a new Business Intelligence dashboard allows users to filter by an additional dimension, how can testers validate this functionality? Testing with data that lacks this dimension, QA might not even guarantee that the new data will appear in the new system.

There’s then the costly compliance risks associated with testing using production data, particularly in it’s raw form. These compliance risks were discussed in the previous article.

Overall, copying production data into a new system does not constitute rigorous testing, and nor does it offer the tools for a successful migration:

• It does not tell you how the old system functioned
• It does not tell you how the new system should function
• It does not provide the scenarios needed for rigorous testing
• It does not ensure compliance with data privacy regulations

4.      You tested too late

This is a common mistake, which was discussed in the previous article. To recap: Waiting to develop a new system before copying over test data risks finding bugs shortly before the “go live date”. This then requires rework for which time had not been forecast during migration planning.

Checklist for a successful migration project

These four common reasons for migration project failure should be addressed during the pre-planning phases of a migration. When embarking on a migration, ask yourself:

1. Do you understand the legacy system’s data?
2. Do you understand the new system in detail? And is that knowledge stored in requirements for future?
3. Do you have compliant data for testing every transform and requirement?
4. Are you testing early enough to give yourself time to fix and pivot?

Fortunately, a unified solution can fulfil each of these criteria. This integrated approach ensures that your teams have the upfront requirements, understanding and data needed for a successful migration. The next article in this series will set out this unified solution.

Download every article in this series as Curiosity's latest eBook, How to avoid costly migration failures.