Learning Objectives
By the end of this lesson you will be able to:
- Identify the key lessons that the DHGS project produced
- Connect those lessons to the PDM principles and tools covered in earlier modules
- Explain which of those lessons are generalisable to other migration projects
- Apply the DHGS experience when evaluating decisions on your own projects
What the DHGS Case Study Demonstrates
The DHGS migration was not a simple project. The data landscape was fragmented, the data quality was poor in parts, the business was changing at the same time as the data was moving, and there were external parties with interests of their own. It was, in other words, a typical large-scale enterprise data migration.
It succeeded. Not without difficulty, but it completed on time, within scope, and with a target system that reflected the business accurately. The post-go-live correction volume was low. The legacy systems were decommissioned cleanly. The business had what it needed.
The question worth asking is: what made the difference? The lessons below are the honest answer to that question.
Lesson 1: Decisions Made Late Cost More Than Decisions Made Early
The most expensive issues in the DHGS project were the ones that were not resolved during the analysis phase. Equipment type codes that were left ambiguous into the build phase required rework of ETL routines that had already been built. Policy decisions that were deferred from the MSG into the trial run phase meant that trial run results could not be properly evaluated until those decisions were made.
This is a pattern that repeats on almost every migration project. The analysis phase feels like the least urgent part of the project - nothing is being built, nothing is moving, the deadline seems distant. The pressure to move to build is constant.
Resist it. Every week of rigorous analysis is worth more than a week of build that has to be undone.
Lesson 2: The DQR List Only Works If You Use It
The Data Quality Rules process gave DHGS a structured way to manage the IT-Business interface. But the structure only works if both sides commit to it.
In the early weeks of the DHGS analysis phase, the team found that DQR items were being sent to business data owners who did not understand what was being asked of them, or who were routing the items to the wrong people. The list was growing faster than it was being resolved.
The fix was straightforward: the Data Migration Analysts scheduled dedicated working sessions with each business data owner, walked through the open items for their area, and left each session with agreed next steps and deadlines. The DQR List did not resolve itself - it required active facilitation.
The lesson is that the DQR process is a tool, not a solution. The tool has to be used. That means building the facilitation into the project plan, not treating it as an administrative side activity.
Lesson 3: Business Transformation Data Is Migration Data
The Business Transformation Register was not, at first, treated as a migration input. It was being maintained by a separate workstream as part of the broader business change programme. The migration team initially assumed that the data would migrate as-is and that business changes would be applied post-go-live.
This assumption was wrong, and catching it early saved significant rework. If the equipment type reclassifications and site reorganisations in the BTR had not been incorporated into the transformation rules, the target system would have gone live with a structure that no longer matched the business. Correcting that after go-live - with live data in a production system - would have been far more complex than encoding the changes in the ETL upfront.
The lesson is to look for business change that is happening in parallel with the migration and to assess its impact on the data being moved. The BTR is the formal mechanism for capturing this, but the thinking has to happen before the document is complete.
Lesson 4: Fallback Is a Confidence Enabler, Not a Failure Plan
The DHGS project sponsor was initially reluctant to invest time in designing the fallback. The reasoning was understandable: designing a fallback implies that failure is expected, and communicating a fallback plan to the business might undermine confidence.
The opposite turned out to be true. When the project sponsor was able to tell the business that a hard cutover was being planned and that a fully designed fallback existed with defined trigger conditions and a tested reversal procedure, the business was more confident in the go-live, not less.
Fallback is not a sign that you expect to fail. It is a sign that you have thought carefully about risk. In a programme where the data migration is running alongside other significant changes, demonstrating that level of risk management discipline builds credibility.
The lesson is to design the fallback early, test it as part of the trial run programme, and communicate it as a feature of the migration plan rather than a last resort.
Lesson 5: Data Migration Independence Matters
The DHGS migration track was run as an independent workstream within the broader programme. It had its own governance, its own reporting, and its own escalation path. This independence was sometimes a source of tension - other workstreams wanted the migration team to absorb scope that was properly theirs - but it was ultimately what allowed the migration to maintain its focus.
When data migration is subsumed into a broader project workstream, it loses visibility and loses priority when competing demands arise. Issues that should be escalated to the programme board get handled informally. Resource that should be on data quality remediation gets borrowed for something else.
The lesson is that migration independence is not about protecting territory. It is about maintaining the conditions under which a complex, time-critical, dependency-heavy workstream can actually succeed.
Lesson 6: The Point of No Return Is a Feature
DHGS’s migration had a hard decommissioning date for the legacy systems. There was no scenario in which the legacy systems would continue to run alongside the target indefinitely. That constraint - uncomfortable as it sometimes felt - was one of the reasons the project succeeded.
When there is always the option to defer, people defer. Data quality decisions that require effort get pushed. Business engagement that is difficult gets avoided. The deadline is the mechanism that converts possibility into necessity.
The PDM definition of data migration includes decommissioning for a reason. The point of no return creates focus. Use it.
Connecting Back to the Course
The DHGS case study has illustrated, in a real project context, every major element of the PDM methodology covered in this course:
- The Migration Strategy Guide structured the early decisions and produced the Policy Overlay that prevented policy mistakes from becoming execution problems
- The Landscape Discovery Survey mapped the source systems and surfaced the implicit knowledge that was at risk of being lost
- The Gap Analysis Mapping produced a complete, version-controlled record of source-to-target field mappings and transformation rules
- The DQR List managed the IT-Business interface through the analysis and build phases
- The Key Data Stakeholder Map ensured that decisions reached the right people
- The Business Transformation Register brought the business change picture into the migration design
- The ETL Content Matrix and version control kept the build aligned with the specification
- The trial run programme validated the process before it was applied to live data
- The System Retirement Plan gave decommissioning the same level of planning and ownership as the migration itself
- The fallback design gave the business the confidence to commit to a hard cutover
None of these tools is complex on its own. What makes them powerful is using them together, in the right sequence, with both the technical team and the business engaged throughout.
A Final Word
Data migration is not glamorous work. It does not attract the same attention as the new system it is serving. But it is the work that determines whether the new system works - whether the data that the business depends on is there, is accurate, and is in the right shape.
The projects that succeed are the ones where someone decided early that data migration was not a technical afterthought, brought a methodology to it, engaged the business as a genuine partner, and held the line on doing it properly when the pressure to cut corners arrived.
That is what the PDM method equips you to do. The DHGS case study is the proof that it works.
Key Takeaways
- Late decisions are expensive decisions - the analysis phase is where the value is created, not the build phase
- The DQR process requires active facilitation, not just administration
- Business transformation data must be incorporated into the migration design, not addressed post-go-live
- Fallback design builds confidence; it does not signal expected failure
- Migration independence preserves the conditions for success in a complex programme environment
- The hard decommissioning date is a feature of the PDM approach - it converts deferral into decision
This is the final lesson in the Practical Data Migration course. Thank you for completing it.