Migration Design Overview

Learning Objectives

By the end of this lesson you will be able to:

• Describe the Migration Design & Execution (MDE) module and its place in the PDM framework
• Explain the design artefacts produced in MDE and how they relate to earlier PDM outputs
• Identify the key design decisions that determine how the migration will run

Migration Design & Execution

Migration Design & Execution (MDE) is the PDM module that takes all the analytical and governance outputs from earlier phases and translates them into a technical design for the migration runs.

MDE is where the work of LA, GAM, DQR, KDSM, BTR, and Release Management converges into an executable plan.

Design Inputs

MDE takes the following as inputs:

Each input constrains or informs the design. The migration cannot run until the data is ready (DQR metrics); it cannot run outside the agreed window (BTR go-live constraints); it must match the agreed form (MSG policy on big bang vs. phased).

Design Outputs

MDE produces:

Migration Run Plan The detailed sequence of events for each migration run, including:

• Extract window for each LDS
• Transformation and validation steps
• Load sequence for each entity
• Validation checkpoints and accept/reject criteria
• Fallback decision points and trigger conditions
• Communications plan (who is notified, when)

Cutover Plan For the final migration run: the minute-by-minute plan for the cutover window. This covers:

• Legacy system freeze (no new data after X time)
• Extract run and expected duration
• Transformation and staging validation
• Load run and expected duration
• Post-load validation
• Go/no-go decision meeting
• Target system handover
• Legacy system archive

Trial Run Schedule A programme of migration runs before the final production run, each designed to:

• Test an increasing volume of real data
• Validate DQR resolutions in a real data context
• Build the team’s confidence and refine the Cutover Plan
• Accumulate acceptance evidence for Data Owners

Migration Run Sizing

A key design question is how many trial runs are needed and what volume each should process.

A common pattern:

1. Development run: Small extract (10-20% of records), first test of end-to-end process
2. Trial run 1: Larger extract (50%), used for DQR review and mapping refinement
3. Trial run 2: Full extract, used for Data Owner review and timing confirmation
4. Dress rehearsal: Full extract under production conditions, including all cutover procedures
5. Production run: The live migration

Each run produces a migration readiness report that feeds the go/no-go decision for the next run.

The Go/No-Go Decision

The go/no-go decision at each migration run gate requires:

• DQR metrics: are all Priority 1 items resolved? Is the record completion percentage above the agreed threshold?
• Timing: did the previous run complete within the planned window?
• Data Owner acceptance: have the relevant Data Owners reviewed the output and confirmed acceptance?
• Technical validation: do record counts match expected volumes? Do checksum validations pass?

The go/no-go decision is a governance decision, not a technical one. The Migration Analyst presents the evidence; the Data Owners and programme governance make the call.

Key Takeaways

• MDE is the convergence point for all PDM analytical and governance outputs into an executable migration design
• Design outputs include the Migration Run Plan, Cutover Plan, and Trial Run Schedule
• Trial runs accumulate evidence for go/no-go decisions and refine the final production run
• The go/no-go decision is governance-led, not technically driven

Book Reference

Practical Data Migration by Johny Morris (BCS, The Chartered Institute for IT):

• Chapter 12 - Migration Design and Execution