Introduction to the Migration Strategy Guide (MSG)

Learning Objectives

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

• Explain what the Migration Strategy Guide is and what it contains
• Describe the governance structures PDM expects on a data migration project
• Identify the PDM-specific governance functions that go beyond standard programme office functions

📦 The DHGS Story - Episode 1: Choosing how to migrate. DHGS has to move ten disconnected legacy systems onto its new Activity-Based Costing platform - but first it must decide how. Two systems integrators bid for the work: Logia and HAL. Using the strategy matrices in this module, the team weighs quality against time and cost and recommends HAL, conditionally. The Migration Strategy Guide they write, and the Key Business Data Areas they carve the project into, become the contract for everything that follows.

Watch for the Kelsey Pit equipment data - it looks like a minor system now, but it’s where the analysis in the next module first hits trouble.

What Is the MSG?

The Migration Strategy Guide (MSG) is the module name in PDM. The document it produces is the Migration Strategy. Governance in PDM is the use of the artefacts, specifically DQR, Release and Version Management, the System Retirement Plan, and the DMZ, to manage the migration process.

The MSG establishes the framework within which every other PDM activity operates. Before the team begins landscape analysis, before the first DQR meeting, before any ETL work starts, the project needs a strategy, and the Migration Strategy is where that strategy lives.

Change control vs. change management: Change control is part of the encompassing programme’s remit. It is for the most significant changes. PDM has its own change management to govern the constant wave of minor changes that are part of business as usual on a migration workstream.

PDM Tailors to Your Governance

PDM does not arrive and impose a brand new way of running the project. Most organisations already have a particular way of initiating, governing, and managing major projects, and PDM expects to be tailored to those local policies and procedures.

So the strategy work is really an assessment. PDM has a set of functions it needs in place; your job is to check whether your organisation’s existing structures are adequate substitutes for them, then mitigate the gaps and the overlaps. The goal is to integrate the rigour of PDM with the local requirements into a single, seamless whole.

Substitution and Risk

The rule for that assessment is straightforward:

• For each PDM module, ask: does the customer already do this, to an adequate standard, in their own way?
• If yes, you may substitute their approach for the PDM module - but you must risk-assess the substitution against what the PDM module would have given you, and record the gaps and overlaps in the MSG.
• Two things can never be substituted: the Data Quality Rules process and the single virtual team. They are the non-negotiable core of PDM. Everything else is open to tailoring; these are not.

Standard Programme Office Functions

PDM assumes that a data migration runs within a broader programme, and that standard programme office functions are in place. These include:

• Scope management - tracking scope changes, particularly as new legacy data stores are discovered
• Project board - formal escalation and decision-making structure
• Communications - formal stakeholder communications, distinct from the embedded business engagement built into Super Smart Tasks
• Planning - extended to cover DQR work and data readiness milestones
• Risk and issue management - but with an important exception: data quality issues should be tracked in the DQR process, not the risk register
• Budgeting - covering the PDM-specific activities that are often underestimated
• Library and configuration management - version control for all PDM artefacts

If these functions are not already in place in the broader programme, the MSG must establish them.

PDM-Specific Governance Functions

Beyond standard programme management, the MSG defines governance structures unique to data migration.

Policies

Policies are the project-specific frameworks within which all decisions are made. They include:

Undisclosed policies, those that exist in the organisation but are not formally documented, are a major source of project risk. The MSG process should actively surface them.

Control Flows

PDM-specific control flows that the MSG establishes:

• DQR System - the process and repository for data quality remediation
• System Retirement Plans - the programme of legacy decommissioning
• Migration Design & Execution Dashboard - progress reporting for migration runs
• Legacy Decommissioning Report - formal record of decommissioned systems

Migration Form

The MSG defines the migration form, how the migration will be executed:

• Big Bang - one-off migration of all data in a single event, or a series of big bangs
• Parallel - new and legacy systems run simultaneously until acceptance is confirmed
• Phased - series of migrations by business area, geography, or function

Each form has different implications for fallback planning, testing, and business disruption.

Software and Supplier Selection

The MSG is also where software and supplier selection decisions are documented.

Software selection is driven by the scale of the migration, the budget, the migration strategy and form, local software policies (“we only buy Oracle”), the availability of trained resource, and what is available in the market.

Supplier selection is driven by alignment with the chosen software and migration strategy, price, and PDM status. If the supplier has a methodology and it is not PDM, can PDM be embedded within it?

The Initial LDS List

The MSG contains the initial list of legacy data stores (LDS), the systems, databases, files, and other data repositories that are in scope for migration.

This list will always be incomplete. It is based on the corporate IT inventory, which typically captures the main systems but misses the small, local, and personal stores that often contain critical data. The Landscape Analysis process exists in part to find everything the MSG list missed.

The initial LDS list is significant not because it is comprehensive, but because it establishes a baseline: anything not on the list is potentially out of scope, and bringing it in later carries a cost.

Key Takeaways

• The MSG establishes the governance framework within which all PDM activities operate
• PDM tailors itself to your local governance - it assesses what exists and fills the gaps rather than bolting on a second rulebook
• PDM modules can be substituted with the customer’s own equivalents after a recorded risk assessment - except the DQR process and the single virtual team, which are non-negotiable
• Policies, including undisclosed ones, are a major source of project risk and must be surfaced at the strategy stage
• The initial LDS list establishes scope; it will grow as landscape analysis proceeds

Book Reference

Practical Data Migration by Johny Morris (BCS, The Chartered Institute for IT): Chapter 4, “Migration Strategy and Governance”.