PDM Academy
Your PDM course.
Checking your access…
Sign in to view your course
PDM Academy is open access with no payment required, but you need to be signed in so we can save your progress. Sign-in takes one click from your inbox.
Sign in to continueOne quick thing - what should we call you?
Get the most out of PDM
Your progress
0 of 56 lessonsComplete a module to unlock its summary - and your downloadable field guide when you finish the course.
Course Introduction
Welcome, what the course covers, and how to get the most from it. A short orientation before the methodology begins. No quiz.
Foundations
Why migrations fail, the Golden Rules, and the end-to-end PDM process - the groundwork the rest of the course builds on.
Module summary key points & takeaways to keep
Migrations fail on data and ownership, not code - and PDM exists to close the gap between the two.
Key points to remember
- Most migrations overrun or fail (roughly 40-50%+; Bloor 2011, Data Migration Pro 2014) - the cause is data, quality and ownership, not technology.
- The Responsibility Gap is the core problem: the business owns the data, the technologists are handed the migration, and nobody owns the join. PDM closes it with one virtual team.
- The four Golden Rules underpin everything: it's a business issue; the business knows best; fit-for-purpose quality; if you can't count it, it doesn't count.
- Two workstreams run in parallel - Technical and Business Engagement - and Super Smart Tasks make the work measurable and governable.
Put it to work
- On day one, name the Data Owner for each source - if you can't, that's your first finding.
- Frame the migration to your sponsor as a business issue with a technical component, not an IT task.
- Start counting early: systems, records and known issues. Numbers are how you govern the project.
This module is conceptual - your first templates arrive in Module 03 (Analysis).
Strategy & Scope
The Migration Strategy Guide, how PDM decomposes a large migration, and how scope is set before the analysis work begins.
Module summary key points & takeaways to keep
Set the rules of the game before touching data: the Migration Strategy Guide and a deliberate decomposition of scope.
Key points to remember
- The Migration Strategy Guide (MSG) is the master governance document - it tailors PDM to your organisation; undisclosed policies are a major risk.
- Large migrations are decomposed along four dimensions; Key Business Data Areas group entities by ownership and set the sequence.
- A Unit of Migration is the lowest level of granularity for which rollback occurs - define it before the run.
- Read an SI proposal for the fixed-price perverse incentive; PDM accreditation is one signal of fit.
Put it to work
- Write (or demand) the MSG first - flush out hidden policies before they become surprises.
- Agree your Units of Migration and rollback boundaries with the business up front.
Templates for this module: Migration Strategy Guide template, Software selection matrix. Get the templates →
The Analysis Phase
Landscape Analysis, Gap Analysis & Mapping, stakeholder management, the Business Transformation Register, and the Data Quality Rules process - the heart of PDM.
Module summary key points & takeaways to keep
The heart of PDM: find every data store, map it to the target, and run the DQR process that quantifies and fixes quality.
Key points to remember
- Landscape Analysis (the LDS) systematically finds every legacy store - including the local and personal ones the corporate inventory misses.
- Gap Analysis & Mapping produces the five mapping-rule types; the mapping is the primary specification for the ETL build.
- The DQR process - Process, Board, Forms, Repository - is the engine that quantifies, prioritises and resolves data quality issues.
- Start DQR before serious issues appear, so the process is familiar when the hard ones arrive.
Put it to work
- Treat the LDS as living: keep finding stores throughout, don't freeze the list early.
- Stand up the DQR list and Board on week one - the repository is cheap insurance.
- For every mapping, name the rule type and flag One Way Street transformations early.
Templates for this module: Legacy Data Store (LDS) template, LDS interview guide, Data mapping template, Semantic issue log, DQR list template, DQR board agenda template, DQR dashboard specification, Key Data Stakeholder Map template, Business Transformation Register template, System Retirement Plan template. Get the templates →
Governance & Methods
Configuration and release management, the DMZ and its commercial incentives, and how PDM works across waterfall, agile, and blended delivery.
Module summary key points & takeaways to keep
Run the migration like a controlled, iterative programme - and define the commercial boundary before money is at stake.
Key points to remember
- Configuration & release management give an iterative, fortnightly cadence; releases are "push"-planned by the DQR Board, not pulled by the dev team.
- The DMZ is the contractual and operational boundary between client and supplier - define it before any fixed-price contract is signed.
- PDM works with waterfall, agile or blended delivery; pure agile is a poor fit because of the non-negotiable go-live and sign-offs.
Put it to work
- Version-control every deliverable as a Configurable Item.
- Pin down the DMZ in writing before signing - data-quality disputes otherwise become commercial disputes.
This module is conceptual - your first templates arrive in Module 03 (Analysis).
Technical Design
The end-to-end migration architecture, ETL design, System Retirement Plans, and decommissioning and fallback design.
Module summary key points & takeaways to keep
Design the whole journey - legacy to staging to target - and plan for the runs that go wrong before they do.
Key points to remember
- Three zones: legacy -> staging -> target. The staging area is the migration team's controlled workspace for profiling, transformation and lineage.
- The ETL Content Matrix documents source, transformation, target, error handling and validation per entity.
- One Way Street transformations can't be reversed - identify them early and design fallback accordingly.
- The go/no-go for each run is the Data Owners' and governance's call, on evidence, against criteria set beforehand.
Put it to work
- Build the System Retirement Plan from Data Owner interviews, not assumptions.
- Decide fallback and rollback per Unit of Migration before the first trial run.
Templates for this module: Business Transformation Register template, System Retirement Plan template. Get the templates →
Build, Test & Execute
Building the ETL, continuous testing, the cutover go/no-go, and clean legacy decommissioning.
Module summary key points & takeaways to keep
Build from the design, test continuously, and treat decommissioning as the point of the whole exercise.
Key points to remember
- Continuous Testing runs throughout the project, not as a phase at the end.
- Technical validation confirms the ETL ran; business acceptance confirms the data is right - they are different jobs.
- Cutover go/no-go is decided against pre-set criteria; hypercare is a defined post-go-live phase with an exit.
- Legacy decommissioning is the business case being realised - the reason the project existed.
Put it to work
- Write the go/no-go criteria before the run, and present evidence against them - don't decide on the day by feel.
- Separate logical decommissioning (business sign-off) from physical (retention-driven, often months later).
This module is conceptual - your first templates arrive in Module 03 (Analysis).
Data Migration Software
The software landscape, choosing tools to fit the PDM process, and the DHGS tooling decision - with an honest note on how fast tools are changing.
Module summary key points & takeaways to keep
PDM is tool-agnostic: specify the process, then choose software to fit it - not the other way round.
Key points to remember
- PDM specifies the process; software is selected to support it (scale, complexity, DMZ compatibility, auditability, skills).
- Purpose-built ERP tools suit standard objects between known platforms; complex non-standard systems often need a hybrid approach.
- Don't accept an SI's tool preference without an independent assessment of fit.
Put it to work
- Score options against the PDM selection criteria - documented in the MSG - not vendor marketing.
- Favour tooling with built-in data lineage where many-to-many mappings exist.
This module is conceptual - your first templates arrive in Module 03 (Analysis).
DHGS Case Study
The full DHGS migration brought together end to end - the policies, the SI proposals, and the lessons learned, now yours to work through.
Module summary key points & takeaways to keep
The full method on one project: policies, SI proposals, and a field-by-field gap analysis you work through yourself.
Key points to remember
- DHGS brings the whole methodology together end to end on a real-shaped, ten-system migration.
- Mapping cardinality is the crux: many-to-one is easy once agreed; one-to-many and many-to-many need a DQR and expert input.
- Not every target field needs a legacy source (system-generated keys, optional nulls), and a small known fallout is handled by an exclusion rule plus a transitional business process.
Put it to work
- When a mandatory target field has no source, search the LDS for a local store before inventing a default.
- Record exclusion-rule fallout in the Detailed Cutover Plan, with the fix-in-target step scheduled.
This module is conceptual - your first templates arrive in Module 03 (Analysis).
Crisis Recovery
Rescuing a failing data migration: stabilisation, planned recovery, and repairing the DMZ.
Module summary key points & takeaways to keep
Rescuing a failing migration is a discipline: stabilise, recover in planned releases, then mop up and repair the DMZ.
Key points to remember
- Almost every failing project shares two root causes: an open Responsibility Gap and uncontrolled issues with no single DQR log.
- Stabilise first - one consolidated DQR log, re-engaged business owners - before trying to fix anything.
- Recover "Agile" in the PDM sense: planned releases, collaborative DQR prioritisation, iterative delivery.
- Work least-worst-case: choose consciously between bad options, get business sign-off, document, and move on without relitigating.
Put it to work
- Your first concrete act on a rescue: consolidate every outstanding issue into one DQR log.
- Escalate non-migration problems (ERP, change management) to their owners; stay strictly on data migration.
This module is conceptual - your first templates arrive in Module 03 (Analysis).