Every methodology starts somewhere. For Practical Data Migration, the earliest seed was planted in 1997 at a regional water company. I was young, technically confident, and about to be taught the most important lesson of my career.
The problem I thought I had solved
I had been tasked with building a SQL database model for a data migration involving sewage treatment plant assets. The work was technical and detail-oriented - my natural territory. I gathered data from the finance department’s asset register, built the model, and was satisfied with the result.
When I presented to the district manager responsible for the facilities, he looked at the model for a moment, then looked at me.
“How many high-lift pumps can you see?”
I looked at the model. One.
“Go and look at the plant.”
There were two.
What had gone wrong
The explanation was straightforward once I understood it, though I hadn’t seen it coming. The water company had recently consolidated sites - a nearby facility had been decommissioned and its operations merged with this one. The finance department’s asset register reflected the pre-consolidation state: some assets that existed operationally were missing from the register, and some assets recorded in the register were from the redundant facility and no longer present.
My technically correct data extract from a formally authorised source had produced a model that was operationally wrong. I had high confidence in bad data.
What changed
A water engineer on the team - someone I hadn’t worked closely with until that moment - told me she had already built an Access database for maintenance planning. It was an unofficial system, built by someone who actually knew the assets, and it was more accurate than the authorised register.
More valuably, she introduced me to local business domain experts across the different sewage districts - the people who worked with these systems daily, who knew which records were reliable, which were stale, and what the discrepancies meant.
The project changed shape from that point. Instead of a technical exercise in extracting and loading data, it became a collaborative process of understanding what the data actually represented - who created it, who used it, where the unofficial sources were, and what “correct” meant for this specific migration.
The lesson that didn’t go away
That experience stayed with me through every project that followed. Business-led migrations consistently produce better outcomes than technically-led ones - not because business people are better at data, but because they carry knowledge the technical team cannot derive from the data alone.
Semantic resolution - understanding what a field actually means in business terms, not just what its data type is - requires the people who use it. Fault management - identifying which discrepancies matter and which don’t - requires the people who care about the outcome. Data source identification - knowing which spreadsheet in which district office actually has the right figures - requires the people who built those workarounds.
Working with knowledgeable staff who maintain systems daily doesn’t just improve data quality. It builds genuine data ownership: people who understand why decisions were made, who feel invested in the outcome, and who are ready to live with the result after the project ends.
None of that is available from the asset register.
This was step 1 of a long journey. PDM took another decade of projects before it became a methodology I was confident publishing. But the district manager’s question - “How many high-lift pumps can you see?” - is still the best summary I have of why data migration is a business problem, not a technical one.