PDM Academy
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.
00
Course Introduction
Welcome, what the course covers, and how to get the most from it. A short orientation before the methodology begins. No quiz.
01 Welcome & What This Course Covers Why data migrations fail so routinely, why there is a better and teachable way, and a tour of what the course covers. 02 About the PDM Methodology Where PDM came from - Johny Morris, the BCS book, three editions - and the one idea at its core: data migration is a business issue. 03 How to Use This Course How the modules build on each other, how the DHGS case study accumulates, and how to use the lessons, templates and quizzes.
01
Foundations
Why migrations fail, the Golden Rules, and the end-to-end PDM process - the groundwork the rest of the course builds on.
01 Common Misconceptions Why data migration projects fail so often, and the widely held beliefs about migration that set projects up to fail before they start. 02 The Responsibility Gap The gap between the business, who own the data, and the technologists, who are handed the migration - and why bridging it is the heart of PDM. 03 The Golden Rules of Data Migration The Four Golden Rules that underpin every PDM project, from "data migration is a business issue" to "if you can't count it, it doesn't count". 04 Super Smart Tasks How PDM turns vague good intentions into tasks that are measurable, governable, and resistant to the pressures of a live project. 05 The PDM End-to-End Process The full PDM process in one pass - the nine modules across two workstreams, and how they fit together from strategy to decommissioning. 06 Meet DHGS: The Case We'll Follow Meet Deep Hole Gravel Services - the regional gravel company whose ten-system migration runs through the rest of the course, and the cast you'll see again. ? Module 01 Quiz: Foundations Consolidate the module. Retake any time - your best score is saved.
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).
02
Strategy & Scope
The Migration Strategy Guide, how PDM decomposes a large migration, and how scope is set before the analysis work begins.
01 Introduction to the Migration Strategy Guide (MSG) The master governance document of a PDM migration - what the MSG contains, how it tailors PDM to your existing governance, and why undisclosed policies are a major risk. 02 Strategy Matrices The analytical tools that make the key strategic choices explicit - migration form, quality versus time versus budget, methodology, and how policies interact. 03 Assessing Systems Integrator Proposals How to read an SI proposal for a data migration - the perverse incentive in fixed-price contracts, what a good proposal addresses, and PDM accreditation. 04 Project Decomposition Overview Why large migrations have to be broken down, the four dimensions PDM decomposes along, and the role of the Conceptual Entity Model. 05 Key Business Data Areas How KBDAs group entities by business ownership, set the migration sequence through their dependencies, and carry the policies into the ETL and DQR work. 06 Units of Migration The lowest level of granularity for which rollback occurs - the business and technical views, why units must be defined before the run, and the DHGS worked example. 07 Conceptual Entity Diagrams & ERDs The four PDM model types, how to read a simple box-and-crow's-feet ERD, and why you should never trust a data model you are handed without checking it. ? Module 02 Quiz: Strategy & Scope Consolidate the module. Retake any time - your best score is saved.
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 →
03
The Analysis Phase
Landscape Analysis, Gap Analysis & Mapping, stakeholder management, the Business Transformation Register, and the Data Quality Rules process - the heart of PDM.
01 Landscape & Discovery - The LDS Landscape Analysis (LA) is defined in PDM as: 02 Completing the LDS Template The LDS template is designed to be completed iteratively - not all fields can be filled from the start, and some require engagement with the Data Owner or Business Domain Experts. 03 Gap Analysis & Mapping (GAM) Gap Analysis & Mapping (GAM) is the process of mapping legacy data structures to target data structures, identifying the gaps, and producing the extraction, transformation, and load rules that the... 04 Completing the Mapping Template The PDM mapping template captures all five mapping rule types for each source-to-target field pairing. A well-completed mapping is the primary specification document for the ETL build - if the... 05 Key Data Stakeholder Map (KDSM) Key Data Stakeholder Management (KDSM) is the PDM process for finding, documenting, and maintaining the people the project needs to engage with across the business and technical landscape. 06 Business Transformation Register (BTR) A Business Transformation Realisation (BTR) - also called a System Retirement Plan in some versions of the methodology - is a document created through one-to-one interviews with each Data Owner... 07 The Change Curve The Change Curve describes the predictable emotional journey that individuals and organisations experience when facing significant change. The specific stages vary between models, but the core... 08 Data Quality Rules (DQR) - Concepts Data quality issues are inevitable in any data migration. The question is not whether they will appear, but how the project will manage them when they do. 09 Working with the DQR List Each DQR item is documented on a standard form. Working through the DHGS example of DQR0004 (Product Price Consistency): 10 DQR Dashboard Design As the DQR list grows - and on a large project it will grow to hundreds of items across multiple KBDAs and LDS - ad hoc reporting becomes unmanageable. The DQR Board needs to see what needs... ? Module 03 Quiz: The Analysis Phase Consolidate the module. Retake any time - your best score is saved.
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 →
04
Governance & Methods
Configuration and release management, the DMZ and its commercial incentives, and how PDM works across waterfall, agile, and blended delivery.
01 Config & Release Management A Configurable Item is any project deliverable that should be version controlled. 02 DMZ & Commercial Interests The DMZ - Demilitarised Zone - is the contractual and operational boundary between the client organisation and any external supplier on a data migration project. 03 Waterfall, Agile & Blended Approaches When a project asks \"are we doing waterfall or agile?\", they are asking about how they will organise and deliver work. This is a governance decision captured in the MSG. ? Module 04 Quiz: Governance & Methods Consolidate the module. Retake any time - your best score is saved.
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).
05
Technical Design
The end-to-end migration architecture, ETL design, System Retirement Plans, and decommissioning and fallback design.
01 End-to-End Design Overview A PDM migration has three zones: 02 ETL Architecture ETL (Extract, Transform, Load) is used in both data integration (ongoing data flows between live systems) and data migration (one-time movement of data from legacy to target). The same tools are... 03 ETL Design in Practice The mapping template (produced in GAM) is the input to the ETL design. Each mapping entry translates to one or more ETL components: 04 Decommissioning & Fallback Design Every migration run carries risk. Even with extensive trial runs and validated data, the final go-live migration can encounter problems: a volume that exceeds test conditions, a business process... 05 System Retirement Planning A System Retirement Plan (SRP) - also described in some modules as the Business Transformation Realisation (BTR) - is a document that captures, for a specific legacy data store, the conditions... 06 Migration Design Overview Migration Design & Execution (MDE) is the PDM module that takes all the analytical and governance outputs from earlier phases and translates them into a technical design for the migration runs. ? Module 05 Quiz: Technical Design Consolidate the module. Retake any time - your best score is saved.
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 →
06
Build, Test & Execute
Building the ETL, continuous testing, the cutover go/no-go, and clean legacy decommissioning.
01 The Build Phase The build phase translates the ETL design (Content Matrix, mapping documents, release plan) into working ETL code. The development team implements the extraction, transformation, and load... 02 Testing Your Migration Continuous Testing (CT) is a PDM module - the ninth - but unlike the other modules, it is not a phase. It runs throughout the project. 03 Execution & Go-Live The cutover window is the period between the last write to the legacy system and the first write to the target system in production. During this window: 04 Legacy Decommissioning Legacy decommissioning is not the end of the project - it is the reason for the project. ? Module 06 Quiz: Build, Test & Execute Consolidate the module. Retake any time - your best score is saved.
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).
07
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.
01 The Data Migration Software Landscape PDM is tool-agnostic. The methodology can be applied using any combination of software tools, or with no specialist tools at all on smaller projects. What PDM specifies is the process - the... 02 Selecting the Right Tool Software selection for a data migration is documented in the MSG. PDM identifies the following selection criteria: 03 Case Study: Software in the DHGS Project Deep Hole Gravel Services is migrating from seven or more legacy systems - covering equipment, vehicles, finance, HR, sales, CRM, and departmental spreadsheets - onto a single ERP platform. ? Module 07 Quiz: Data Migration Software Consolidate the module. Retake any time - your best score is saved.
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).
08
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.
01 Introducing DHGS Deep Hole Gravel Services Plc (DHGS) is a regional provider of gravel and infill products. It operates its own gravel pits and supplements supply by taking deliveries from third-party providers -... 02 Exercise: Identifying Migration Policies One of the first tasks on any PDM project is to identify the migration policies that will govern the project. These policies shape every subsequent decision - what data is in scope, how quality... 03 Migration Policies: Solution The DHGS scenario contains direct or implied evidence for several policy categories - but not all eight. Six categories are either entirely absent from the text or only partially inferable. That... 04 Exercise: Evaluating SI Proposals DHGS has decided to bring in a Systems Integrator (SI) to support the data migration. Two suppliers have been shortlisted and have submitted proposals. You have been asked to evaluate them and... 05 SI Proposals: Analysis and Recommendation Neither proposal is straightforwardly good or bad. Both have genuine strengths. Both have serious concerns. A PDM-trained practitioner should be able to articulate those concerns clearly - and use... 06 DHGS Strategy and Scoping Before any data was touched, the DHGS project team worked through the Migration Strategy Guide (MSG). This is not a document that gets produced and filed - it is a structured set of decisions that... 07 DHGS Analysis and Data Quality Strategy tells you what you are doing. Analysis tells you what you are working with. For DHGS, the analysis phase was where the true scale of the data quality challenge became visible. 08 DHGS Technical Design The analysis phase produced a detailed picture of the data and its problems. The technical design phase translated that picture into a plan for how data would actually move - extracted from... 09 DHGS Build, Test and Execute The build phase for DHGS followed directly from the technical design. The ETL Content Matrix and the System Retirement Plan were the primary inputs. The outputs were working ETL routines, a tested... 10 Lessons Learned 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... ? Module 08 Quiz: DHGS Case Study Consolidate the module. Retake any time - your best score is saved.
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).
09
Crisis Recovery
Rescuing a failing data migration: stabilisation, planned recovery, and repairing the DMZ.
01 When Migrations Go Wrong 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... 02 Phase 1: Stabilisation Stabilisation does not mean fixing the migration. It means stopping the situation from getting worse and creating the conditions under which controlled, effective work becomes possible. 03 Phase 2: Planned Recovery Phase 2 begins when stabilisation is complete - when you have a consolidated DQR log, business stakeholders engaged, and a communicable plan. 04 Phase 3: Mop-Up & Repairing the DMZ Once Phase 1 and Phase 2 are complete - DQRs consolidated, stakeholders engaged, release plan running - there is a set of things that a well-run project would have completed months ago but that... ? Module 09 Quiz: Crisis Recovery Consolidate the module. Retake any time - your best score is saved.
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).