Learning Objectives
By the end of this lesson you will be able to:
- Identify the two root causes that are present in almost every failing data migration
- Describe the three phases of the PDM recovery approach
- Explain why the rescue strategy is Agile regardless of how the project originally ran
- Define the scope boundary: what you are and are not responsible for in a crisis
If Your Project Is In Trouble
Data migration projects fail. Not rarely - routinely. A significant proportion of data migration practitioners will spend part of their career parachuted into a project that is already in serious difficulty.
This module is for that situation. The tone is different here: direct, numbered, no ceremony. If you are reading this in anger, you will not want expansive prose.
The good news: failing data migration projects are recoverable. The patterns of failure are well understood, and so are the patterns of recovery.
The Two Root Causes
Almost every failing data migration has the same two weaknesses at its core:
1. The Responsibility Gap is wide open.
The enterprise has ceded ownership of the migration to technologists. Business data owners are not engaged, not accountable, and often not consulted. When things go wrong, there is no one on the business side who accepts responsibility for data quality - and no one on the technical side who can fix problems that are fundamentally about business knowledge.
This is Golden Rule 1 violated. Refer back to Lesson 01.02 - The Responsibility Gap if you need to revisit this concept.
2. Issues are not under control.
There is no single DQR log. Outstanding problems are scattered across emails, spreadsheets, meeting notes, and individual developers’ heads. No one has a complete picture of what is broken, how serious each issue is, or who owns the fix.
Without a DQR process, a data migration project is not under control - full stop. Refer back to Lesson 03.08 - Data Quality Rules Concepts.
Your Scope Boundary
In a major crisis there are often many things failing at once - data migration is rarely the only problem. You must restrict yourself strictly to issues within the data migration remit.
This is not about avoiding accountability. It is about effectiveness. A project rescue fails when the data migration team is drawn into fixing problems that belong to the programme delivery team, the business change team, or the system integration workstream.
Use your DQR log to triage: data migration issues go in; everything else gets escalated to its rightful owner.
The Three Phases of Recovery
PDM structures crisis recovery into three sequential phases:
Phase 1 - Stabilisation
Stop the situation getting worse.
Establish the conditions for controlled work.
Phase 2 - Planned Activity
Move to a release-based approach.
Deliver measurable, perceivable improvements.
Phase 3 - Post-Implementation Mop-Up
Address what was deferred during the crisis.
Close out properly what a well-run project would have done from the start.
These phases are not equal in length or difficulty. Stabilisation is the hardest - it requires political skill as much as technical skill. Planned activity is the grind. Mop-up is the relief.
Why the Recovery is Always Agile
The rescue approach is unashamedly Agile, regardless of what delivery methodology the project was using before.
Waterfall and stage gates have already failed you. A release-based, iterative approach is the only mechanism that gives senior stakeholders certainty (“here is what will be fixed, by this date, in this release”) while allowing the team to respond to the new problems that will keep surfacing.
If the word “Agile” has become politically toxic on the programme - perhaps because a failed scrum approach is part of the problem - call it “release management” instead. The substance is the same.
PDM’s approach to Agile is not scrum. It is planned releases, collaborative prioritisation, and ruthless triage. Scrums on the programme become subordinate to the DQR/release planning board. See Lesson 04.03 - Waterfall, Agile & Blended Approaches for the PDM model.
Key Takeaways
- Failing migrations almost always share two root causes: an open responsibility gap and uncontrolled issues
- Your scope is data migration - triage ruthlessly to keep other problems out of your log
- Recovery has three phases: Stabilise → Plan → Mop-Up
- The recovery approach is Agile (release-based) regardless of the project’s original methodology
Book Reference
Practical Data Migration by Johny Morris (BCS, The Chartered Institute for IT):
- Chapter 17 - Rescuing Failing Data Migration Projects