Learning Objectives
By the end of this lesson you will be able to:
- Explain what a System Retirement Plan contains and how it is used
- Describe how System Retirement Plans interact with migration design and legacy decommissioning
- Identify the key Data Stakeholders who must contribute to a System Retirement Plan
What Is a System Retirement Plan?
A System Retirement Plan (SRP) - also described in some modules as the Business Transformation Realisation (BTR) - is a document that captures, for a specific legacy data store, the conditions under which it can be retired.
The SRP is produced through one-to-one interviews with the Data Owner for each LDS and is maintained throughout the project. It is not completed in one session - it is built up across multiple passes as the project learns more about the data and the business requirements.
Content of an SRP
The SRP documents the Data Owner’s requirements across all dimensions of the migration:
Data Requirements
- What data must be migrated (and what can be excluded)
- Quality thresholds for each Unit of Migration
- Data retention requirements (what must be kept in the legacy archive)
Operational Requirements
- Training: what training is needed, and when? (Including the training lag)
- Testing: what test scenarios must pass before go-live?
- Go-live window: when can go-live occur? (Year-end constraints, operational blackouts)
- Transitional Business Processes: how are in-flight transactions handled during cutover?
Technical Requirements
- Fallback conditions: what problems would trigger a return to the legacy system?
- Archive requirements: what data must be accessible after decommissioning, and for how long?
- Data lineage: can migrated data be traced back to its source?
Commercial Requirements
- Customer experience: what must customers be told, and when?
- Regulatory compliance: any compliance requirements that affect migration timing or data handling?
Decommissioning Certificate The conditions under which the Data Owner will sign the certificate confirming the legacy system can be retired. This is the ultimate acceptance criterion for the LDS.
Multiple Data Owners per LDS
Large legacy data stores often serve multiple business functions with multiple Data Owners. In the DHGS case, the Kelsey Pit system serves both Production & Maintenance (Whit Bissell) and Sales (Dave Reed). Each Data Owner has different priorities and different decommissioning conditions.
The SRP for Kelsey Pit must address both Data Owners’ requirements, and both must sign the decommissioning certificate before the system can be retired.
When Data Owners have conflicting requirements - one wants the legacy system kept active longer than another - the conflict must be escalated to programme governance for resolution.
SRPs in Migration Design
System Retirement Plans feed directly into migration design:
- Go-live window constraints define the migration run timing
- Data retention requirements define what must be archived vs. deleted
- Testing requirements define the acceptance criteria for trial runs
- Transitional Business Process requirements define what must be in place at cutover
An SRP that is not consulted during migration design is a compliance risk. If the Data Owner’s requirement for 30-day archive access is not reflected in the archive design, the project has not met its acceptance criteria - even if the data migrated correctly.
The SRP as a Change Control Tool
SRPs are under change control. As the project evolves - new LDS are discovered, DQR items change the scope of what can be migrated, go-live dates shift - the SRP must be updated and re-signed by the Data Owner.
An outdated SRP is a risk: it may reflect commitments that are no longer achievable, or may miss requirements that have emerged since the last review.
Key Takeaways
- The SRP captures the Data Owner’s conditions for retiring a legacy system: data requirements, operational requirements, technical requirements, and the decommissioning certificate
- Large LDS may have multiple Data Owners with different requirements - all must be satisfied
- SRP requirements feed directly into migration design: go-live timing, archive design, acceptance criteria
- SRPs are under change control and must be kept current throughout the project
Book Reference
Practical Data Migration by Johny Morris (BCS, The Chartered Institute for IT):
- Chapter 09 - Business Transformation Realisation
- Chapter 14 - Legacy Decommissioning