The System That Wouldn’t Die

A ghost story about legacy code, bad decisions, and the application I thought I buried in 2011.

legacy-systems war-stories technical-debt VBA Microsoft Access

In 2011, I was younger and far more confident than I should have been.

A DOS-based transaction tracking system needed to be replaced. It had been around forever. Nobody liked it. Nobody fully understood it. But it worked — and that made it dangerous.

It was written in Haskell. There was no source code. The single machine still running it had finally died. I tried to revive the hard drive anyway — late night, open chassis, misplaced optimism. Like an eager EMT on a chaotic Friday shift, I kept trying long after I should have known better.

Nothing survived.

The only backup was paper. Boxes of printed transaction logs. The business, preserved in ink.

The requirements were simple.
Or at least they sounded simple.

  • Low cost
  • No hosting
  • Built fast
  • Temporary

I had a week.

The Language Best Left Unspoken

With limited time and fewer options, I reached for the scariest tool I knew at the time: VBA.

Specifically, Microsoft Access.

We already had licenses. It ran locally. No servers. No infrastructure. No recurring costs. It felt pragmatic. Almost responsible.

I told myself it was temporary.

I spent nights hunched over forms and modules, tearing through recordsets, stitching business rules directly into VBA. Logic layered on logic. Duct tape holding together just enough structure to keep the whole thing upright.

I wasn’t building something elegant.

I was building something that worked.

And somehow… it did.

The Years Passed

Weeks turned into months.
Months turned into years.

“The Software,” as it came to be known, just kept chugging along.

It survived operating system upgrades.
It survived staff turnover.
It survived my growing realization that temporary systems have a habit of becoming permanent.

Eventually, I moved on. New roles. New stacks. New languages.

Python replaced VBA.
Databases lived on real servers.
Deployments became repeatable. Observable. Clean.

I buried Access alongside other things I preferred not to revisit.

Or so I thought.

It Came Back

In 2025, the past returned without ceremony.

The request was simple:

“We need a new version of The Software.”

By then, my primary development machine was a MacBook.
My daily tools were Python, Django, modern databases, proper deployments.

VBA was supposed to stay locked away with my earliest experiments.

But there it was.

Still running.
Still critical.
Still very much alive.

The Horror of Legacy

The real terror wasn’t that the system existed.

It was that:

  • People depended on it
  • Data lived inside it
  • Nobody wanted it to break
  • Everyone assumed it would “just keep working”

Legacy systems don’t haunt you because they’re old.

They haunt you because they worked just well enough to never be replaced.

They become invisible infrastructure. Quiet. Untouched. Essential.

Until someone asks for a change.

The Lesson

This isn’t a story about Microsoft Access.
Or VBA.
Or even a rushed decision made under pressure.

It’s about what happens when “temporary” isn’t given an expiration date.

Temporary systems need discipline. A sunset plan. A migration path. A budget for replacement.

Without those, they calcify.

They move from workaround to bedrock without anyone formally deciding that’s what they’ve become.

Every developer has a system like this somewhere in their past.
Something built late at night.
Under constraint.
Meant to disappear quietly.

Sometimes it doesn’t.

Sometimes it waits.


It was past midnight when I reopened that file.
The same file I swore I’d never touch again.

— The Caretaker