Every long-running system accumulates rules that exist nowhere else: a discount that applies only to one region, a rounding quirk a regulator once required, an exception added after an incident in 2011. The people who knew why are often gone. The documentation, if it exists, describes the system as it was designed, not as it behaves. The code is the only reliable record — and the first thing a modernization project should do is read it.
Why this comes before any rebuild
Rewrites fail most often by forgetting something. The new system looks cleaner, passes its tests, and then produces a different invoice total for a rare customer type nobody remembered. Recovering the rules first turns forgotten behaviour into a checklist, and a checklist can be tested.
A practical recovery process
- Trace the money and the obligations first — pricing, tax, interest, approvals, retention periods. These are the rules where a silent difference costs the most.
- Use a language model as a reader, not an author — it is good at summarizing what a block of old code does in plain language, listing its conditions and flagging odd constants. Treat the output as a draft for a human to verify, never as truth.
- Capture characterization tests — run the existing system on a broad sample of real inputs and record the outputs. These become the safety net: the new system must reproduce them or explain every difference.
- Interview the people who live with it — support and operations staff know which behaviours are features and which are bugs everyone works around. Ask what they would be upset to lose.
- Classify each rule — keep, change deliberately, or retire. Writing this down is the moment the business, not the code, decides what the new system should do.
A rule you can state in one sentence and test with three examples is a rule you can safely move. A rule you can only describe as 'it just does that' needs investigation before anyone touches it.
How this fits the strangler approach
Incremental replacement works because each slice can be compared against the old behaviour. The recovered rules and the recorded outputs are what make that comparison possible. They turn a risky migration into a sequence of small, verifiable swaps — which is also what lets the business keep running while it happens.