What the old system knows
Every long-lived system accumulates rules that exist for a reason nobody present can explain. An odd rounding on a particular contract, a status that only three customers ever hit, a batch job that must run before another one. Each was a real decision, made once, in response to something that actually happened.
A rewrite that starts from the documented requirements will faithfully reproduce the system that was described, and quietly drop the system that was running. The gap between them shows up in week two, usually in finance.
Treat the strange behaviour as evidence, not as mess. Somebody put it there under pressure.
Replace at the seams
- 01Find the natural boundaries, where data already changes hands, and cut there rather than by module name on an architecture diagram.
- 02Put the new path behind the old interface, so callers do not move house and change job in the same week.
- 03Run both and compare. Disagreements between old and new are the requirements document you were missing.
- 04Retire only when the comparison has been boring for a full business cycle, including the month-end that always misbehaves.
The people who know
The most valuable input in any modernisation is the person who has worked around the system for years. They know which reports are trusted, which are printed and ignored, and which screen everyone opens first thing on Monday.
They are also, usually, the people most nervous about the project, with reason, since they will absorb the disruption. Bringing them in early is not a change-management courtesy; it is the cheapest requirements gathering available.
