Part one in this article series summarized the shockingly high failure rates for migration projects, identifying data migration as a key area of project failure. This article will now consider the types of risks that should be mitigated when planning a data migration.
The risks fall into three broad categories, summarized below. These apply to any software development project, but are made particularly acute by the nature of data migrations.
Read the entirety of this article series in the Curiosity eBook, How to avoid costly migration failures.
Quality issues following a data migration range from production outages, to bugs, missing functionality, and missing data.
Production collapses might stem from “bad” or “dirty” data that has snuck in during the migration, potentially resulting in outages that cost on average $84,000 -$108,000 per hour [1].
In other instances there might be data in the legacy system that developers and business analysts simply did not know about, and so did not develop for. This unexpected data might cause equally unexpected “features”, or bugs, or the data might simply fail to appear in the new system.
Then there’s new functionality. During a migration, organisations typically attempt to implement new functionality in the new system. This functionality must be designed, developed and tested rigorously, with the familiar challenge that there will be no data in the legacy system with which to test the new functionality.
Compliance risks can be particularly acute during data migrations. This is because, during the “big bang” migrations often favoured today, organisations are moving all the data to a new system.
The data under migration furthermore typically contains some of the most sensitive types of data, reflecting the nature of systems that are commonly migrated today. This includes CRMs full of personal data about customers and prospects, as well as HR systems packed with personal information about a workforce.
HR systems carry the additional risk of containing categories of data that are explicitly marked “sensitive” in legislation like the EU GDPR. This includes information relevant to a person’s health, trade-union membership, and sexual orientation [2].
In the instance of CRM and ERP systems, there might additionally be commercially sensitive data, the spread of which should likewise be minimized.
A cautionary tale for migration planning comes from the Norwegian Confederation of Sport. In 2021, the Norwegian Data Protection Agency (DPA) announced that they were fining the confederation €125,000 [3]. This followed the leak of personal data relating to 3.2 million Norwegians, as a result of a “discrepancy” that “occurred when they were testing solutions for moving a database from a physical server environment to the cloud.”
In 2021, the Norwegian DPA levied a fine for compliance breaches during cloud migration testing. Highlights added.
The DPA found that sufficient risk assessments were not in place, and nor was there a “legal basis for performing testing with this personal data.” The testing, the DPA said, could have instead been performed with synthetic test data, or using far less personal data.
The fine of €125,000 might be far less than the fines of €746 or 225 million that have been levied under the GDPR [4]. However, it’s particularly significant here as it shows the compliance risks of performing a software migration, and in particular of testing that migration.
Today, the majority of migration projects overrun on cost, budget, or both. Data migrations appear to be a significant factor in these overruns. So, what makes a data migration such a risk factor for project time and cost?
Enterprises today often opt for a “big bang” migration, in which they move all the legacy data at once. Many furthermore opt for tooling to move the data, or simply to copy the data and hope for the best. This scenario pushes data migration testing late in the project. Often, testing waits until after the new system has been developed, and shortly before the “go live” date.
This late-stage testing is a throwback to old school waterfall projects, and carries all the familiar risks. It relies on BAs, testers and developers having impeccable upfront understanding of the legacy data and new system, though this is rarely the case. Instead, quality issues from unexpected or misunderstood data are usually discovered only after legacy data has been migrated over. This then requires a massive refactoring, for which time and budget had not been initially forecast.
Given the high rate of migration project failures identified in part one, it appears that these risks are rarely mitigated during migration projects. The next article in this series considers why this is the case, setting out 4 reasons for data migration failures. Part four will then set of how a unified solution avoids these common mistakes, facilitating migration project success.
Read the entirety of these articles in Curiosity’s latest eBook, How to avoid costly migration failures.
References:
[1] Business Computing World (2019), “Assessing the Financial Impact of Downtime”. Retrieved from https://web.archive.org/web/20220401112307/https://businesscomputingworld.co.uk/assessing-the-financial-impact-of-downtime/ on August 4th 2022.
[2] European Commission, “What personal data is considered sensitive?”. Retrieved from https://ec.europa.eu/info/law/law-topic/data-protection/reform/rules-business-and-organisations/legal-grounds-processing-data/sensitive-data/what-personal-data-considered-sensitive_en on August 4th 2022.
[3] European Data Protection Board (2021), “Norwegian DPA: Norwegian Confederation of Sport fined for inadequate testing”. Retrieved from https://edpb.europa.eu/news/national-news/2021/norwegian-dpa-norwegian-confederation-sport-fined-inadequate-testing_en on August 4th 2022.
[4] GDPR Enforcement Tracker. Retrieved from https://www.enforcementtracker.com/ on August 4th 2022.