Learning Objectives
By the end of this lesson you will be able to:
- Explain what strategy matrices are used for in PDM
- Identify the key dimensions along which a migration strategy is assessed
- Describe how policies interact to produce a migration strategy
What Are Strategy Matrices?
Strategy matrices are analytical tools used within the MSG process to assess the strategic options for a migration and document the decisions made.
They help the project team and its stakeholders make explicit choices about the dimensions of the migration, choices that, if left implicit, become sources of misunderstanding and scope dispute later in the project.
The Key Dimensions
Migration Form
As introduced in the previous lesson, the migration form defines how the data will be moved:
| Form | Description | When to use |
|---|---|---|
| Big Bang | All data migrated in a single cutover event | Clean, time-bounded, high disruption tolerance |
| Phased | Series of migrations by business area or geography | Complex programmes, risk mitigation, staged value delivery |
| Parallel | Legacy and target systems run simultaneously | Low risk tolerance, high validation requirement |
The chosen form affects ETL design, testing strategy, fallback planning, and resource requirements throughout the project.
Quality vs Time vs Budget
Every project lives in a triangle of quality, time, and budget. On a data migration, the quality dimension has a specific meaning: it is about the appropriate quality for business purpose, not absolute quality.
The strategy matrix makes this tension explicit: the project’s risk appetite determines whether late-running DQR items are migrated at lower quality, held back, or used to defer go-live.
Delivery Methodology
Waterfall, Agile, or Blended? The choice is documented in the strategy and has implications for how releases are planned, how testing is organised, and how the DQR board interacts with delivery cycles.
Policy Interactions
Policies rarely exist in isolation. A regulatory policy (data must remain in country) interacts with an architectural policy (cloud-first infrastructure) to constrain the migration form. A local policy (90% onshore delivery) interacts with a budget policy to constrain supplier selection.
The strategy matrix process surfaces these interactions before they become late-stage surprises. In the DHGS case study, for example, the policy of concentrating on the largest 200 customers interacts with the migration form decision to suggest that customer data is migrated early in a phased approach.
Undisclosed Policies
A recurring challenge in strategy work is the policy that exists but is never written down, the informal understanding that “we always use Vendor X” or “the CFO has to sign off any system retirement”. Undisclosed policies are one of the most common sources of late-stage scope conflict.
The MSG process should explicitly ask: what policies are operating in this organisation that are not in any formal document?
Documenting the Strategy
Strategy matrices are living documents. The initial version is produced during the MSG phase with the information available. It is revisited at key governance checkpoints, after landscape analysis reveals new LDS, after DQR metrics become available, after testing reveals systemic issues.
The strategy is not set once and frozen. It is a governance tool that evolves with the project.
Key Takeaways
- Strategy matrices make explicit the key choices about migration form, quality tolerance, methodology, and policy interactions
- Undisclosed policies are a significant risk source and must be actively surfaced
- The strategy is not static - it is a governance document that evolves as the project uncovers new information
Book Reference
Practical Data Migration by Johny Morris (BCS, The Chartered Institute for IT): Chapter 4, “Migration Strategy and Governance”.