Course summary

Migrations fail on data and ownership, not code - and PDM exists to close the gap between the two.

• 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.

Set the rules of the game before touching data: the Migration Strategy Guide and a deliberate decomposition of scope.

• 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.

The heart of PDM: find every data store, map it to the target, and run the DQR process that quantifies and fixes quality.

• 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.

Run the migration like a controlled, iterative programme - and define the commercial boundary before money is at stake.

• 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.

Design the whole journey - legacy to staging to target - and plan for the runs that go wrong before they do.

• 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.

Build from the design, test continuously, and treat decommissioning as the point of the whole exercise.

• 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.

PDM is tool-agnostic: specify the process, then choose software to fit it - not the other way round.

• 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.

The full method on one project: policies, SI proposals, and a field-by-field gap analysis you work through yourself.

• 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.

Rescuing a failing migration is a discipline: stabilise, recover in planned releases, then mop up and repair the DMZ.

• 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.