Learning Objectives
By the end of this lesson you will be able to:
- Explain the relationship between decommissioning design and fallback design
- Describe the types of fallback available on a data migration
- Identify the conditions that trigger fallback and how they are defined
Why Design Fallback?
Every migration run carries risk. Even with extensive trial runs and validated data, the final go-live migration can encounter problems: a volume that exceeds test conditions, a business process that behaves differently with live data, a target system configuration that only reveals itself under production load.
Fallback is the plan for what happens when things go wrong at go-live. It must be designed before the migration run, not improvised during it.
Types of Fallback
Full Fallback (Roll Back) Return all systems to their pre-migration state. Legacy systems continue operating; the target system is rolled back to its pre-load state.
Full fallback is only possible if:
- The legacy systems have been kept running (or can be restarted from a snapshot)
- No One Way Street transformations have destroyed the ability to reconstruct the original data
- The rollback can be completed within the available window
On a phased migration, full fallback for a single KBDA may be possible even when full system rollback is not.
Partial Fallback (Fall Forward) Accept that some data cannot be rolled back, and proceed with manual corrections or a subsequent migration run. “Fall forward” means accepting the migrated state but fixing identified issues on the target rather than restoring from the legacy.
Appropriate when:
- Full rollback is not technically possible (One Way Street transformations)
- The volume of issues is small and correctable in the target
- The business case for proceeding outweighs the risk of the issues
No Fallback For some migrations - particularly those involving legacy systems that are no longer maintainable - there is no viable fallback. The migration must succeed, or the business is in an extremely difficult position.
PDM recommends that no-fallback situations be identified explicitly in the design phase, and that additional testing and contingency measures be applied to compensate.
Designing the Fallback Trigger
Fallback should have explicit trigger conditions - the criteria that, if met during or after go-live, activate the fallback plan. These are agreed with the Data Owner and captured in the BTR.
Example trigger conditions:
- More than X% of a KBDA’s records fail target validation
- A critical business process cannot operate with the migrated data
- A show-stopping defect is discovered in the target system that cannot be patched within the migration window
- The migration run does not complete within the planned window
The trigger conditions are not invoked automatically - they trigger a go/no-go decision meeting with the Data Owner, Migration Analyst, and programme governance.
The Relationship with System Retirement Plans
The fallback design is directly linked to the System Retirement Plans (BTR documents). Each BTR captures the Data Owner’s requirements for fallback:
- What conditions would they invoke fallback?
- What is the maximum acceptable period of target system unavailability?
- What transitional processes are in place if fallback is invoked?
Fallback design that does not account for the Data Owner’s actual requirements is a paper exercise. The BTR process ensures the design is grounded in business reality.
Archive vs. Active Legacy
A design decision related to fallback: should the legacy system be kept active (capable of being returned to production) or archived (read-only, for data lineage and audit only)?
Active legacy enables full fallback but incurs ongoing maintenance costs. It must be agreed in the BTR and has a defined end date (when the legacy is decommissioned after a successful period of target operation).
Archive legacy is cheaper but means fallback beyond the archive period is not possible. The archive must be structured so that audit and data lineage queries can be run against it for the required retention period.
Key Takeaways
- Fallback must be designed before go-live, not improvised during it
- Three fallback types: full roll-back, partial fall-forward, or no fallback
- Trigger conditions must be defined and agreed with Data Owners in the BTR
- One Way Street transformations constrain fallback options - this is a key reason to identify them during GAM
- The legacy system’s post-migration status (active vs. archive) is a design decision with commercial and technical implications
Book Reference
Practical Data Migration by Johny Morris (BCS, The Chartered Institute for IT):
- Chapter 12 - Migration Design and Execution
- Chapter 14 - Legacy Decommissioning