Learning Objectives
By the end of this lesson you will be able to:
- Describe the DHGS organisation and the business context for its migration
- Identify the legacy systems involved and the target platform
- Explain the scope and scale of the migration project
- Recognise the structural factors that made this project challenging
About 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 - particularly specialist sands and coarse substrate - to fulfil customer orders.
DHGS has a broad customer base: fewer than 200 large wholesale customers plus more than 1,000 small and medium-sized wholesale accounts, as well as an online retail trade. The business has identified that smaller wholesale orders are not profitable and is actively looking to shift its focus toward bulk customers and online trade. This strategic intent is directly relevant to the migration: not all customer data is equally worth carrying forward.
DHGS maintains its own fleet - large lorries, maintenance vans, and sales and directors’ cars - and also leases vehicles and contracts third-party hauliers from a network of small operators. Fleet management is handled by a small dedicated team using their own systems.
DHGS has a significant investment in physical infrastructure: gravel extractors, cleaners, and graders, with all the ancillary maintenance operations one would expect. Some equipment is maintained in-house; some is maintained under contract. Some is owned outright; some is leased or rented. Across all of this, different ownership and maintenance arrangements generate different data obligations.
In addition to these sector-specific operations, DHGS runs the normal company functions: sales, purchasing, HR, and finance.
The Legacy Landscape
DHGS’s systems had grown up independently to serve different parts of the business. At the point the migration project was commissioned, the landscape comprised:
| System | Coverage |
|---|---|
| Heavy Plant | Gravel extractors, cleaners, graders, and ancillary equipment |
| Cars and Vans | Sales representatives’ and directors’ vehicles |
| Commercial Vehicles | Lorries and larger fleet assets |
| Finance | Sales, purchasing, and payroll |
| Human Resources | Employee records and HR processes |
| Sales Forecasting | Departmental system |
| Customer Relationship Management | Departmental system |
| Sales Planning | Departmental system |
| Bid Work | Departmental system |
| Large Projects | Departmental system |
There was no integration between these systems. Reporting across business areas required manual reconciliation. Data held in one system was not reliably consistent with data held in another. The organisation had reached the point where this fragmentation was operationally unsustainable.
The Migration Scope
DHGS’s decision was to consolidate all systems onto a single ERP platform. The migration therefore needed to bring together data from multiple distinct systems - each with its own data model, data quality history, and ownership - into a single coherent target.
The project team was called in to assist in the planning, management, and execution of the data migration. The scope covered the full range of Key Business Data Areas across the legacy estate: physical assets, vehicles, customers, suppliers, employees, financial records, and associated reference data.
The Conceptual Entity Diagram produced during scoping showed the relationships between these areas and formed the basis for decomposing the work into manageable Units of Migration. Given the breadth of the legacy landscape, decomposition was essential - attempting to migrate everything at once would have been unmanageable.
Not all data in scope was of equal quality, and not all of it was equally worth migrating. The decision to exit the smaller wholesale customer segment, for example, had direct implications for which customer records needed to be carried forward and which could be left behind.
The Business Transformation Complication
The Production Director had decided to use the ERP switchover to change the physical asset maintenance methodology to Activity Based Costing (ABC). This was not simply a data migration - it was a data migration running in parallel with a significant change to how the business would operate.
This is a pattern PDM explicitly addresses. When the target state differs from the source state not just technically but operationally, the migration must reflect the business as it will be at go-live, not as it is today. That requires close coordination between the migration team and the business transformation workstream, and it means some data cannot simply be moved - it must be transformed to reflect new structures, classifications, or methods that do not yet exist in the source.
Why This Project Was Difficult
Several factors combined to make the DHGS migration a genuine challenge:
Scale and breadth. Ten or more source systems, spanning physical assets, vehicles, people, customers, suppliers, and finance. Each system had its own data model, its own data quality history, and its own business owner.
No single source of truth. Multiple systems held overlapping or related data with no reliable mechanism for reconciling conflicts. Resolving them required business decisions, not just technical ones.
Business transformation in parallel. The move to ABC meant the migration team could not simply map source data to target fields. They had to understand the future operating model well enough to transform the data to fit it.
Strategic data decisions. The planned exit from smaller wholesale accounts meant the migration team had to work with the business to agree which customer data was in scope and which was not - before any technical work could begin.
Supplier and contractor involvement. External parties were involved in parts of the project, introducing the contractual and commercial dynamics discussed in Module 04.
The Team
The migration was run by a small core team using PDM as its methodology. This gave them a shared language, a set of tools, and a process for managing the IT-Business interface. It did not remove the difficulty - but it gave the project a structure within which the difficulty could be managed.
The roles that mattered most:
- Data Migration Analysts - responsible for driving the analysis, managing the Gap Analysis Mapping, and coordinating the Data Quality Rules process
- Business Data Owners - identified per data area, responsible for making decisions about their data when the analysis surfaced issues
- ETL developers - responsible for building and running the extraction, transformation, and load routines
- Project management - keeping the migration track aligned with the wider programme
The lessons that follow trace what this team actually did - from strategy through to go-live and decommissioning.
Key Takeaways
- DHGS is a regional gravel and infill products supplier consolidating ten or more legacy systems onto a single ERP platform
- The legacy estate spanned heavy plant, vehicles, finance, HR, customers, and several departmental systems - each with its own data model and ownership
- A parallel decision to move to Activity Based Costing (ABC) meant the migration had to reflect a future operating model, not just the current one
- Strategic decisions about which customers and data were in scope had to be made before technical work could begin
- The project used PDM as its methodology, giving the team a structured approach to an inherently complex task