You get a written account of what your system does, where it will hurt you, and what to do about it. Your board can read it and your developers can test against it.
We read the code and we sit down with the people who run it. In the assessment below, a month-end close that two managers independently described as routine resolved to a program with no recorded use at all. Neither the code nor the conversations would have caught that on its own.
Read it and decide for yourself whether the work is worth buying.
Risk Register
What You Are Exposed To
Eight findings, each rated for impact and likelihood against your own numbers, each naming the control that is actually working today. Every rating is a lookup on a published grid, so your team can check the work.
The ones that matter sit where a technical fact meets how you actually operate. Freight quoted from tables last changed in 2019, corrected by hand on thirty to forty orders a day by one person. A web portal selling configurations the plant cannot build, caught by two engineers before they reach the floor. Neither of those shows up in code analysis and neither shows up on an org chart.
Business Logic Documentation
The Rules Nobody Has Written Down
The processes you nominate get read line by line, and the people who run them get interviewed. Both, because the code does not record why anyone built it that way, and the people working around it every day know things the system never wrote down.
You get every rule in the order the code applies it, with the program and line it came from, acceptance cases, and a worked example traced end to end. Five processes here, holding 511 rules that existed only in code and in one developer's head. Your team can test them and a vendor can quote them.
Dependency & Integration Maps
What Talks to What
The call graph, coupling measured per program, and every connection to the outside world with its protocol, its failure behavior and its owner.
Ten programs here carried the coupling, the complexity and most of the business rules at once. Twenty-two of the thirty-four connections from the new Azure layer read the database directly instead of calling the programs that own the rules. Seven of the eight external boundaries had no owner.
Application Inventory
What You Can Still Change
Every object counted, split by whether a person wrote it or a generator emitted it. That split is what decides how much of your system is still recoverable.
This one reported 94.1% source coverage. On hand-written code it was 83.9%. Forty-seven programs with no source at all sit on live call paths. They run every day and nobody can change them. You get the list.
Modernization Roadmap
Multiple Paths, One Recommendation
Every system gets its own set of paths. This one had three: refresh the hardware and change nothing else, refresh and re-sequence, or replace. Yours will be different. Each is assessed on the same criteria, with an effort class, a delivery risk, and what it does to your risk register.
You get the options and you get a recommendation you can act on. The rule that picks between them is published with its thresholds, fixed in advance, and only the measured values change. Disagree with a threshold, move it and re-run the rule yourself. The path we recommend is broken into stages you can stop after. The report, the exports and the rule register are yours, to keep and to hand to whichever vendor you choose.
Get the Sample Assessment
Tell us where to send it. The PDF is on the next page. Downloading it does not schedule a call.
We may follow up with you about your interest. We do not sell or share your details. See our privacy policy.