How Did You Do?
The DHGS scenario contains direct or implied evidence for several policy categories - but not all eight. Six categories are either entirely absent from the text or only partially inferable. That is deliberate. No client briefing document gives you everything. Part of your job as a migration lead is to identify the gaps and go and fill them through structured discovery.
Below is the full policy set for DHGS, including both what the scenario reveals and what it does not.
The Policies
Project Methodology
- The project will be run using a waterfall approach with a formal Project Initiation Document (PID).
- The project board will include senior representation from both IT and the business.
- There is no dedicated communications function within the project team.
From the scenario? No. These policies are not inferable from the text - they have to be discovered by asking how the project will be governed.
Architectural
- DHGS operates on a Microsoft technology stack.
- Systems have grown organically; there is no existing integration layer or middleware.
- There is no appetite for introducing integration software unless there is a proven need.
From the scenario? No. The text tells you there are separate systems with no integration, but the Microsoft stack and the no-middleware preference have to be surfaced through discovery.
Quality v Time v Budget
- Time and budget are the priority. Data quality is treated as the responsibility of the business: if the data is wrong in the source, it will be wrong in the target unless the business acts to fix it.
- This does not mean quality is unimportant - it means quality remediation is a business task, not a migration team task.
From the scenario? No. This is a critical policy that is almost never stated in a briefing document. It must be established explicitly with the project sponsor early in the engagement.
Business Items
The three primary Units of Migration are:
- Customer - the customer master record and associated account data
- Productive Unit - physical assets (plant, vehicles) and their associated maintenance, ownership, and operational records
- Employee - HR and payroll records
From the scenario? Partially. The scenario describes customers, plant, and fleet in detail. The framing as “Units of Migration” and the precise boundary of each unit requires explicit agreement with the business.
Master Data Management
- There is no formal MDM policy at DHGS.
- Customers and Plant records are the two areas identified as key MDM concerns - multiple legacy systems hold overlapping or conflicting data about the same entities.
- The “top 200 customers” - DHGS’s large wholesale accounts - are identified as an early win: high quality, high value, and a natural starting point for migration planning.
From the scenario? Partially. The scenario identifies the customer segmentation (200 large vs 1,000+ small) and the diversity of plant ownership. The absence of a formal MDM policy and the identification of priority customer records requires discovery.
Software
- DHGS has no appetite for introducing migration or integration tooling unless a proven need can be demonstrated.
- No specific tools are mandated or excluded beyond this.
From the scenario? No. Must be established through discussion with the IT lead.
Regulatory
DHGS operates in several regulated areas. The following regulatory obligations affect the data migration scope and approach:
- HMRC - financial records, VAT, payroll, and tax obligations
- DVLA - vehicle licensing and fleet records
- Data Protection - customer and employee personal data
- Health and Safety - plant maintenance records and equipment certification
- Environment Agency - quarrying and extraction activities
- Local Planning Authority - site and extraction permissions
- Audit Standards - financial records must meet audit trail requirements
From the scenario? Partially. The scenario implies several of these (vehicles, finance, HR, plant) but does not state them explicitly. A regulatory mapping exercise is required to confirm the full list and establish what data obligations follow from each.
Local
Local policies are organisation-specific and often the most sensitive. For DHGS:
- Remove small customers. The decision to exit the small wholesale customer market means a substantial portion of the existing customer database will not be migrated. This is a data selection policy with significant implications for scope and volume.
- Activity Based Costing. The Production Director’s decision to adopt ABC during the switchover means some plant maintenance data cannot be migrated as-is - it must be transformed to reflect the new costing methodology.
- Staff downsizing. DHGS anticipates a reduction in headcount as a consequence of the ERP consolidation. This is a sensitive matter and must not be included in any shared project documentation. It is noted here for the migration team’s awareness only - it affects the HR data scope and the engagement approach with HR stakeholders.
- Financial year deadline. The programme is driven by a financial year end date. This is the hard constraint that defines the go-live window.
From the scenario? Partially. The small customer exit and ABC change are stated. The financial year deadline and staff downsizing are not in the public scenario - they are discovered through confidential engagement with senior stakeholders.
The Key Insight: Undisclosed Policies
When you completed the exercise, you likely found evidence for Business Items, Regulatory (partially), and Local (partially). The remaining categories - Project Methodology, Architectural, Quality v Time v Budget, Software, and the full Regulatory picture - require active discovery.
This is not unusual. It is the norm.
The Migration Strategy Guide is not a document you complete in one meeting. It is built up through structured engagement with sponsors, IT leads, business data owners, and subject matter experts. The policy categories give you the questions to ask. The scenario gives you the starting point.
One additional point: the staff downsizing policy illustrates an important principle. Some policies exist and are real, but they cannot appear in a shared artefact accessible to the wider project team. You need a mechanism for tracking sensitive policies separately and ensuring they inform your approach without being exposed in general documentation.
Key Takeaways
- Only two of the eight policy categories (Business Items and Local - partially) are clearly visible in the initial scenario
- Six categories require active discovery through structured engagement with stakeholders
- The Quality v Time v Budget policy is critical and is almost never stated unprompted - always establish it explicitly
- Sensitive policies (here: staff downsizing) are real and must inform your approach, but require separate handling
- The policy identification exercise is not a one-time task - the MSG is a living document, updated as discovery progresses