Characterization before modernization

The problem

A bespoke system built sixteen years earlier sat between order intake, production scheduling, and dispatch. It worked. It also had no tests, no current documentation, and no one left who had written it. Two previous modernization attempts had been abandoned once the scale of the unknown became clear, which is the rational outcome of starting a rewrite you cannot verify.

The business need was real: the platform it depended on was reaching end of support, and reporting that should have taken minutes took days. But the order flow could not be interrupted, and "we think it behaves the same" was not an acceptable answer.

What we did

We refused to write replacement code for nine weeks. Instead we characterized the system as it actually behaved, which is rarely what the original intent describes. We instrumented the live system, captured real inputs and outputs across a full business cycle including month-end, and turned that into an executable description of known-good behavior — edge cases, rounding quirks, and all the accumulated exceptions that turned out to encode real commercial agreements.

Some of those quirks were bugs the business had long since adapted to. We catalogued them, showed the client which were load-bearing and which were not, and let them decide deliberately which to preserve. That list was the most valuable single artifact of the engagement.

Only then did we replace anything. Module by module, each new component ran against the characterization suite and, for the critical paths, in parallel with the old one — comparing outputs on live traffic until the difference was zero or explained. Cutovers happened one seam at a time, each reversible.

What we shipped

• An executable characterization suite covering the order-to-dispatch path across a full business cycle.
• A catalogue of undocumented behaviors, each marked as intentional, tolerated, or defect, with a client decision recorded against it.
• A phased replacement in which every module was verified against observed behavior before cutover.
• Parallel-run comparison on the critical paths, with differences reconciled rather than waved through.
• Reporting rebuilt on the new foundation, with the long-running queries reduced to interactive time.

The result

The order flow was never interrupted. Every behavior change that shipped was a change someone chose, and there is now a record of who chose it and why. The two abandoned attempts had failed at the same place — the point where an unknown surfaces and there is nothing to check the new code against. Removing that unknown first is what made the third attempt finish.

The characterization suite is still in use as the regression gate for ongoing changes.

Client identity withheld by agreement.

Contact