When this becomes a buying problem
Important behavior is distributed across code, stored procedures, reports, configuration, exception handling, and human workarounds - and no single source fully defines intent.
Questions to answer before scope
- What operational problem makes business logic preservation during modernization necessary now?
- Which system, workflow, users, data, environments, and downstream actions are inside the boundary?
- Which behavior or authority cannot change without explicit approval?
- What evidence will support the next decision?
- Who owns the technical, business, security, procurement, and final release decisions?
- What is expressly excluded from the first engagement?
A defensible working sequence
- Behavior discovery and source tracing
- Scenario inventory and characterization testing
- Old-versus-new output comparison
- Data reconciliation and exception analysis
- Known, unknown, disputed, intentional, and accidental change classification
- Deliver the named outputs: Business-rule map, Parity scenario catalog, Comparison and reconciliation report.
- Use the evidence to support this decision: Which behavior must remain, which change is intentional, and whether a release is acceptably equivalent.
Artifacts that should remain
- Business-rule map
- Parity scenario catalog
- Comparison and reconciliation report
- Unknown and disputed behavior register
- Domain-owner review record
Common failure modes
- A claim that all behavior can be discovered
- Replacement of domain-owner judgment
- Legal interpretation of business rules
- Guaranteed zero regression
- Starting implementation before the decision and evidence basis are written
- Treating a framework or checklist as proof that a specific system is safe or compliant