Define the evidence needed before making a legacy decision
A legacy system migration risk assessment is the process of identifying, categorising and evaluating what could go wrong when you move data, processes or functionality from an existing system to a new one. It is not a general project risk exercise. It focuses specifically on the gaps between what the old system actually does and what the new system is being asked to replicate or replace.
The core purpose is to surface hidden dependencies before they become live problems. Legacy systems often contain behaviour that was never documented: workarounds added by former staff, database fields repurposed over time, batch processes that rely on specific timing, or manual steps that happen outside the software but are essential to the workflow. A risk assessment forces these into view.
Risk in this context falls into a few distinct categories. Data risk covers the possibility that records are corrupted, duplicated, truncated or misaligned during transfer. Process risk covers the chance that a business workflow breaks because the new system handles a step differently or not at all. Integration risk covers the connections between the legacy system and other software, which may be undocumented or behave unexpectedly when the source changes. Operational risk covers the transition period itself: what happens to the business if the cutover takes longer than planned or has to be reversed.
The output of a proper assessment is not a list of fears. It should be a structured register that ties each risk to a specific part of the system, rates its likelihood and impact, and identifies what would need to change to reduce it. That register then feeds directly into decisions about migration approach, testing scope and rollback planning.
| Assessment area | What to establish | Evidence to retain |
|---|---|---|
| When Risk Assessment Becomes Critical | Not every system replacement demands a formal risk assessment. | A named owner, current-state evidence, unresolved questions and a dated decision record. |
| What to Examine | Define the expected outcome, the responsible owner and the evidence needed to verify it. | A named owner, current-state evidence, unresolved questions and a dated decision record. |
| Structuring the Assessment | A practical approach is to work through the system by process rather than by technical component. | A named owner, current-state evidence, unresolved questions and a dated decision record. |
| Common Mistakes | Assuming documentation reflects reality. | A named owner, current-state evidence, unresolved questions and a dated decision record. |
When Risk Assessment Becomes Critical
Not every system replacement demands a formal risk assessment. If you are moving a simple internal tool with a few dozen records and no integrations, the risks are relatively contained. The assessment becomes essential when the legacy system handles regulated data, supports revenue-generating processes, connects to multiple other systems, or has been modified over many years without clear documentation. The longer the system has been in production and the more people have touched it, the higher the chance that critical behaviour is invisible to the current team.
Carrying out a meaningful risk assessment requires access to the right people and the right information. Technical staff alone cannot complete it, because much of the risk lives in business knowledge that was never written down. Operations managers, long-serving users and anyone who has had to work around the system's limitations all hold pieces of the picture.
What to Examine
- Data structures and quality: Are there fields that are no longer used but still populated? Are there records that fail basic validation rules? Is there data that exists only in the legacy system and nowhere else?
- Integration points: Does the system send or receive data from other software? Are those connections documented, or were they built informally? What happens to those systems if the data format changes?
- Undocumented behaviour: Are there reports, scripts or manual processes that query the database directly rather than going through the application interface?
- Timing dependencies: Are there batch jobs, scheduled tasks or processes that assume the system is available at specific times?
- Access and permissions: Is access controlled in ways that are not reflected in the user interface, such as direct database credentials held by individuals?
Structuring the Assessment
A practical approach is to work through the system by process rather than by technical component. Start with the most critical business workflow the system supports, map every step, and at each step ask what would break if the underlying data or logic changed. Then move to the next workflow. This ensures the assessment stays grounded in business impact rather than drifting into abstract technical concerns.
For each identified risk, record the specific trigger, the consequence if it occurs, the existing controls that might mitigate it, and what additional action would reduce it further. A risk described as "data might be lost during migration" is not actionable. A risk described as "customer billing records created between 2016 and 2019 use a deprecated address format that the new system rejects, which could cause those records to fail import" can be tested and addressed.
Questions to Put to a Supplier
If you are engaging a development company to carry out or support the migration, their approach to risk assessment is a useful indicator of rigour. Practical questions include: How do they identify risks that are not visible in the code or database? What role do business users play in the assessment? Do they produce a written risk register before migration work begins? How do they distinguish between risks that can be resolved in advance and risks that must be managed during the cutover? What is their threshold for escalating a risk to a go-no-go decision?
Common Mistakes
Assuming documentation reflects reality. In legacy systems, documentation is often outdated or was never accurate. The risk assessment should treat existing documentation as a starting point, not evidence. Verification means checking the actual data, the actual code paths and the actual user behaviour.
Testing with sample data rather than realistic volumes. A migration that works cleanly on a hundred test records may fail on a million production records due to performance constraints, duplicate handling or edge cases that only appear at scale. The risk assessment should flag volume as a distinct concern and the testing plan should reflect it.
Separating risk assessment from the migration plan. If the risk assessment is produced as a standalone document and then filed, it has failed. Each identified risk should have a clear owner, a mitigation action and a link to the specific phase of migration work where it will be addressed.
Omitting rollback from the assessment. Every migration should have a defined rollback position. The risk assessment should identify which risks would trigger a rollback, what the rollback process involves, how long it would take, and what data state the business would return to. If rollback is not feasible for certain elements, that must be stated explicitly and accepted as a conscious decision.
Excluding manual and offline steps. Not all risk lives inside the software. If staff print reports from the legacy system and use them as input for other processes, or if data is manually re-keyed between systems, those steps carry migration risk too.
What this work cannot prove on its own
A risk assessment reduces uncertainty but does not eliminate it. There will always be risks that only become visible during the live migration, particularly in systems with poor observability. The assessment should be honest about what cannot be known in advance and what the contingency is for those unknowns.
The assessment is also only as good as the access and information available. If the original developers are no longer available, if the database has been modified by multiple parties over years, or if there are third-party components with unclear licensing or support status, some risks can only be described in broad terms. That is acceptable provided the limitation is documented and factored into the migration approach.
Key Checks Before Proceeding
- Every critical business process supported by the legacy system has been walked through step by step with someone who performs it.
- All integration points, including informal ones, have been identified and documented.
- Data quality issues have been quantified rather than assumed to be minor.
- Each risk in the register has a named owner and a specific mitigation action.
- Rollback has been planned for, and the limitations of that rollback have been accepted.
- The risk register has been reviewed by someone who was not involved in creating it, to catch assumptions that have been treated as facts.
- The assessment has been completed before the migration approach is finalised, not afterwards as a justification.
Leave the next team with verifiable evidence
Once the risk assessment is complete and the findings are tied to specific actions, the business is in a position to decide whether to proceed, adjust the scope, change the migration method or accept certain risks with full awareness of what that means. That decision belongs to the business, not the supplier, and the risk assessment is the foundation for making it properly.