Learning Objectives
By the end of this lesson you will be able to:
- Describe the sequence of activities in the final migration run and cutover
- Explain the go/no-go decision process at each cutover checkpoint
- Identify the communications required during and after go-live
The Cutover Window
The cutover window is the period between the last write to the legacy system and the first write to the target system in production. During this window:
- Legacy systems are frozen (no new data can be entered)
- The final migration run executes
- Validation occurs
- The go/no-go decision is made
- If go: the target system opens for business
- If no-go: fallback is invoked
The cutover window must be as short as operationally possible. Businesses cannot operate without their systems. The window is defined in the BTR (go-live restrictions section) and tested in the dress rehearsal.
Cutover Sequence
A typical cutover proceeds as follows:
T-7 days: Final preparation
- Confirm all DQR items that must be resolved before go-live are closed
- Complete final mapping freeze (no more mapping changes)
- Complete release candidate build and testing
- Brief all stakeholders on cutover sequence
T-1 day: Pre-cutover checks
- Validate that legacy systems are accessible and in expected state
- Confirm extract window timing with legacy system owners
- Confirm target system is ready to receive data
- Confirm fallback readiness (legacy systems can be restored if needed)
- Confirm all on-call personnel are available
Cutover day: The run
- Legacy system freeze - no new entries from T=0
- Final incremental extract (any changes since the last trial run)
- Transformation and staging validation
- Checkpoint 1: Record counts, DQR metric review → Go/No-Go
- Load to target
- Post-load target validation
- Checkpoint 2: Target validation, sample BDE review → Go/No-Go
- Data Owner sign-off
- Target system open for business
- Legacy system archived (or placed in read-only mode)
Post-go-live (first week)
- Monitoring for data issues surfaced by actual business use
- Support for business users encountering data problems
- Final DQR items raised for any post-migration data corrections
Go/No-Go Decision Points
Each checkpoint in the cutover has a go/no-go decision. The decision criteria are defined in the Cutover Plan (agreed in advance with Data Owners). The decision is made by the Migration Analyst with Data Owner concurrence.
Go criteria (typical):
- Record counts within agreed tolerance of expected
- No Priority 1 technical errors in the load log
- Sample review: BDE confirms X of Y randomly selected records are correct
- Load completed within the planned timing window
No-go criteria (trigger fallback):
- Record count deviation exceeds agreed tolerance
- Critical business data (e.g. all customer records) fails validation
- Load timing overrun means the target cannot open within the business window
- A show-stopping data defect is identified in sample review
Communications
Go-live is a high-anxiety moment for business stakeholders. Communications must be planned and executed precisely:
During cutover: Regular status updates to key stakeholders (hourly or at each checkpoint). No silence - if the run is proceeding normally, say so explicitly.
On go-live confirmation: Formal notification to all Data Owners, business users, and programme governance. Include a brief summary of migration statistics.
Post-go-live: A hypercare period of 5–10 business days with dedicated support. Issues found during hypercare are logged as DQR items for post-migration correction.
Hypercare Period
The hypercare period immediately after go-live is when business users first work with the migrated data in anger. Issues that did not surface in trial runs (because trial run reviewers were looking at samples, not running full business processes) emerge now.
PDM treats hypercare as a defined project phase, not an informal handover. It has:
- A defined duration (agreed with Data Owners in the BTR)
- A defined support team (migration analyst + BDEs)
- A defined escalation path (DQR Board remains active)
- A defined closure criterion (hypercare ends when issue rate falls below a threshold)
Key Takeaways
- The cutover window must be as short as possible and is defined in the BTR
- Each cutover checkpoint has pre-defined go/no-go criteria - decided in advance, not assessed under pressure
- Communications during and after go-live must be planned and precise - silence breeds panic
- Hypercare is a defined phase, not an informal handover - it has a duration, a support team, and a closure criterion
Book Reference
Practical Data Migration by Johny Morris (BCS, The Chartered Institute for IT):
- Chapter 12 - Migration Design and Execution