A classic example of a data migration issue in projects

Here's background. The project required migrating over 7 years' worth of transactional data (sales order, returns, and so on) over 7 years. The CFO was adamant about migrating the data and wanted it to report, provide year-on-year analysis, and undertake returns processing (they sometimes allowed returns up to 7 years).

The following were the challenges:

  • The data quality in the legacy was bad (it always is due to bugs in the past and so on. This is the reason the company was moving to the new system).
  • Another challenge was selling the solution. Even though the CFO was pushing for a high volume of data migration, nobody was pushing back with the facts of the legacy data, the impact of doing such a migration, and the ways to meet his requirements. Just refusing to migrate so much data is not enough; you need to convince your leaders. I would rather spend more time on this part to get it right than spending the humongous amount of effort required on data migration (and still come up with a messy outcome).

The impact on the project was as follows:

  • Many rounds of data migration had to be done (more than ten). Each time the team discovered more issues in the legacy data; it was a painful, iterative process.
  • The overall impact on the schedule and budget was that the data migration stream consumed most of the key resources on the project. It also had an impact on the overall schedule/budget as the data migration was on a critical path.
  • A lot of data migration bugs were discovered during testing, and this slowed down the process. (In some cases, they had to redo the entire migration before moving further with the testing).
  • After the release, new issues surfaced in many cases while processing the returns. It created a lot of noise in the returns process and impacted customer satisfaction. Moreover, it resulted in additional work for the accounting team, which had to analyze and post journal entries for the errors in the returns processing (accountants can fix anything through journal entries, but they shouldn't have to).

The customer decided to go on to the next version after a painful and expensive lesson learned.

  • This time, only open orders, and no history from the legacy data, were migrated.
  • Reports from the previous system, the data warehouse, were used to report on the legacy data.
  • We also came up with a manual process to review the initial order in legacy prior to processing any returns as the volume of returns was not very high, and it went down significantly as time went by.
  • Unfortunately, the customer had to spend money to do it all over again; rework can be avoided by keeping it simple the first time.
..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset