Your shop runs on an Access database from 2004. Here are your three real paths.

First, the thing nobody says out loud: that Access database was a good decision. Somebody built it for a few thousand dollars in 2004, it fit the shop exactly, and it has processed twenty years of orders while "real" ERP systems came and went at your competitors, taking their budgets with them. You didn't fall behind. You got your money's worth several hundred times over.

But you're reading this, which means something changed. Usually one of three things: the person who understood it left or passed away; the PC it lives on is making noises; or the business outgrew the single-user assumption and now two people can't enter orders at the same time without corrupting something.

Here's the honest risk model, and then the three paths.

What actually fails first

It's rarely the database. Access files are surprisingly durable. What fails, in the order we actually see it:

• The machine. The .mdb lives on one aging PC or an old server

share. Disk death is the most common total-loss event — and "we have backups" often means "we had backups until the backup drive filled in 2019."

• The glue. ODBC drivers, a Windows update, an Office version bump.

The database is fine; nothing can talk to it anymore.

• The person. The queries, the forms, the "don't touch that column"

folklore — all in one head. When that head retires, the system keeps running but becomes unmodifiable. That's the quiet failure: the shop changes and the software can't follow.

• The assumption. Single user, one site, trusted network. Growth

breaks these before anything crashes.

If none of these has happened yet, you have time to choose well. If one has, you still have paths — they're just more expensive in adrenaline.

Before anything else: the ninety-minute insurance policy

Whatever path you pick later, do this today. It requires no consultant and no budget:

• Copy the .mdb/.accdb file somewhere off that machine. Then do it

again tomorrow. Then automate it (even a scheduled robocopy to a NAS and a cloud drive is fine). Verify a copy actually opens.

• Image the whole PC (Macrium, Clonezilla, anything). The application

is not just the file — it's that machine's exact Office version, drivers, and mapped drives. A disk image turns "the PC died" from a crisis into an errand.

• Write down the folklore while the person who knows it is available:

what gets entered where, which reports get printed, what never gets touched and why. One page. It will be worth more than the file.

That's it. You've converted a total-loss scenario into a recoverable one. Now you can choose a path calmly.

Path 1 — Stabilize in place

What it is: keep the system, remove the risk. Virtualize the machine so it runs as a file you can copy, put real backups around it, split the database (Access supports a front-end/back-end split) so multiple users stop corrupting each other, and document it.

When it's right: the system still fits the business, order volume is stable, and the pain is fear, not friction. A shop doing the same mix it did in 2015 does not need new software; it needs the risk taken out of the old software.

What it costs: days, not months. Some of it is genuinely DIY (the section above is half of it). An IT generalist can do the virtualization; you don't need a manufacturing-software specialist.

The honest limit: stabilizing buys years, not decades, and it buys zero new capability. If the business is changing — new product lines, more users, customers demanding portals or EDI — path 1 is a foundation for path 2 or 3, not an alternative.

Path 2 — Move to an off-the-shelf shop system

What it is: JobBOSS2, ProShop, Fulcrum, Realtrac, and their cousins. Real products, actively developed, with support desks.

When it's right: your shop's workflow is close to the industry's standard shape — quote, route, schedule, ship, invoice, nothing exotic — and you have the appetite for a migration project. For many shops this is genuinely the correct answer, and any consultant who never says so is selling you something.

What it costs: typically in the tens of thousands for a ~20-user shop in year one, then subscription forever. But the money is the small cost. The real costs are: your history (twenty years of orders and pricing rarely migrate cleanly — most shops import customers and open orders and abandon the rest), your customizations (that pricing logic somebody tuned for a decade becomes "not supported"), and the workflow tax (the product's shape wins arguments with your shop's shape; you adapt to it, not the reverse).

The honest limit: if your Access system survived twenty years, it's usually because your shop doesn't quite fit the standard shape. Ask the vendor to demo your weirdest workflow, not their happy path, before you sign anything.

Path 3 — Rescue and rebuild, incrementally

What it is: treat the old system as a specification written in data. Recover everything it knows — the schema, the records, the pricing logic buried in queries and code — and rebuild it as modern software, one piece at a time, while the old system keeps running. Replace the piece that hurts most first (usually order entry or pricing), run the two side by side, and cut over only when the new piece has earned it. Verify the rebuild by replaying history through it: if the new pricing engine can reproduce what you actually charged for the last decade, it's right; if it can't, you found a bug before it cost you money.

When it's right: the system encodes how your shop actually works and that fit is worth keeping; you want to own the result instead of renting it; or the off-the-shelf demos all broke on your weird workflow. Also: when the thing is actively failing — this path is the only one built around "production never stops."

What it costs: done in fixed-price increments, a typical rescue lands at or below what the off-the-shelf migration costs in year one — with the difference that you end up owning software shaped like your shop, with your full history intact, and no subscription. (Yes, this is the path we sell. That's exactly why it's listed third, after the two paths that don't involve us.)

The honest limit: you're taking on custom software, which means you need someone accountable for it long-term — a retainer, an in-house person, or the discipline that any competent engineer could pick it up. If nobody will own it, path 2's support desk is worth its subscription.

Choosing in one table

One last thing worth knowing: paths are not forever. The most common sequence we see is 1 → 3 — stabilize now, rescue when the business demands it. The worst sequence is the one chosen by a dead hard drive.