Learning Objectives
By the end of this lesson you will be able to:
- Complete an LDS list entry for a given legacy data store
- Identify the fields that require business input vs. those that can be completed technically
- Extend the LDS template for project-specific needs
The LDS Template in Practice
The LDS template is designed to be completed iteratively - not all fields can be filled from the start, and some require engagement with the Data Owner or Business Domain Experts.
A typical completion sequence:
Pass 1 (IT, immediately): Name, access, format, scale, rough topography. These come from the IT inventory and initial technical exploration.
Pass 2 (IT + business): Function, entities, data origin, initial quality assessment. These require at least one conversation with someone who works with the system.
Pass 3 (with Data Owner): KDSH confirmation, System Retirement Plan reference, quality detail. These require a formal engagement with the Data Owner.
Fields That Require Business Input
Several fields cannot be completed without business involvement:
Data Origin - whether a field is mastered here (this system is the authoritative source), derived (calculated from other data), or copied (pulled from another system). IT can guess at this; only the business knows for certain. Getting it wrong has serious consequences for the mapping.
Quality Assessment - a technical data profiling tool can tell you what percentage of records have a null in a mandatory field. It cannot tell you whether that null represents a genuine absence of data or a legacy system workaround. The business context is essential.
KDSH Identification - technically, the system administrator is the system owner. But the Data Owner in PDM terms is the person who has the authority to sign the decommissioning certificate. This is often a business manager, not a technical one, and the right person may not be obvious.
Extending the LDS Template
The standard PDM LDS template covers the minimum required fields. Most projects extend it with project-specific columns:
- Process usage - which business processes depend on this LDS
- Consolidation - whether this LDS will be merged with others in the target
- Detailed migration tracking - current migration status per LDS
- Departmental links - which business departments use this LDS
- Programme links - dependencies on other programme workstreams
- Reports fed - which reports (especially mandatory/statutory) this LDS supplies
- External interfaces - feeds to or from systems outside the migration scope that must keep working
Extending the template is encouraged - the LDS list is one of the most-used artefacts across the project lifetime.
The DHGS LDS List
In the DHGS case study, the initial LDS list from the MSG includes the main systems: the Finance system (FSDB), the CRM system, the HR system, and Commercial Vehicles. Landscape Analysis subsequently discovers additional stores:
- Kelsey Pit - the equipment and maintenance database for the Kelsey pit site
- Pebbles - a product pricing system run by a specific business unit
- Several departmental spreadsheets tracking equipment maintenance histories
Each of these smaller stores would not have appeared in the corporate IT inventory. Each turns out to contain data that is material to the migration.
The list also records more than systems - the statutory extraction-volume return DHGS files with its regulator, and the external interfaces (the online-retail payment gateway, fleet telematics) that survive the migration:
The DHGS LDS list (worked example)
| LDS name | Type | Function | KDSH (Data Owner) | Origin | Quality | Decommission? |
|---|---|---|---|---|---|---|
| FSDB | Database | Finance / billing | Finance Mgr | Mastered | Fair | Yes |
| Kelsey Pit | Spreadsheet | Extraction equipment register | Whit Bissell | Mastered | Poor | Yes |
| Pebbles | System | Product pricing (one BU) | Commercial Mgr | Mastered | Fair | Yes |
| Extraction Volumes Return | Report (statutory) | Regulator return on gravel extracted | Compliance Lead | Derived (FSDB + Kelsey Pit) | Must reconcile | No - must be reproducible on target |
| Online Retail Payment Gateway | External interface | Card payments for the online arm | IT / Payments | Copied | n/a | No - interface preserved, not migrated |
Format note: this inline foldout is the go-forward standard for course artefacts - the worked register is shown in the lesson, expandable, rather than attached as a handout. The blank LDS template stays available as an optional download because it is a genuine fill-in worksheet. See
pdm-website/DESIGN.md§8 andpdm-course/ARTEFACTS_INVENTORY.md.
Common Pitfalls
Declaring too quickly: Completing the template in one pass based on IT knowledge only, without business input. Results in incorrect data origin assessments and missed KDSH.
Treating the template as a one-time exercise: The LDS list needs to be reviewed at each project gate. New LDS continue to be discovered through GAM and DQR.
Missing the local stores: Spreadsheets, Access databases, and departmental systems are systematically undercounted. They are often the most data-quality-challenged stores and the hardest to migrate.
Key Takeaways
- The LDS template is completed iteratively across at least three passes
- Several fields require business input and cannot be completed from IT knowledge alone
- The template should be extended with project-specific columns to maximise its utility across the project
- Local and departmental stores are frequently missed - active outreach to business units is needed to find them
Book Reference
Practical Data Migration by Johny Morris (BCS, The Chartered Institute for IT):
- Chapter 10 - Landscape Analysis