Pattern from the field · Manufacturing

743 Stored Procedures, 58 That Mattered

A manufacturer's production-scheduling system had 743 stored procedures. Only 58 carried the actual business. Here is what happens when you rebuild those and delete the rest.

Manufacturing · Anonymised client pattern

The situation

A manufacturer asked us to modernise their production-scheduling system. It was old, it was central, and a straight quote for a like-for-like rebuild had already been put in front of them. The system had 743 stored procedures. The assumption on the table, ours included at first, was that all 743 encoded something the business depended on, and that a faithful port meant carrying every one of them across to a newer stack.

That assumption is where most of the cost hides. Rebuilding 743 procedures faithfully is expensive, and it produces a system exactly as large and exactly as tangled as the one it replaces, just in a different language.

What was really going on

Not all 743 procedures were load-bearing. When the team started asking why each one existed, rather than how to port it, the shape changed. Fifty-eight of them carried the actual business: the rules that decided what got made, in what order, against which constraints. The rest were dead branches, abandoned reports, and workarounds for bugs that had been fixed years earlier and never cleaned up.

That distribution is common and it is easy to miss, because from the outside 743 procedures all look equally important. Nobody had ever been paid to work out which ones still mattered. It is cheaper to assume they all do and quote accordingly. The honest answer only appears when someone interrogates the system instead of transcribing it.

What we did

We refused to treat the codebase as a specification to be copied. Instead we worked out which procedures still carried weight and which were noise, one at a time, with the people who run the schedule rather than from the code alone.

We rewrote the 58 that carried the business and deleted the rest. The system that came out was smaller than the one that went in: smaller surface to maintain, fewer paths that can fail, fewer things to test on every change. That is the point most rebuild quotes miss. The goal was never to reproduce 743 procedures on a newer platform. It was to find the 58 that earned their place and let the other 685 go.

This is what we mean when we describe legacy modernisation as subtraction rather than translation. The value is not in how faithfully you copy the old system. It is in how honestly you decide what does not need to exist. We wrote about the underlying idea in modernisation is subtraction.

What changed

The engagement came in roughly 30 percent under the quote a straight port would have cost. That figure is openly estimated against the like-for-like quote rather than measured to the pound, but the direction is not in doubt: rebuilding 58 procedures instead of 743 is a smaller job, and the result was a smaller system to run afterwards.

Smaller surface meant fewer rollbacks, less to test on each release, and a lower invoice both to build and to maintain. The saving was not a clever discount. It was the direct consequence of not rebuilding six hundred things nobody used.

If your last modernisation delivered the same logic in a newer wrapper, the stack was probably not the problem. Nobody was paid to ask which parts still mattered. If you are scoping a rebuild and you want it to come out smaller than it went in, talk to us before the quote is signed, not after.

Anonymised, composite pattern drawn from real engagements. Figures are openly estimated, not audit-grade.

Recognise this in a system you own? We can talk it through.

The rewrite is the easy part. The diagnosis isn't.