Business logic in long-running software rarely lives only in source code. Some is in configuration, data, export templates and integrations. More exists in work instructions or the memory of experienced users. Rebuilding visible screens alone loses precisely the rules that hold operations together.
Discover behavior through several sources
Interviews matter but are not enough. Combine process observation, existing documentation, data profiles, configuration, support cases and concrete transactions. For every step, ask about variants: missing data, reversal, delegation, late approval and conflicting sources.
The most frequent path is not necessarily the highest-risk one. Month-end activities, rare complaints and regulated corrections deserve explicit attention.
Distinguish rules from friction
A workaround may be an important control or simply historical friction. Record the purpose, owner, inputs, decision, output and failure consequence of each rule. Only then decide whether the target preserves, simplifies or intentionally removes it.
That decision requires domain approval. “The old system does it this way” is not enough reason either to copy or discard behavior.
Build characterization tests
Martin Fowler describes characterization tests as a way to capture present behavior before change. Representative inputs can run through both legacy and target systems. Differences are not automatically defects; domain owners classify them as intended improvement, acceptable variance or parity failure.
Readable Given–When–Then scenarios help domain and engineering teams examine edge cases together. They do not replace other test layers, but create a shared, binding language.
Bound parity explicitly
“Everything as before” cannot be tested. Define critical behavior areas: calculation, state transition, authorization, import/export, notification and integration event. Record accepted differences and non-goals.
The parity catalogue becomes part of acceptance. Every rule links to its source, scenario, expected result and accountable owner. After migration, the team can still explain why the new system behaves as it does.
The rebuild therefore does not preserve every peculiarity. It preserves deliberately approved business logic and removes complexity consciously—with evidence rather than memory.