Learning Objectives
By the end of this lesson you will be able to:
- Describe the two PDM workstreams and the nine modules within them
- Explain the role of the DMZ and Release Management sub-module
- Distinguish between the waterfall framing of PDM and its agile-compatible delivery model
Two Workstreams
PDM is organised around two parallel workstreams that run throughout the project:
Technical Workstream
- Landscape Analysis (LA)
- Gap Analysis & Mapping (GAM)
- Migration Design & Execution (MDE)
- Legacy Decommissioning (LD)
- Continuous Testing (CT)
Business Engagement Workstream
- Key Data Stakeholder Management (KDSM)
- Business Transformation Realisation (BTR)
Two modules deliberately sit outside the columns. Data Quality Rules (DQR) spans both workstreams - it is the forum where the business and technical sides meet, and it contains the Release Management sub-module. Migration Strategy & Governance (MSG) governs the whole model - both workstreams operate within the controls it establishes.
The workstreams are not sequential - they run in parallel throughout the project. The Technical workstream delivers ETL artefacts; the Business Engagement workstream secures the business knowledge and acceptance those artefacts depend on; DQR is where the two meet.
The Nine Modules
Migration Strategy & Governance (MSG)
The project framing. Establishes policies, governance structures, migration form (big bang, phased, parallel), software selection, and the initial list of legacy data stores. MSG is the first module, its outputs feed everything else, and it governs both workstreams throughout the project.
Landscape Analysis (LA)
The systematic discovery and documentation of legacy data stores (LDS). Every system, database, spreadsheet, or file that holds data to be migrated must be found, understood, and documented before it can be analysed or mapped.
Gap Analysis & Mapping (GAM)
The mapping of legacy data to target structures. This is where the technical complexity of a migration lives - resolving semantic differences, identifying missing data, and producing the mapping rules that the ETL will execute.
Data Quality Rules (DQR)
The forum where the business and technical sides meet - DQR spans both workstreams. It is the structured process for identifying, quantifying, prioritising, and resolving data quality issues, and in PDMv3 it is the hub for every decision and fix that is not a mapping requirement. It is the primary mechanism for business-led data remediation, the primary Super Smart Task in the project, and home to the Release Management sub-module.
Key Data Stakeholder Management (KDSM)
Finding and engaging the people who know the data - Data Owners, Business Domain Experts, Technical System Experts. KDSM is not a one-time activity; it continues throughout the project as new legacy stores are discovered and new issues arise.
Business Transformation Realisation (BTR)
Capturing the requirements of data owners for their migration - what they need to train on, test, retain, audit, and experience at go-live. BTR documents both convert resistance into specification and provide the migration team with their acceptance criteria.
Migration Design & Execution (MDE)
The technical design and execution of the migration - ETL architecture, extract design, transformation design, load design, and the migration runs themselves. MDE depends on outputs from all other modules.
Legacy Decommissioning (LD)
The retirement of legacy systems after successful migration. LD is not an afterthought - it is the original business case for the migration and the point at which the project is truly complete.
Continuous Testing (CT)
Testing is not a phase in PDM - it runs throughout. Each data release is tested. DQR metrics feed into test readiness. The final migration run is the last in a series of tested, validated releases.
Release Management
The Release Management sub-module sits within the DQR module - it uses the same tools and techniques - and operates throughout the project. A release is a collection of configurable items that together deliver a coherent ETL.
Releases are planned and delivered in fortnightly cycles - similar to agile sprints, but “push” rather than “pull”: the release content is planned through the governance structures (DQR Board, MSG) rather than within a self-organising scrum team.
Release cycles provide the project with a regular delivery cadence, a fallback mechanism (a faulty release can be rolled back to a previous one), and a platform for cross-programme planning.
The DMZ
The DMZ - Demilitarised Zone - is the contractual and operational boundary between the client organisation and any external supplier. It defines:
- What data can flow across the boundary and in what form
- Who owns data quality issues on each side
- What commercial protections apply to each party
The DMZ is particularly important in fixed-price contracts, where supplier behaviour on data quality issues can directly affect the client’s costs and timeline.
Is PDM Waterfall or Agile?
PDM is neither strictly waterfall nor strictly agile - it is designed to be compatible with both.
The overall shape is sequential: you cannot map data you have not analysed; you cannot execute a migration you have not designed. But within that sequence, each phase is iterative. DQR meetings recur. Releases are fortnightly. Test cycles accumulate evidence.
The full course covers the relationship between PDM, waterfall, and agile delivery approaches in detail.
Legacy Decommissioning as Business Case
One point worth making explicit: in PDM, legacy decommissioning is not the end of a project - it is the reason for a project.
The original business case for a data migration is almost always tied to retiring the legacy systems: reducing maintenance costs, eliminating licences, freeing staff, closing data centres. If the legacy system is never decommissioned, the business case is never realised.
PDM treats decommissioning as a first-class objective. Business Transformation Realisation documents capture decommissioning certificates and exit criteria. The whole project is, in a sense, working toward the moment when a Data Owner signs a decommissioning certificate and the legacy system is switched off.
The Non-Negotiable Core
PDM is built to be tailored. Most of the nine modules can be adapted, resequenced, or even substituted with an equivalent the organisation already runs well - the next module covers how to do that safely. But four things are non-negotiable. Remove any one of them and what you are doing is no longer PDM:
- One virtual team - the business and IT work as a single team with shared ownership of the data, not two sides managing a hand-off across a wall.
- Data Quality Rules (DQR) - the structured, business-led process for resolving every data issue and decision that is not a pure mapping requirement. It is the hub of the methodology.
- Collaboration - engagement is built into the work itself, continuously, not bolted on as occasional “stakeholder management”.
- Super Smart Tasks - every task is defined so that it is measurable and governable, and at the same time builds the team and engages the business.
Everything else is a question of tailoring. These four are the test of whether a project is genuinely doing PDM.
Key Takeaways
- PDM has two workstreams (Technical, Business Engagement) and nine modules - DQR spans both workstreams and contains the Release Management sub-module; MSG governs the whole model; the DMZ marks the client-supplier boundary
- The workstreams run in parallel; the nine modules interact throughout the project
- Release cycles provide agile-style delivery cadence within an overall sequential project structure
- Legacy decommissioning is the original business case - not an afterthought
- Four things are non-negotiable in PDM - one virtual team, the DQR process, collaboration, and Super Smart Tasks; everything else can be tailored
Book Reference
Practical Data Migration by Johny Morris (BCS, The Chartered Institute for IT): Chapter 3, “PDMv3 Overview”.