Building a Migration Risk Matrix: Step by Step

From a List of Findings to a Set of Priorities

An assessment is the input. It hands you a list: 14 packages with session state, a 2 TB fact table, three circular foreign-key clusters, a few hundred Oracle-specific functions in the application layer. That list is necessary — but a flat list has a quiet failure mode. Everything looks equally important, so teams either treat every item as a five-alarm fire or, more often, work the list top-to-bottom and run out of time before they reach the thing that actually mattered.

A risk matrix fixes that. It takes every finding and places it on two axes — how likely it is to bite, and how much damage it does if it does — so the work sorts itself into "fix first," "keep watching," and "safe to accept." This guide builds one step by step for an Oracle-to-PostgreSQL migration.

Why a Matrix Beats a Checklist

A checklist answers "did we look at X?" A matrix answers "what do we do about X, and in what order?" The difference shows up under deadline pressure, which is exactly when migration decisions get made. With a matrix:

• Prioritisation is explicit. A high-likelihood, high-impact item gets attention before a low-likelihood one — by construction, not by whoever shouts loudest.
• Acceptance is a decision, not an accident. Low/low risks get consciously accepted and signed off, instead of silently forgotten.
• It communicates upward. Leadership reads a colour-coded grid in ten seconds; they don't read a 40-row checklist.

Step 1 — Define the Two Axes

Keep both axes concrete and migration-specific. Vague axes produce vague scores.

Likelihood — how certain is this to actually cause a problem?

• High — present in the schema and known to need a decision (e.g. a package holds session state).
• Medium — present, but the standard pattern usually handles it cleanly.
• Low — edge case, or only triggers under conditions you control.

Impact — if it goes wrong, what's the blast radius?

• High — data correctness, a blown cutover window, or a rollback.
• Medium — schedule slip or rework, but recoverable within the project.
• Low — cosmetic or easily fixed after the fact.

The two axes that matter most for migration are almost always data correctness and cutover-window risk. Anything that threatens either lands in the high-impact column by default.

Step 2 — Populate the Risk Catalog

Most Oracle-to-PostgreSQL projects draw from the same catalog of risks. Start here, then add the findings specific to your assessment. Score each on both axes and pair it with a mitigation:

Step 3 — Score and Find the Heat Zones

Turn the two axes into a number so the matrix sorts itself. The simplest method that survives scrutiny: score each axis 1–3 (Low/Medium/High), multiply, and read the product as a heat zone.

            IMPACT →
            Low (1)     Medium (2)    High (3)
          ┌───────────┬────────────┬────────────┐
 High (3) │   3       │    6 🟠    │   9 🔴     │
          ├───────────┼────────────┼────────────┤
 Med (2)  │   2       │    4 🟡    │   6 🟠     │
          ├───────────┼────────────┼────────────┤
 Low (1)  │   1 🟢    │    2       │   3        │
          └───────────┴────────────┴────────────┘
   ↑ LIKELIHOOD

 🔴 6–9  Mitigate now — owned action, due before cutover
 🟠 4–6  Active mitigation + monitoring
 🟡 3    Watch — re-score at the next milestone
 🟢 1–2  Accept — document the decision and move on

The exact thresholds matter less than applying them consistently. The value is that a 2 TB table with no CDC plan (likelihood Medium × impact High = 6, orange) visibly outranks an unfamiliar-ops risk you've already scheduled training for — and the grid makes that ordering obvious to everyone looking at it.

Step 4 — Assign a Response to Every Red and Orange

A score without an owner is just anxiety. Every cell in the red and orange zones gets one of four responses, an owner, and a date:

• Mitigate — reduce likelihood or impact. CDC turns a high-impact cutover-window risk into a low one. This is the default for most reds.
• Avoid — change the plan so the risk disappears. Refactor a stateful package to stateless parameters and the "package state" risk is gone, not managed.
• Transfer — move the risk to where it's handled better. Let the migration tool's validation own data-correctness proof rather than a hand-written script.
• Accept — for low/low items, consciously decide to live with it and record who signed off.

Step 5 — Keep It a Living Document

A risk matrix built once and filed away is theatre. The score changes as you do the work — and that movement is the project's health signal. Re-score at every milestone:

• After schema conversion — hard-construct risks drop as each is resolved and reviewed.
• After the first full test load — load-order and performance risks get real data behind them.
• After a validation dry-run — data-correctness risk collapses once the proof comes back green.

A matrix that's mostly green by the week before cutover is the most honest go/no-go signal you can hand a steering committee. A matrix still showing reds is telling you something — listen to it.

Where the Tool Pre-Fills the Matrix

DBMigrateAIPro's Migration Advisor builds the first draft of this matrix for you. The assessment populates the catalog — every hard construct, the data profile, the dependency graph — and the Advisor assigns a risk score to each finding, with the items that need human review called out by name. You start from a scored matrix and refine it, instead of facing a blank grid.

It won't make the judgement calls for you — whether to refactor a package or wrap it, whether a performance risk is acceptable — but it does the inventory and the first-pass scoring, which is the tedious 80%.

The Honest Verdict

A migration risk matrix isn't project-management ceremony. It's the difference between a team that knows its three biggest risks and is actively driving them down, and a team that has a long checklist and a vague sense of unease. The first one ships on schedule. The second one discovers its top risk on cutover night.

Build the matrix from your assessment, score it honestly, assign an owner to every red, and re-score as you go. By cutover, the grid should be telling you it's safe — backed by evidence, not optimism.