Learning Objectives
By the end of this lesson you will be able to:
- Describe the strategy decisions DHGS made at the start of the migration project
- Explain how the Migration Strategy Guide informed those decisions
- Identify how project decomposition was applied to the DHGS data landscape
- Understand how the Conceptual Entity Diagram structured the migration scope
Starting With Strategy
Before any data was touched, the DHGS project team worked through the Migration Strategy Guide (MSG). This is not a document that gets produced and filed - it is a structured set of decisions that shape every downstream activity. Getting it wrong at this stage amplifies problems later.
The MSG asks a series of questions that force the team to be explicit about what they are doing and why:
- What is the scope? What data is in, and what is explicitly out?
- What is the policy for each data category - full migration, selective migration, or no migration?
- What is the approach to data that exists in multiple source systems?
- What happens to data that cannot be remediated in time?
For DHGS, working through these questions surfaced a number of decisions that might otherwise have been left implicit until they caused a problem.
Policy Decisions
One of the most important outputs of the MSG process for DHGS was a set of migration policies - explicit statements about how each category of data would be handled.
Some of the key policy decisions included:
Equipment records with no associated site. The source system contained equipment records that had no valid site assignment. These could not load to the target. The policy decision was that records without a valid site would not migrate - but they would be documented, and the business would be given the opportunity to assign them before go-live.
Superseded equipment types. Some equipment type codes in the source had been deprecated and replaced. The policy was that all records using deprecated type codes would be remapped to current equivalents as part of the transformation, using a mapping table maintained by the business.
Historical records beyond a defined age threshold. The business decided that equipment records with no service activity beyond a defined point in the past would not migrate. They would be archived in a read-only legacy system rather than loaded to the target.
Reference data harmonisation. Where source reference values did not map cleanly to target reference lists, the policy was that a master mapping would be produced by the business data owners and applied consistently across the migration.
Each of these was a business decision, not a technical one. Recording them in the MSG meant they were owned, approved, and available to everyone working on the project.
The Policy Overlay
A practical tool in the DHGS strategy phase was the Policy Overlay - a version of the MSG that showed the impact of each policy decision on the data volumes. This gave the business a clear picture of what would and would not migrate under each scenario, and allowed them to adjust policies before the work of remediation began.
The Policy Overlay is useful precisely because it makes consequences visible early. A policy that sounds reasonable in the abstract - for example, “do not migrate inactive records” - can look very different when you see that it excludes 30% of the dataset. At that point, the business can either accept the exclusion or revise the policy. Either way, the decision is explicit.
For DHGS, the Policy Overlay revealed that the initial proposed policies would leave a larger proportion of equipment records behind than the business was comfortable with. This led to a revision of the age threshold for historical records and a more targeted definition of what counted as “inactive.”
Project Decomposition
With strategy set, the team moved to project decomposition - breaking the migration work into a structure that could be planned, resourced, and tracked.
The first step was identifying the Key Business Data Areas for DHGS. These are the major categories of data that the migration needs to handle, each with identifiable ownership and a definable scope. For DHGS, the Key Business Data Areas were:
| Data Area | Description |
|---|---|
| Equipment | Core asset records - the primary migrating entity |
| Sites and Locations | The organisational and physical locations to which equipment was assigned |
| Customers | The internal and external customers associated with equipment and service records |
| Reference Data | Equipment types, status codes, location codes |
| Service History | Historical records of maintenance and service activity |
Each Key Business Data Area became a unit of planning - with its own data owner, its own analysis workstream, and its own place in the Gap Analysis Mapping.
Units of Migration
Within each Key Business Data Area, the team defined Units of Migration - the discrete groups of records that would move together, in a defined sequence. This matters because some data cannot migrate until other data is already in place. Equipment records, for example, depend on Site records already existing in the target.
The DHGS Unit of Migration sequence was:
- Reference data (foundation - everything else depends on it)
- Sites and Locations
- Customers
- Equipment records
- Service History (dependent on Equipment being present in the target)
This sequence became the backbone of the execution plan. Any deviation from it would create dependency failures - referential integrity errors in the target, or transformation rules that could not execute because the lookup values they needed were not yet present.
The Conceptual Entity Diagram
To communicate the relationships between data areas and support the decomposition decisions, the team produced a Conceptual Entity Diagram for DHGS. This is not a full entity-relationship diagram in the database sense - it is a high-level picture of the major entities and the relationships between them, drawn at the level of Key Business Data Areas rather than individual fields.
The diagram showed, for example, that:
- Equipment was related to Sites (an Equipment record must have a Site)
- Equipment was related to Equipment Types (a reference data entity)
- Service History was related to Equipment (a Service History record must have a parent Equipment record)
- Customers were related to both Sites and Equipment (via service contracts)
This diagram served two purposes. First, it validated the Unit of Migration sequence - by looking at the dependencies, the team could confirm that the load order was correct. Second, it gave business stakeholders a picture of the data landscape that they could engage with, without needing to understand the technical detail.
Supplier Assessment
Part of the strategy phase involved assessing the supplier proposals for the technical elements of the migration. The DHGS team applied a structured assessment against the PDM framework - looking at how each proposal handled data quality management, release and version control, and business engagement.
The assessment found that the proposals varied significantly in how they treated data quality risk. Some transferred that risk explicitly to the client; others were vague about it. The assessment gave the project team the basis for a more informed procurement decision, and for negotiating clearer contractual language around responsibilities.
Key Takeaways
- The Migration Strategy Guide forced explicit policy decisions about each category of DHGS data before any technical work began
- The Policy Overlay made the consequences of each policy decision visible in terms of data volumes - and led to policy revisions before work started
- Project decomposition produced Key Business Data Areas and a Unit of Migration sequence that drove the execution plan
- The Conceptual Entity Diagram validated the load order and gave business stakeholders a workable picture of the data landscape
- The supplier assessment applied PDM criteria to supplier proposals, exposing differences in how data quality risk was allocated