Where 1,658 business rules ended up

The common picture of modernization is that you read the old code, find the business rules, and rewrite them in the new stack. On a recent system we did the first part thoroughly and then counted. Fewer than a third of the rules belonged in the new code.

The system was a desktop admin tool written in VB.NET WinForms over an Oracle database. Most of its logic wasn't in the VB.NET. It was in a large body of PL/SQL packages and triggers. The target was a .NET web API with new React screens. The client isn't named here.

Every rule gets an owner

Discovery extracted 1,658 business rules from the forms, the packages and the triggers. Each rule records where it came from, down to the file and line. Before anything was built, every rule had to land in exactly one place, and a coverage check refused to pass the plan until all of them had.

477 rules (29%) are rebuilt in the new application. These are the validations, calculations and workflow decisions that live in the forms or are called from them. Each one is owned by exactly one capability specification, and the build is tested against it.

762 rules (46%) stay in the database. The client chose to keep the Oracle schema and its triggers running, and the triggers keep doing their jobs: stamping who changed a record, writing audit history, keeping cached totals in sync, and in some tables assigning primary keys. The specs say so explicitly, and the new code is told not to reimplement them. Doing both would write every audit entry twice.

419 rules (25%) are excluded, each with a reason: duplicate logic, code no screen calls, or functions outside the agreed scope.

The rules that need a person

39 rules were marked suspect: the legacy behaviour looked like a defect. One extended-price calculation used a hard-coded number where a variable value was expected. Fixing it might be right, or downstream reports might depend on the wrong number. That is a business decision, so the spec records the rule as blocked with no default and asks the owner.

Three capabilities raised a different question. Their PL/SQL was live in production, but the forms that called it weren't in the compiled project. Is that dead code, or a feature someone runs from a different tool? The plan lists drop-or-build as an open decision instead of guessing.

What an earlier AI pass got wrong

On another system, an earlier AI-generated plan referred to two dedicated audit tables. Checking against the source showed they didn't exist: auditing was done with columns on each table plus one change-log table. A rebuild from that plan would have created tables nobody needed and missed the real mechanism. Since then, the processed source code is the ground truth. When a generated document disagrees with it, the code wins and the disagreement is recorded.

What this means for a modernization budget

• "Rewrite all the rules" overstates the work. Here, 71% of the rules either stay where they are or shouldn't be carried forward.
• "Keep the database" is a decision with consequences. It saves migration effort, and it means the new code has to share responsibility with triggers it doesn't own. That needs writing down before the build starts, not discovering in testing.
• Suspect rules are where projects go wrong. Silently fixing a bug the business relies on is as damaging as copying one it doesn't. Each one needs an owner and a decision.

FAQ

How are rules found in stored procedures? ARC reads the database code together with the application code, and links each rule found on a form to the database logic it depends on. A rule's full behaviour then reads as one record with citations to both layers.

Does keeping the database rule out moving it later? No. Each frozen rule is listed, so a later database migration starts from a known inventory instead of a fresh investigation.

Is 29% typical? We don't know yet, and one system isn't a benchmark. The split depends on how much logic lives in the database and how much the client chooses to keep there. The useful number is the ledger itself.