The most reliable way to recover business rules from an old system is to run the old and the new system together on live transactions, then explain every difference in writing. Reading code shows what the system does. Talking to managers shows what they believe it does. The side-by-side run shows where the two disagree, and each disagreement is a rule.
Why the code alone is not enough
Source code answers "what happens". It does not answer "was that intended". Old code mixes three kinds of behaviour, and on screen they look identical:
- Rules the business chose. A discount ceiling, a rounding convention, an approval limit.
- Workarounds for faults that were fixed elsewhere. The code still carries the patch.
- Branches nobody has run for years. They belong to a product, a branch office or a tax rule that no longer applies.
Copy all three and the new system inherits old accidents. Copy only what you recognise and it drops rules that mattered. You need evidence from outside the code to sort them.
Five steps
1. Watch before you ask
Whoever explained the process at the kickoff is often not the person who runs it. Sit beside the operator for a shift. Note every moment where they do something the process map does not show: a figure typed twice, a spreadsheet opened beside the screen, a call to a colleague.
Then ask about that moment. "You re-entered that value. What does the system do if you do not?" gets a better answer than "Are there any exceptions?" Operators stop noticing their own workarounds.
One question works in most workplaces: when the software blocks the correct action, what do you do instead?
2. Run old and new together
Send the new system a copy of the live transactions the old one handles, for a stretch long enough to include a month-end and a quarter-end if the process has them. Keep the old system as the record while you compare.
3. Reconcile every record by program
Compare every output record, line by line, each day. A monthly review of twenty sampled records misses the rare cases, and the rare cases hold the rules you are hunting. A daily full comparison costs a script and some patience.
4. Explain every difference in writing
For each difference, record the cause and a decision. "Resolved" is not a cause. A pair of differences that add up to zero in the totals still counts: two errors cancel today and will separate when volumes change.
5. Write a test for each finding
A rule in a document is forgotten within a couple of years. A rule in an automated test fails the build when someone removes it without understanding it. Write one test per resolved difference, with a comment giving the reason and, when known, the origin of the rule.
The discrepancy log
Keep one row per difference. This is the format:
| Field | Content |
|---|---|
| ID and date | When the difference first appeared |
| Records affected | Count and an example reference |
| Old output and new output | The two values side by side |
| Cause | The rule or fault that explains it |
| Verdict | Old behaviour correct, new behaviour correct, or fault in old system |
| Decision | Copy the rule, drop it, or change it, with the approver's name |
| Test | Link to the automated test that now guards it |
When the run ends, this log is the written specification that the project lacked at the start. Hand it to the next team with the code.
How to sort the differences
| Pattern | What it usually means | Action |
|---|---|---|
| Same difference on many records, one cause | A real rule | Copy it, write the test |
| Differences confined to one branch or customer group | A local exception | Confirm with the owner, then copy or drop |
| Differences that only appear at period end | A date-driven rule | Add the date cases to the test pack |
| Old output that cannot be explained by anyone | A fault or a dead branch | Ask the process owner; drop it if no one defends it |
| Totals match, lines differ | Offsetting errors | Treat as two defects and explain both |
Rules that tend to surface in Indian estates built on Tally, spreadsheets or an in-house ERP: a different rounding for one customer class; a tax treatment that changed in an earlier year and was patched as an exception; a branch whose data always loads a day late; a credit limit enforced on one screen and skipped on another; a price list that changes on a fixed date. A requirements workshop will not reveal these, since the staff who live with them have stopped seeing them as unusual.
Capture knowledge before people leave
Retirement is the biggest risk to old systems. When the last person who knows why the system behaves a certain way leaves, the reason leaves with them. Treat knowledge capture as a deliverable with a named owner and a date:
- List the people who can change each critical area, and for each area, who covers it if they go.
- Pair a second person with the sole holder of any critical area now.
- Record the reason beside every rule, not only the rule.
- Keep the discrepancy log and the tests under version control with the code.
When to plan the run
The run happens late in a migration, but you plan it at the start: the old system has to stay available, you need a way to feed both systems the same inputs, and someone needs time to review the daily differences. On platforms that must not stop, such as core ledgers, AS/400 and mainframe modernisation uses the same method behind an interface. For the order of systems, see which legacy systems to modernise first. For cutover timing, see big bang or phased rollout. Data problems turn up in the same run; ERP data migration covers them.
Questions buyers ask
How long should the parallel run last?
Long enough to include every period-end event the business has: month-end, quarter-end and any annual cycle. Stop only when the difference count has stayed at zero for a full cycle.
What if the old system has no clean input feed?
Capture the inputs at the point of entry, by copying transactions as they are posted, then replay them into the new system. Plan this early because it needs a change in the old system or its database.
Who signs off a discrepancy?
The owner of the process, not the engineer. The engineer finds the difference and the business decides which behaviour is correct.
Where Brihat Infotech fits
Brihat Infotech's legacy modernisation work includes behaviour tests and parallel-run evidence among its deliverables, and data migration with checksums between old and new. For the full picture, see the legacy modernisation guide.