How to modernize software without losing the business rules
A rewrite can reproduce the obvious screens and still lose a rule the business depends on. Those rules may live in code, an export, an old spreadsheet or the knowledge of the person who handles exceptions.
Build a baseline of behavior
Record the important tasks, their inputs and expected results before changing the implementation. Include calculations, permissions, reports and integration messages. Ask what happens after a correction or an incomplete record, not only on the normal path.
In ZMatic’s move to a custom ERP, the spreadsheet dependencies were part of the business knowledge that needed to be understood. The migration was more than a transfer of rows.
Give each dependency a test
Identify the systems and people consuming the current output. For a document workflow, that may include existing identity and permission rules: ECONT’s DMS retained sign-on and access supplied by the ERP.
Use those dependencies to define acceptance examples. A new screen may look right while a report or downstream system receives the wrong value.
Rehearse the move
Map identifiers, decide which history moves and keep unresolved records visible. Rehearse with representative data. Compare business totals and relationships as well as counts, then test complete tasks with the imported records.
Before release, agree which system becomes authoritative, who performs the checks and what would trigger a rollback. If both systems remain active temporarily, write down who owns each record during that period.
The legacy application modernization scope needs to include this transition work alongside the replacement code.
