Learning Objectives
By the end of this lesson you will be able to:
- Explain what a Business Transformation Realisation document captures and why
- Describe the multi-pass interview process for completing a BTR
- List the minimum content areas that every BTR should cover
What Is a Business Transformation Realisation?
A Business Transformation Realisation (BTR) - also called a System Retirement Plan in some versions of the methodology - is a document created through one-to-one interviews with each Data Owner that captures:
- Their requirements for the migration of their data
- Their fears and concerns about the change
- The conditions under which they will sign the decommissioning certificate
The BTR serves a dual purpose: it is a business engagement tool (bringing the Data Owner through the change curve) and a migration design input (their requirements shape the ETL, the testing, and the go-live approach).
The Change Curve and BTR
Data owners typically react to the prospect of a migration through the same emotional stages as any significant change:
- Denial: “We won’t really need to migrate all of that”
- Anger: “Why are you touching our systems?”
- Bargaining: “Can we keep the old system running for another year?”
- Acceptance: “What do we need to do to make this work?”
The BTR interview is designed to accelerate this journey. By giving the Data Owner space to express every concern - and then documenting those concerns as requirements - it moves them from resistance to negotiation.
The technique: “We need to understand all the reasons this migration shouldn’t happen, so we can address each one.”
The Multi-Pass Process
A BTR is completed across at least three interview sessions with each Data Owner:
Pass 1 - Initial engagement The first interview establishes the relationship and begins the journey up the change curve. Ask open questions: what does this system do for you? What are you worried about? The output is a first draft of the requirements and a list of outstanding concerns.
Pass 2 - Validation and extension Review the first draft with the Data Owner. What is missing? What has changed? This pass often reveals additional requirements as the Data Owner has had time to think. It also typically reveals additional BDEs who should be involved.
Pass 3 - Sign-off The final pass produces a signed BTR. The Data Owner confirms that their requirements are correctly captured and that the document represents the conditions for migration acceptance.
The number of passes depends on the complexity of the LDS and the engagement of the Data Owner. Some BTRs require more than three passes; few require fewer.
Content Areas
Every BTR should cover, at minimum:
| Area | Description |
|---|---|
| Training | What training is required before go-live? Include the “training lag” - the time between training and go-live during which skills are lost |
| Testing | What test data is needed, and what sign-off process is required for test results? |
| Data Retention | What data must be retained from the legacy system and for how long? |
| Audit & Data Lineage | What audit trail is required? Can migrated data be traced back to its source? |
| Go-Live Restrictions | Are there windows of opportunity or blackout periods? (Year-end, fiscal close, etc.) |
| Customer/User Experience | How will customers or end users be affected at go-live? |
| Fallback | If migration fails, what is the fallback plan? What are the conditions for invoking it? |
| Resources | What people and physical resources are needed from the business for the migration? |
| Transitional Business Processes | How are in-flight transactions handled during the cutover window? |
| Decommissioning Certificate | What conditions must be met before the Data Owner signs? |
The DHGS Example
In the DHGS case study, the Data Owner for the Kelsey Pit equipment system is Whit Bissell, a production manager who feels his autonomy is threatened by the IT project. The initial BTR interview lasts ten minutes before he cuts it short.
The approach: rather than pushing through a requirements list, the team asks what would prevent him from signing the decommissioning certificate. His answers - concerns about web portal uptime, maintenance data completeness, equipment categorisation - become the requirements in the BTR.
When Whit realises that his concerns are being documented as requirements (not dismissed), and that he will not be asked to sign until every concern is addressed, his posture shifts. The BTR process converts a hostile stakeholder into an engaged one.
Key Takeaways
- The BTR captures Data Owner requirements and moves them through the change curve - both functions are essential
- The multi-pass interview process ensures completeness and builds the relationship
- The minimum content areas are: training, testing, data retention, audit, go-live restrictions, customer experience, fallback, resources, transitional processes, decommissioning certificate
- BTR outputs feed into ETL design (exclusion rules, timing constraints), testing (acceptance criteria), and legacy decommissioning (sign-off conditions, archiving requirements)
Book Reference
Practical Data Migration by Johny Morris (BCS, The Chartered Institute for IT):
- Chapter 09 - Business Transformation Realisation