Business rule extraction is the work of finding, naming and writing down the decisions a system makes, such as who qualifies, what something costs and where a case goes next. The rules come from the code, the data and the people who run the system, and the result is a catalog the business can read and check.
Below: where rules hide, the method we use to trace them, a catalog template, and what the tools do, in their vendors' own words.
- Business rule extraction means finding, naming and writing down the decisions a system makes, such as eligibility, pricing, validation, routing and calculations.
- Rules hide in screen triggers, stored procedures, batch jobs, configuration tables, reports, copybooks and the spreadsheets beside the system.
- Start from the outputs the business cares about and trace backwards. Record each rule with its source, conditions, an example, an owner and a confidence level.
- Tools speed up the search. A person still confirms each rule with the business owner and pins it with a test.
What counts as a business rule?
A business rule is a decision the system makes on the business's behalf. Most fall into a few kinds (examples illustrative):
| Kind of rule | Example |
|---|---|
| Eligibility | A customer can't open a second account while the first is overdue |
| Pricing | Orders above a set quantity get the volume rate |
| Validation | A ship date can't fall before the order date |
| Routing | An order over the customer's credit limit goes to credit review instead of shipping |
| Calculation | Interest accrues daily and is rounded once, at month-end |
| Timing | Payments received after the cutoff post on the next business day |
Writing rules down is the point. The Business Rules Group's Business Rules Manifesto says rules "should be expressed declaratively in natural-language sentences for the business audience," and "in such a way that they can be validated for correctness by business people." That's the standard for every extracted rule: someone in finance or operations can read it and say yes or no.
Where business rules hide in legacy code
Rarely in one place. Check each of these:
- Screen triggers and form events. Validation that fires when a user leaves a field or saves a record, such as WHEN-VALIDATE-ITEM triggers in Oracle Forms or control events in a VB6 form.
- Stored procedures and database triggers. Checks that run whichever application writes the row.
- Batch jobs. Overnight jobs that apply fees or change statuses. Even the order they run in can be a rule.
- Configuration and reference tables. Rates, status codes, flags and thresholds that change behavior without a code change.
- Reports. A report's filter often defines a business term, such as which customers count as active.
- Copybooks and shared includes. In COBOL, copybooks hold shared record layouts, and a field's allowed values can carry business meaning into every program that includes them.
- Spreadsheets beside the system. The adjustment someone applies by hand each month.
- People. The manual override support staff use when a case doesn't fit.
The same rule often lives in two places, written slightly differently. Find both.
Business rule extraction from legacy code: a method
Don't start with the code. Start with the decisions.
- List the outputs and decisions the business cares about. The invoice total, the approval, the queue a case lands in. Ask the business owner which would hurt most if a replacement got them wrong.
- Trace backwards from each output. Find every place that sets or changes it: code paths, database writes, batch jobs and the reference tables they read. Follow the conditions, not only the assignments.
- Record each rule as you find it, in plain language, with its source location, the conditions under which it applies, a worked example, a business owner and a confidence level.
- Check the rule against the data. A rule that never fires on real records, or fires differently from what the code suggests, means something has changed.
- Confirm with the business owner. Each rule is intended, obsolete or a bug, and only the business can say which.
- Pin it with a test. Write a characterization test for each confirmed rule, so a migration or refactoring can't drop it silently.
For the tracing itself, see how to understand legacy code. If one person holds most of the reasons, capture their knowledge while they're still here.
A business rule catalog template
Copy the columns. The rows are illustrative.
| ID | Rule, in plain language | Source location | Conditions | Example | Owner | Confidence | Status |
|---|---|---|---|---|---|---|---|
| BR-014 | Orders over the customer's credit limit go to credit review instead of shipping | Order entry screen, validation on the order total; repeated in a database procedure | Total above limit, customer not on prepayment | Limit 5,000, order 6,200: routed to review | Head of credit | High | Confirmed |
| BR-027 | The first late payment in 12 months has its late fee waived | Nightly fee job, third step, reads a waiver table | Payment late, no other late payment in the prior 12 months | Second late payment in a year: fee charged | Finance operations | Medium | With owner |
| BR-031 | Accounts in status 9 are left out of the monthly statement run | Statement report query | Status equals 9 | Account in status 9: no statement produced | Unknown | Low | Open question |
High: the code, the data and the owner agree. Medium: the code and data agree, but the owner hasn't confirmed. Low: the rule is inferred, or the sources conflict. A catalog full of Medium rules is a to-do list, not a specification.
Business rules extraction tools
Tools speed up finding where a rule might live. They don't decide what it means.
| Kind of tool | Good for | Can't do |
|---|---|---|
| Static analysis and cross-reference | Showing every program that reads or writes a field | Say which conditions matter to the business |
| Code search | Finding every use of a status code or threshold | Find rules that live in data or in people |
| AI assistants | Drafting a plain-language summary of a procedure for a person to check | Guarantee the summary is right; see AI for legacy code |
| Vendor modernization services | Rule documentation inside a larger migration on one platform | Confirm the rules with your business owners |
Two mainframe services, described from their vendors' own documentation:
- AWS Transform. AWS's mainframe user guide describes a business logic extraction step that runs at "Application level" or "File level," stores results in Amazon S3 in JSON format, and notes: "Documentation can be generated only for COBOL and JCL files."
- IBM watsonx Code Assistant for Z. IBM's product page lists "Explain code in natural language" among its capabilities for mainframe applications.
Treat any tool's output as a first draft of the catalog. Confirming each rule with its owner is the slow part, and where the value is.
How the 30-day assessment handles rules
Before a migration or rewrite, the rules are the requirements, as we argue in before you rewrite a legacy system. The 30-day assessment is fixed in scope, at a price agreed before we start. Over 30 days we read the codebase and the architecture around it, map how the system fits together, find the hidden architectural debt, and flag the security and compliance gaps. For the decisions you tell us matter most, we trace the rules back through the code and the data and record them in a catalog like the one above, with source locations and confidence levels.
The report says in plain language what is broken and what it would take to fix it, and marks which rules still need a business owner's confirmation. Your own team can act on it, or we can do the work as a separate project with its own scope and price. The report stands on its own either way.
Email Santosh a short list: the system, what it runs on, and the decisions you most need written down. If a narrower check would answer the question, we'll say so.