01
Rule extraction
Business rules lifted out of the implementation and written down against the process they actually serve, not the module they happen to live in.
Legacy modernisation becomes possible when someone knows what the code does.
Modernisation stalls because nobody knows what the code does. Pexon extracts the business rules out of legacy and mainframe systems, documents them against the processes they serve, and generates tests around the current behaviour, so a rewrite can be verified rather than hoped for.
The starting point
The rules live in code nobody has read this decade.
The people who wrote it have retired, the documentation describes an earlier version, and every proposed rewrite stalls at the same question: what exactly does the current system guarantee?
That question is answerable, and the answer is where every modernisation decision should start. The work below is about producing that answer cheaply and reliably, before anyone commits to a rewrite, a wrap or a retirement.
Start with the subsystem that blocks the most work.
Usually the one every change request has to route through. Two weeks is normally enough to establish whether the rules are recoverable and what a full extraction would cost.
What we build
How we make it tractable
02
Test generation
Characterisation tests generated around current behaviour, so a rewrite can be checked against what the system does today.
03
Prioritised map
Which rules are load-bearing, which are dead, and which are duplicated — the input a modernisation decision actually needs.
Why extraction has value on its own
The extraction is the decision, not the rewrite
A documented rule inventory changes the conversation even when nothing is rewritten. It turns "we should modernise" from a slogan into a list: which rules are load-bearing, which are dead, which are duplicated across modules. That list is what makes any modernisation path — including deliberately doing nothing — an informed choice instead of a bet.
The languages in the common cases — COBOL, PL/I, older Java and .NET estates — matter less than the availability of source and runtime behaviour. Where both are available, the extraction approach is the same; where they are not, that is the finding the two weeks exist to produce.
Modernisation paths
What the map unlocks, and when each path is right
| Path | What it is | When it is right | What it needs |
|---|---|---|---|
| Rewrite | Reimplement the subsystem on the current stack | The rules are recoverable and the subsystem is load-bearing | The extracted rules and the generated tests as the contract |
| Wrap | Put an API in front of the existing system | The rules are stable and the risk of touching them is higher than the cost of keeping them | A service boundary and a test harness around current behaviour |
| Retire | Decommission rules nobody uses | The map shows dead or duplicated rules | The prioritised map, agreed with the business owners |
| Do nothing | Keep the system, with the inventory as insurance | The rewrite cannot be justified yet, but the knowledge must stop living in one head | Nothing but the extraction itself |
The map does not pick the path; it makes the path pickable. All four options become decisions with an evidence base, which is the entire point of the two-week engagement.
What changes
- A rewrite can be verified against documented behaviour instead of guessed at.
- Dead rules are identified and dropped rather than faithfully reimplemented.
- The knowledge stops depending on one person's memory.
- The modernisation decision has a costed evidence base instead of a vendor pitch.
The honest case for doing nothing: if the subsystem is stable, unthreatened by regulatory or cost pressure, and nobody is proposing to touch it, the extraction may still be worth doing as insurance — but a rewrite is not. The two weeks tell you which of those you are in.
More in Data foundation
Legacy specifics
Do you rewrite the system as well?
We can, but that is a separate decision and deliberately a later one. The extraction has value on its own: it is what makes any modernisation path — including doing nothing — an informed choice.
Which languages do you handle?
COBOL, PL/I and older Java and .NET estates are the common cases. The approach does not depend on the language so much as on whether the source and the runtime behaviour are both available to us.
Next step
Not a sales call. An architecture call.
Thirty minutes with the architect who would actually run the engagement.