Legacy Risk Map — Claude Code Guide

Business criticality and change risk are different dimensions

Business criticality shows how painful a failure will be for users or the business. Change risk shows how easily the proposed change could disrupt behavior. A critical flow may have low change risk when the fix is well isolated, while a secondary module may have high change risk because of a shared utility and missing tests.

Do not reduce these dimensions to one score. Make visible unknowns explicit: an unknown owner, unverified configuration precedence, or conflicting docs affect the decision even when business impact has not yet been assessed.

Minimal risk-map entry

Examples of decisions, not generic improvement

• mrr-engine / pause-resume MRR: high business criticality and high change risk; approximately 25% coverage and a possible code/docs discrepancy — characterize behavior and check the owner before changing anything;
• payments / retry recovery: high/high because of money and external integration — gather recovery evidence and narrow the scope to one retry path;
• config / timezone + feature flags: medium/high — document precedence and perform manual verification for dates and flags;
• legacy/OldBillingUtils.java: broad impact and weak tests — build a module/flow map first instead of starting a mass refactor.

Operational actions from the risk map

A risk map should lead to a decision: what can be done now, what needs evidence, and what should be deferred. “Improve quality” without an owner, scope, and check is not an operational action.

1. characterize current behavior for a high/high flow;
2. gather more evidence when unknowns block the assessment;
3. identify an owner for the business rule or critical integration;
4. document configuration precedence when behavior depends on several layers;
5. hold the change or narrow the scope when evidence is insufficient;
6. freeze changes or defer the work when risk exceeds verification readiness.

Git churn as a supporting signal

In the learning example, the result might be 11, but treat this only as a churn signal. The number alone, without a period, source, and threshold, does not prove risk. Add it to the evidence, compare it with other modules, and decide whether deeper discovery is needed.

git log --since="1 year ago" --name-only --pretty=format: \
  | grep 'mrr-engine/MrrFormulas.java' | wc -l