The Risk Register: Naming Every Way It Can Fail
Estimated read: 3 min
A risk register is the practice of writing down, before it happens, every way the migration could fail – so that when something goes wrong, the team is executing a pre-agreed mitigation instead of discovering the problem and the response to it at the same time. It’s the same discipline a DBA already applies to a major cutover weekend: naming the failure modes in advance is what turns a 2 a.m. surprise into a checklist item.
A risk register entry is not “reconciliation might fail” – that’s too vague to act on. Each entry needs five fields:
| Field | Purpose |
|---|---|
| Risk | The specific failure, tied to a node in the dependency graph (e.g. “PL/SQL transpilation for the billing domain exceeds estimated effort by more than 50%”) |
| Probability | Low / medium / high, based on evidence – prior domains’ actual conversion time, not a guess |
| Impact | What it delays or breaks downstream if it happens, traced through the dependency graph |
| Owner | The named person who monitors this risk and triggers the mitigation – not a team, a person |
| Mitigation / trigger | The specific action taken, and the specific signal that triggers it (e.g. “if transpilation is >50% over estimate by day 10, pull in a second engineer from the customer-domain team”) |
The risks worth naming for a legacy-to-Databricks migration fall into recurring categories: schema drift after freeze (the source team ships a change anyway), transpilation errors that pass code review but produce subtly wrong results under specific data conditions, performance regressions where a converted query technically returns correct results but takes ten times longer at production scale, reconciliation mismatches that never resolve to zero variance because of a semantic difference nobody caught (e.g. Oracle’s NULL-handling in an aggregate versus Spark’s), business-user rejection at the trust-gate sign-off, cutover-window overruns, and rollback failure – discovering during an actual incident that the rollback path was never actually tested end to end.
A risk register with entries but no named owner for each one isn’t a risk register – it’s a list of things to worry about. The single most valuable field in the table is owner, because it’s what turns “someone should probably watch for this” into an actual person checking a specific signal on a specific cadence.
The risk register isn’t a one-time document written at kickoff and filed away – it’s a living artifact reviewed at every steering committee checkpoint, which is exactly the audience and cadence the next lecture covers.
| ← Previous: Sequencing: What Order, What Parallel, What Blocks What | Next: Stakeholder Communication and the Steering Committee → | |:—|—:|