Data migration is a business problem.
PDM solves it that way.
A structured, specialist methodology for planning and executing enterprise data migrations - built on 20+ years of real-world delivery across utilities, financial services, healthcare, manufacturing, and the public sector.
What is a data migration?
The industry often treats data migration as a technical task - extract, transform, load, done. PDM offers a more precise and more useful definition:
"The selection, preparation, extraction, transformation and permanent movement of appropriate data which is of the right quality to the right place at the right time, and the decommissioning of legacy data stores." - Johny Morris, Practical Data Migration
Every word is deliberate. Selection means not all data migrates - business judgment decides. Appropriate quality means quality is relative to purpose, not abstract perfection. Permanent movement means this is one-way and irreversible. And decommissioning means the job is not done until the legacy system is retired - which is almost always why the project existed in the first place.
Why migrations fail - and it's not the technology
40–60% of large-scale data migration projects run over time, over budget, or fail entirely (Bloor Research). That figure has barely moved in decades. The reason is not the tools - it's the structure of how projects are run.
The Responsibility Gap
Every data migration reaches a point where technical analysis alone is not enough. Data quality issues surface that only the business can resolve - questions of meaning, ownership, and priority that no amount of ETL logic can answer.
When that happens, questions go to the business. The business, already overwhelmed by day jobs and managing the disruption of a system change, resolves what it can. The rest queues. IT waits. Deadlines loom. Both sides grow frustrated - and retreat behind their own assumptions about whose problem it is.
"The enterprise will have accepted the passive role offered to it… The implicit contract between enterprise and the project has gone wrong. They have misled one another."
Root causes, not symptoms
- Projects treat migration as a technical delivery, not a business programme
- Business engagement is an afterthought, not a design principle
- No shared language between IT and business teams
- Data quality expectations are never made explicit up front
- Legacy system retirement - the original business case - is never planned for
The technology is rarely the problem
In 20+ years of migrations across major programmes, Johny Morris can recall only a single case where migration technology itself was the root cause of failure. The problems are almost always organisational and methodological - which means they are solvable with the right approach.
The Four Golden Rules
PDM rests on four non-negotiable principles. Violating any one of them is a reliable predictor of project failure. Following all four is the foundation of every successful migration.
Data migration is a business issue, not a technical issue
The most commonly violated rule - and the root cause of most failures. Business teams own the data, and they own the outcome. IT can model, normalise, and transform - but it cannot see the business meaning behind bits and bytes. Technologists are dangerously arrogant when they assume otherwise.
When violated: Data quality problems land with IT, which has no mandate or knowledge to resolve them. The Responsibility Gap opens.
The business knows best
Every enterprise holds all the knowledge needed to migrate correctly - in its people, not its databases. Business Domain Experts (the frontline staff with daily contact with legacy systems) are a formal role in PDM, not an afterthought. No technical analysis substitutes for their knowledge.
When violated: Semantic issues go unresolved, unofficial data sources are missed, and the migrated data fails to represent business reality.
No organisation needs, wants, or will pay for perfect data quality
The most challenging assertion in PDM - and the most important. Data migration is a project with a deadline and a business case. Perfect quality is almost never achievable and often not necessary. What matters is appropriate quality for the target system and its business processes.
"Plan to accept it, control it and prioritise your decisions from the outset."
When violated: Projects chase perfection, miss deadlines, and make rushed decisions at the worst possible moment - under cutover pressure.
If you can't count it, it doesn't count
PDM is a measured methodology. Every data quality issue is quantified: how many records, what percentage, what impact on migration. Qualitative assessments ("data quality is quite good") are not actionable. Quantitative assessments enable management, reporting, and decision-making.
When violated: Projects cannot demonstrate readiness for cutover, cannot compare data sources, and cannot report progress honestly to programme governance.
The end-to-end process
PDM organises a migration into nine modules across two workstreams - technical delivery and business engagement - running in parallel throughout the project. Every module produces defined outputs that feed into the others.
Migration Strategy & Governance
Project framing, policies, and governance structures. Defines the migration form (big bang, phased, or parallel), establishes the initial inventory of legacy data stores, and sets up the controls that feed everything else.
Landscape Analysis
Systematic discovery and documentation of every legacy data store - every database, spreadsheet, and file that holds data relevant to the migration. "Like building a bridge - you need sound foundations on both sides."
Gap Analysis & Mapping
Maps legacy data structures to target system structures. Where the technical complexity of migration lives - resolving semantic differences, identifying missing data, and producing the mapping rules for ETL execution.
Data Quality Rules
The hub for all data quality decisions, fixes, and remediation. The primary mechanism for business-led data quality work and the main "Super Smart Task" - putting business teams in ownership of the decisions only they can make.
Key Data Stakeholder Management
Finding and formally engaging the people who know the data - Data Owners, Business Domain Experts, and Technical System Experts. Not a one-time activity; continues as new data stores are discovered and issues arise.
Business Transformation Realisation
Captures requirements of data owners for their own migration - what they need to train on, test, retain, and experience at go-live. Converts resistance into specification. Provides acceptance criteria for the migration team.
Migration Design & Execution
Technical design and execution of the migration - ETL architecture, extract, transform, and load design, through to the migration runs themselves. Depends on outputs from all other modules.
Legacy Decommissioning
Retirement of legacy systems after successful migration. Not an afterthought - decommissioning is almost always the original business case (reducing costs, eliminating licences, freeing staff). PDM treats it as a first-class deliverable.
Continuous Testing
Not a phase at the end - runs throughout the project. Each data release is tested. DQR metrics feed directly into test readiness. The final migration run is the last in a series of tested, validated releases.
The DMZ - Demilitarised Zone
PDM defines a formal contractual and operational boundary between client and supplier: the DMZ. It specifies what data flows across the boundary and in what form, who owns data quality issues on each side, and what commercial protections apply. Critical on fixed-price contracts where ambiguity about ownership is a reliable source of dispute.
Watch the methodology explained
Johny Morris walks through the full PDM process in this 38-minute presentation from November 2019 - landscape analysis, gap analysis, DQR, legacy decommissioning, and the DMZ.
"You'll spend more time on a data migration working with your business partners and colleagues than you will with the actual technology." — Johny Morris, November 2019 Watch at 1:54 →
"It's a bit like building a bridge - you've got to do your surveying on both sides of the river." — Johny Morris, on Landscape Analysis Watch at 6:04 →
What PDM gives practitioners
PDM is not a theoretical framework - it is a working toolkit, designed to be used on live projects. It scales from enterprise-wide programmes to smaller business change projects.
A complete map of the problem
Nine modules covering every aspect of a migration - nothing omitted, nothing duplicated. Use the full methodology on large programmes or select the modules relevant to your project scope.
Business engagement built in
Super Smart Tasks, DQR boards, KDSM roles, and BTR interviews give business teams real ownership over their data - transforming them from passive recipients of change into active partners in the migration.
Measurable progress at every stage
DQR metrics, release cycles, and readiness criteria mean you can always show programme governance exactly where the migration stands - in numbers, not qualitative assessments.
Commercial clarity
The DMZ concept gives both client and supplier a defined interface that protects both parties. On fixed-price contracts in particular, it prevents the ambiguity about data quality ownership that triggers the most damaging disputes.
Risk managed proactively
By building the single virtual team from the start - business and IT working within the same process - PDM spots and resolves challenges while there is still room to be flexible. Problems surface early, not at cutover.
A real finish line
Legacy decommissioning is planned from day one, not treated as someone else's problem after cutover. PDM migrations finish: the legacy system is retired and the business case is realised.
"Follow the methods and principles in this book and you will be guided to success. You will even make lasting allies out there in the real world of your enterprise." - Johny Morris, Practical Data Migration
Go beyond learning by doing
Reading about PDM gives you a framework. Applying it gives you experience. But a PDM Certification gives you something more - a structured, recognised professional approach that colleagues, clients, and employers can rely on. It is the difference between knowing what good looks like and being able to consistently deliver it.
Read the book
Practical Data Migration by Johny Morris, published by BCS - the definitive text on the methodology, covering every module, tool, and principle in full depth.
Get the BookTake the course
Work through all nine PDM modules on Hopp Academy using the DHGS case study. Video lessons, text lessons, quizzes, and downloadable templates - at your own pace.
Start LearningGet certified
Complete the course and earn your PDM Certification - formal recognition of a structured, professional approach to data migration. Join a community of practitioners who deliver with confidence.
Get Certified