The requirements your legacy system never had.
The logic that runs your system lives in old code, a Salesforce org, and the heads of people who have left. No current document says what it does. Our Business Rule Extractor recovers it: we read your source, our engineers validate what it finds, and you get a documented requirements specification of how the system really behaves.
Nobody can say exactly what the system does. That is the blocker.
A rewrite, an audit, a takeover, or an acquisition stalls at the same sentence: "we don't have documentation, and nobody fully understands what it does anymore." The behavior that matters, the rules, the calculations, the edge cases, is buried in code written years ago, or in a Salesforce org customized over a decade, by people who have since left. There is no current specification to work from, so every downstream decision is a guess.
The Business Rule Extractor gives you the specification that was never written. The deliverable, stated plainly: a documented requirements specification of how the system actually behaves today, built on the business rules and edge cases recovered directly from the source.
What the system does
Functional behavior, step by step, described the way a requirements document would have described it if one had ever existed.
The rules that govern it
The conditions, calculations, thresholds, and validations that decide outcomes, written down instead of left implicit in the code.
The edge cases nobody remembers
The exception paths and special conditions that only fire under specific inputs, recovered before a rewrite silently drops one.
From an undocumented codebase to a specification you can act on
You give us read-only access to your source code repository
Or your Salesforce org, under confidentiality agreed in writing first. No annotated code, no partial documentation to assemble, no reverse-engineering effort on your side, and no running environment to stand up.
The extractor reads the source
It follows control flow, conditionals, calculations, validations, and data transformations across the system, the paths a person would have to trace by hand over weeks.
It identifies the business rules and edge cases
Not just the happy path. The exception handling, the special cases, and the quiet conditions that only fire under specific inputs, the parts a rewrite is most likely to miss.
Our engineers review and validate the output
Every extracted rule is checked by an AnAr engineer before it reaches you. You get a validated specification, not a raw model dump you then have to audit yourself.
You receive a documented requirements specification
A readable account of how the system actually behaves, delivered in the format your team wants to work from.
The rules a rewrite breaks are the ones nobody remembered were there. This is the tool that finds them first and writes them down.
A specification you can hand to a rebuild, an auditor, or a new team
The output is a readable requirements document, not a diagram dump and not a bare list of extracted strings. It is organized the way an engineer inheriting the system would need to read it, and it is validated by a person before it reaches you.
Functional behavior, described
What the system does, walked through step by step, in the language a requirements document uses, so it is usable by people who will never read the code.
Business rules, written down
The conditions, calculations, thresholds, and validations that drive outcomes, stated explicitly instead of implied by nested logic.
Edge cases and exception handling
The special paths and failure conditions that are easy to overlook and expensive to rediscover in production.
Decision logic and dependencies
How rules relate, what depends on what, and where changing one behavior ripples into another.
Reviewed by an engineer, not a raw model dump
Every rule is validated by an AnAr engineer before hand-off, so you are reading a checked specification, not an unaudited machine summary. That is the difference between a document you can build on and one you have to re-verify yourself.
When you need to know what the system does before you touch it
The extractor is the knowledge-recovery step that comes before the risky work. It sits in the Understand phase of our four-phase method, codebase comprehension done properly, and it feeds the work that follows.
You are about to modernize or rewrite, and no spec exists
The recovered requirements become the reference the rebuild is measured against, so parity is verifiable instead of hoped for. See legacy application modernization and AI-driven application modernization.
You inherited or acquired a system
A takeover starts with knowing what you took over. The extractor documents the system before you commit to changing it. See application maintenance.
Compliance or audit needs the rules documented
When a regulator or auditor asks what the system does and why, the answer is a written specification, not tribal memory.
You need a functional test suite but have no spec to test against
The recovered rules feed our Automation Testing Framework to also produce a backend functional test suite, so recovered behavior becomes verified behavior.
This is the Understand phase of our method applied to inherited systems. Supported sources: .NET, VB.NET, classic ASP, Java, legacy web and desktop applications, and Salesforce orgs, the mid-tier stacks most rule-extraction tooling skips in favor of mainframe COBOL.
What it looks like on a real system
These are the shapes of engagement the extractor is built for, described by situation, not by client, because the point is the pattern you may recognize.
Modernization prep, mid-tier legacy
A team ready to rebuild a decade-old .NET or VB.NET application with no current spec of what it does. Before writing a line of the rebuild, the extractor recovers the business rules and edge cases so the new system has a reference to match, not a guess to chase.
Post-acquisition system takeover
An organization acquires a product and its codebase, but not the people who built it. The extractor documents the acquired system's real behavior so the receiving team can operate and change it without relearning it by breaking it.
Compliance and audit documentation
A regulated system whose governing rules were never formally written down. The extractor produces a specification of the rules the system enforces, ready for review, so the answer to "what does it do and why" is a document instead of tribal memory.
A Salesforce org nobody fully owns anymore
Years of admins and consultants have layered flows, validation rules, workflow rules, process builder, and Apex on top of each other, and the logic driving your records is no longer written down anywhere. This is where teams reach for the extractor on Salesforce:
- Before a migration or consolidationYou are moving to another org, another platform, or a Salesforce reimplementation, and you need to know what the current org actually enforces before you move it.
- After the admin or consultant leavesThe automation still runs, but no one can say precisely why a record behaves the way it does.
- When an audit or compliance rule appliesSomeone asks what the org enforces on customer, financial, or regulated data, and the answer today is "we'd have to read the flows."
The deliverable is the same: a documented requirements specification of what your org actually does, so you can migrate, rebuild, or govern it with intent instead of guesswork.
Scenario shapes, not client results. The extractor is built and in use; we do not publish invented numbers or named cases for it.
Why teams trust AnAr to read code they can no longer read themselves
We built the extractor, and our engineers validate its output.
Not a reseller of someone else's tool. It is built and operated by the same engineers who modernize and maintain client systems every day.
We run it on real, inherited production codebases.
The extractor earns its keep on messy, undocumented, years-old systems, not demo apps, because that is exactly what clients hand us.
150+ projects. 95% client retention. 12 years of delivery.
The tooling matters because the delivery around it is proven. Clients stay with us for years because the systems we touch keep working.
Your code stays yours.
Confidentiality is agreed in writing before any source is shared. Visibility is read-only and limited to the engineers assigned to your engagement, and the recovered specification is yours.
What teams ask before putting it to work
If your question is not covered below, a short note to our engineering team is the fastest way to a specific answer about your system.
What do you need from us to start?
Read-only access to your source code repository, or your Salesforce org, under confidentiality agreed in writing first. No annotated code, no existing documentation, no requirements document to assemble beforehand, and no running environment to stand up.
Is this a product we buy, or a service?
A service. Our engineers run the extractor and validate the output. You receive a documented requirements specification, not a tool to operate yourself.
What does the output look like?
A readable requirements specification: functional behavior described step by step, the business rules and edge cases that govern it, and the decision logic and dependencies between them. Tell us how your team wants it delivered and we will match that format.
What languages and sources do you support?
.NET, VB.NET, classic ASP, Java, legacy web and desktop applications, and Salesforce orgs, the mid-tier stacks most rule-extraction tooling ignores. Tell us your stack and we will confirm fit before any work starts.
How is our source code and IP protected?
Confidentiality is agreed in writing before any source is shared. Visibility is read-only and limited to the engineers on your engagement. The recovered specification is yours.
Can we use the output for a rewrite, or only with AnAr?
The specification is yours to use however you choose, including handing it to your own team or a different vendor for the rebuild. If you want the recovered rules turned into a backend functional test suite, that chains into our Automation Testing Framework.
Tell us about the system nobody can fully explain
A short note is enough. Tell us about the system and what is blocking you, and our engineering team comes back with a real read on what running the extractor on it would involve.
Come to us with:
- A modernization or rewrite blocked because no current spec exists
- A system you inherited or acquired that nobody fully understands
- A Salesforce org whose logic is no longer written down anywhere
- A compliance or audit need for the rules written down
You will speak with engineering, not sales. The first reply comes from someone who can answer technical questions about your system, within one business day.
Send a Message
A few details so the right engineer follows up.
Routed to the right engineer
Your note goes to someone who has read code like yours, not to a sales queue.
A written reply within one business day
A real read on what running the extractor on your system would involve, not a sales sequence.
A review to go deeper
If it is a fit, we scope the source, the confidentiality terms, and the specification you would get back.
Rebuilding the system next? See Legacy Application Modernization →
Taking over a system you inherited? See Application Maintenance →
See every tool we build: AnAr AI Accelerators →