Almost every growing business has one: a spreadsheet, or a Microsoft Access database, that someone built years ago to track something — orders, inventory, client records, scheduling — that has quietly become the system the whole company runs on. Nobody sat down and decided it would be the system of record. It just never stopped being the thing everyone added one more column, one more tab, one more query to.
None of what follows is an argument that spreadsheets or Access are bad tools. For one person tracking one thing, they're excellent — fast to build, flexible, and nobody has to wait on IT to add a column. The problem isn't the tool. It's that the tool was never designed to do what it's now being asked to do: hold the business's real data, safely, while more than one person touches it.
It worked, because it was really only ever one person's job
When one person owns the file, none of its weaknesses ever show up. There's only one mental model of what each column means, because there's only one person who ever had to build that model. There's no risk of two people saving conflicting versions, because there's only ever one person saving. There's no need for permissions, because there's only one person to grant them to. The spreadsheet isn't fragile in that world — it just has never had to survive the thing that's happening now: more than one person depending on it at the same time, none of them able to see what the others are doing to it.
The cost nobody puts on the spreadsheet: typing the same thing twice
Before getting into what breaks, it's worth naming the cost that's usually bigger than anything breaking outright: copying. A typical order might travel like this — a customer submits it on the website, an employee gets an email, copies the details into a spreadsheet, emails the warehouse, copies the tracking number back into the spreadsheet once it ships, updates the customer, and then re-enters the whole thing into QuickBooks so accounting has it too. None of that is anyone's mistake. It's just what happens when the systems around the business don't talk to each other and a spreadsheet is the thing gluing them together by hand.
Put a number on it and it stops being an abstract complaint. If three employees spend even ten hours a week on that kind of copying — a conservative estimate once every system it touches is counted — that's 1,560 employee-hours a year spent moving data that already exists somewhere else into another place it needs to exist too. That's not a problem a better spreadsheet fixes. It's labor cost hiding inside a process nobody ever actually sat down and designed.
Where a shared file stops being the right foundation
Access can support more than one user. A properly split application — a front end on each person's machine, a shared back-end file on the network — can work fine for a small team, and it's not fair to call Access a single-user tool. The real question isn't whether Access can technically be shared. It's whether a file-based database is still the right foundation once the business depends on it: more concurrent users, less reliable networks (remote work, VPNs, synced folders), more data, more integrations with other systems, real permission requirements, an actual audit trail, and a backup-and-recovery plan that isn't "hope the file didn't corrupt." Each of those pushes harder against what a shared file was ever designed to absorb.
Access does have a hard ceiling — a 2GB limit per file — but the more common failure isn't hitting that wall. It's everything that makes the file fragile well before anyone gets close to it: a folder synced by Dropbox or OneDrive that wasn't built to understand database file locking, and will happily create a second, conflicting copy mid-save; a remote worker on a slow connection holding a lock longer than expected; queries that were fine on last year's data volume and aren't anymore because nobody revisited the indexes as the table grew. None of that means Access is badly built. It means a shared file was never the layer meant to absorb that much change.
The question isn't whether Access can be shared. It's how much is riding on it by the time sharing it stops being enough.
Spreadsheets don't remember anything that counts as an answer
Modern spreadsheets aren't as memoryless as they used to be — Google Sheets and Microsoft 365 both keep version history, and collaborative editing shows who's in the file right now. But version history isn't the same thing as an audit trail. Knowing a cell changed at 2:37 p.m. isn't the same as a system that records what happened in terms the business actually cares about: Order 12457 changed from Pending to Shipped, by Joseph Rounds, at 2:37 p.m., tracking number 12345. One of those is a technical log buried in a menu nobody opens. The other is how you actually answer "why does this order say something different than it did yesterday" six months from now.
Version history also doesn't stop the mistake from happening — it just gives you a chance to notice after the fact, if anyone thinks to look. Here's the ordinary version of how that goes wrong: someone sorts a range by date to reorder a list, forgets to select the rest of the row along with it, and every customer's order total is now attached to a different customer's name. Nothing in the spreadsheet objects, because a spreadsheet has no idea what a "row" is supposed to mean. It just has cells.
That's the real change-management problem, and it has nothing to do with anyone being careless. With a system built around what the data actually represents, a bad change is a mistake someone can find, explain, and reverse, because the system knows what changed and when. With a spreadsheet, a bad change is just the new truth, silently, until someone notices the numbers don't add up — and by then it might be weeks of decisions made on data that was already wrong.
A spreadsheet doesn't know what a row means. Only the person editing it does.
Signs you've actually outgrown it
Not every spreadsheet needs replacing. These are the signs that the file itself, not the people using it, has become the risk:
Signs you've outgrown the spreadsheet
- More than one or two people edit it regularly.
- You've had a "wait, who changed this?" moment nobody could actually answer.
- It has ever failed to open, shown a "locked by another user" message, or needed to be repaired.
- Nobody can say how many rows or records it holds without opening it and counting.
- The same information gets typed into more than one system.
- Employees regularly export a CSV from one system just to import it into another.
- A new hire needs a verbal walkthrough just to understand what the columns mean.
- One employee has become the only person who actually understands how the process works.
- Losing this file tomorrow would take down a real part of the business, not just cause an inconvenience.
One or two of these are a nuisance. Three or more, and the file has quietly become infrastructure — it's just infrastructure nobody ever designed to hold weight. The one about being the only person who understands it is worth sitting with on its own: that's not a spreadsheet problem, it's a single point of failure with a name and a vacation schedule.
What should actually replace it depends on what's really broken
Not every business that's outgrown a spreadsheet needs custom software, and it's worth being honest about that before recommending it. There are really four honest answers, and the right one depends on what's actually broken.
Four honest answers to "what should replace it"
- Keep the spreadsheet. If one or two people use it, it's never caused a real incident, and nothing critical depends on it surviving unattended, the process hasn't actually outgrown the tool yet.
- Move to an existing platform. A CRM, a warehouse system, a project-management tool, or accounting software built for the job is usually cheaper and faster to adopt than building something new, when one already fits.
- Integrate what you already have. Sometimes the spreadsheet isn't the real problem — it's that the systems around it don't talk to each other, and the spreadsheet is just the thing gluing them together by hand.
- Build something focused. When the workflow is specific enough that no off-the-shelf tool actually fits it, a narrow, purpose-built application is worth the investment — not a rebuild of everything, just the one piece that's genuinely unique.
That third path is the one people underestimate. Take the order flow from earlier: a customer places an order, an employee receives it by email, copies it into a spreadsheet, emails the warehouse, copies the tracking number back in once it ships, and re-enters the whole thing into accounting. Connect the order system, the warehouse, shipping, and accounting directly — even with something as unglamorous as a webhook and an API call — and the same order moves through on its own, with the spreadsheet gone from the middle of it. Sometimes replacing the spreadsheet doesn't mean replacing everything around it. It means removing the spreadsheet from the middle.
When the honest answer is the fourth path, we've written before about when Boston businesses should choose custom software over off-the-shelf tools — the same principle applies directly here: the best first project is narrow, one workflow, one bottleneck, not a rebuild of everything at once.
Where this leaves you
A spreadsheet or an Access file was never the wrong choice — it was the right choice for a business with one person and one file. The tool didn't get worse. The business outgrew the one condition that made it safe: a single person, making changes nobody else could collide with, with nothing important enough riding on it to need a record of what happened. What actually replaces it depends on what's really broken — sometimes that's an existing platform, sometimes it's connecting the systems you already have, and sometimes it's a narrow piece of custom software built around the one workflow nothing else fits. If you're not sure which one you're looking at, tell us what it's holding together and we'll help you figure out which of those is actually the right next step, before you spend money solving the wrong problem.