Eighteen years is a long time in technology. When the first edition of Practical Data Migration was published in 2006, cloud computing was in its infancy, Agile was still fighting for mainstream acceptance, and SaaS platforms were not yet a dominant force in enterprise IT. The data migration landscape looked very different.
PDMv3, published in 2020, reflects that changed world. Yet practitioners who learned the methodology from the first edition will find everything that matters is exactly where they left it.
PDMv1 (2006): establishing the foundations
The first edition had one primary objective: establish that data migration was a discipline with its own structure, its own failure modes, and its own requirements - and that those requirements were not being met by the generic project management and software development methodologies that most organisations were applying to the problem.
The Golden Rules were there from the beginning. The Responsibility Gap was named and described. The core insight - that data migration is a business problem, not a technical problem - was stated clearly and argued at length.
What the first edition lacked was the full nine-module framework. The methodology was more principled than procedural: it told you what mattered and why, but the detailed process architecture - the named modules, the defined artefacts, the DQR board, the BTR - came later.
It was, nonetheless, the first non-proprietary methodology for data migration ever published. That alone made it transformative.
PDMv2 (2012): adding structure
The second edition added the structural scaffolding that practitioners had been asking for since the first. The nine-module framework was formalised. The artefacts - the DQR process, the KDSM roles, the BTR templates - were defined. The end-to-end process diagram appeared for the first time.
Attendees at the Data Migration Matters conference in 2014 noted the new process flowchart - described as “a large printed poster” - as a significant step. For the first time, practitioners had a visual map of the complete PDM process that they could use to explain the methodology to sponsors, to clients, and to new team members.
PDMv2 also introduced more explicit guidance on the DMZ - the contractual and operational boundary between client and supplier - reflecting how the commercial dynamics of data migration had evolved as the market for migration services matured.
PDMv3 (2020): adapting to a changed world
By 2020, three things had changed the data migration landscape significantly:
Cloud and SaaS. The rise of cloud-native and SaaS platforms changed the shape of many migrations. Data no longer always moved to an on-premise target system with full access to its schema. SaaS migrations often involve restricted access, API-based loading, and vendor-controlled transformation. PDMv3 addressed these scenarios explicitly.
Agile. When PDMv1 was published, most large enterprise programmes ran on waterfall. By 2020, Agile was ubiquitous - and PDM needed to be explicit about how it worked within sprint-based delivery environments. PDMv3 added a dedicated chapter on working across waterfall, Agile, and blended approaches, clarifying that PDM is compatible with both and explaining the specific adaptations required for each.
Supply-side maturation. In 2006, the market for specialist data migration services was thin. By 2020 it was established, with specialist suppliers, recognised tools, and established commercial patterns. PDMv3 updated its guidance on the commercial relationship between client and supplier - including the perverse incentive dynamics that can emerge in fixed-price contracts - to reflect this matured landscape.
Two new chapters were added. The core principles were not changed.
What never changed
The Four Golden Rules of PDMv1 are identical in PDMv3. The Responsibility Gap is still described in the same terms. The insistence that data migration is a business issue, not a technical issue, has not softened in eighteen years of evidence that it is still being violated on projects across every industry.
This is not stubbornness. It is a reflection of the fact that the structural problems that cause migrations to fail have not changed. The technology has evolved dramatically. The human and organisational dynamics have not.
A project that treats its migration as a technical delivery, hands data quality problems to IT, and hopes the business will engage when needed is as likely to fail today as it was in 2006. PDM was built to prevent that - and the core of how it does so has not needed to change.
PDMv4?
The methodology continues to evolve. The data landscape of 2026 - AI-assisted transformation, large language models, increasingly complex multi-cloud environments - will eventually produce a fourth edition. What it will say about the Golden Rules is easy to predict: nothing new.