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 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?
How we make it tractable
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.
Test generation
Characterisation tests generated around current behaviour, so a rewrite can be checked against what the system does today.
Prioritised map
Which rules are load-bearing, which are dead, and which are duplicated — the input a modernisation decision actually needs.
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.
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.
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.
Not a sales call. An architecture call.
Thirty minutes with the architect who would actually run the engagement.