Migration Risk Register
A maintained record of what could go wrong in a migration, with likelihood, impact, owner and mitigation, reviewed as the programme progresses.
Migration risk is concentrated in a small number of areas that recur across programmes, which makes a starting register straightforward to write and negligent to omit.
The recurring entries:
Undiscovered dependencies — something integrates with the system in a way nobody documented. Mitigate by discovering from evidence: network flow logs, database audit logs, and a period of monitoring before cutover.
Data quality problems surfacing during migration, where the old system tolerated what the new one validates. Mitigate by profiling the data early — this is the risk most likely to move the date.
Behavioural differences nobody knew were relied upon. Mitigate with shadow running for high-risk paths.
Performance under real load and real data distribution, which a test environment misrepresents.
Knowledge loss — the person who understands the legacy system leaving mid-programme. This is a real scheduling risk and is rarely on the register.
Business change during a long programme, which is why long migrations should deliver in increments.
Rollback becoming impossible after a one-way step, which must be identified in advance rather than discovered.
What makes the register useful rather than ceremonial: an owner and a mitigation with a date for each entry, and review at every stage gate — with risks that materialise recorded, so the next programme starts from evidence.