The Hidden Cost of Keeping Dead Systems Alive

We paid developers for six years to keep a dead system alive.

Support for our business system had ended. Couldn’t upgrade — we’d customized it so heavily the vendor’s own updates wouldn’t take. So we did what a lot of companies do: kept paying developers to bend it to our will.

Duct tape and prayer, at scale.

The company was $15M when the customizations started. It grew 20x on that system. Then it just… couldn’t anymore. Couldn’t scale, couldn’t report, couldn’t keep up.

So leadership made the call: start over. Ground-up implementation. Three-year effort.

And in the first planning meetings, I heard the sentence that starts every one of these fires:

We need to rebuild it to our specs.

I pushed back hard. We had one shot to do this right — why would we spend millions recreating the exact mess that got us here?

So we did something slower and less exciting instead. We documented every process first. Every discipline, mapped out, before anyone touched the new system. Then we held each process up against industry best practices and asked one question: is this customization a real business requirement, or a workaround?

The answer surprised everyone.

Not one customization was critical. Zero.

Every single one existed because the old system couldn’t do basic reporting. We’d spent years — and a lot of money — building requirements that were really just scar tissue around a broken system.

We fixed the processes. Ran the new system standard. The customizations didn’t get migrated. They got deleted.

That was early in my career. Twenty-five years later, I still watch companies make the same call — different system, same scar tissue.

If your team is telling you we can’t run standard, we’re different — document your processes first.

You might find out you’re not that different. You’re just used to the workarounds.

Staudt Advisory