Let’s start with the unfashionable truth: a spreadsheet QMS is not a mistake. For a ten-person shop pursuing first certification, a well-kept document register, an NCR log, and a training matrix in spreadsheets can absolutely pass an audit; we’ve built systems exactly like that for clients, on purpose. Spreadsheets are free, universally understood, and infinitely flexible.
The problem is that every strength on that list becomes a liability at scale, and the transition is gradual enough that most teams don’t notice the moment the tools became the bottleneck. Here are the signals, in roughly the order they tend to appear.
1. The register and reality disagree
The first sign is always version drift: the document register says Rev C, the floor copy says Rev B, and the file in the shared drive is an unlabeled draft of Rev D. A register maintained by hand is a description of your document control, updated when someone remembers. Once the description and the reality diverge, and someone other than the quality manager notices, you’ve crossed the line. This is also the single most common source of external audit findings, because it’s the first thing auditors check.
2. One person is the quality system
Ask who knows how the NCR log’s status columns actually work, where the calibration tracker lives, and which copy of the training matrix is real. If every answer is the same name, your QMS has a bus factor of one. Spreadsheet systems accrete conventions (color codes, hidden columns, “don’t sort by column F”) that live in one person’s head. When that person is on vacation during a customer audit, the system effectively doesn’t exist.
3. Audit prep takes weeks
A system of record produces evidence as a byproduct of work. A spreadsheet system produces evidence through reconstruction: reconciling registers, chasing missing sign-offs, hunting certificates through email. If audit preparation is a named project with a start date, you’re paying an evidence-retrieval tax in concentrated installments: typically one to two working weeks per audit cycle, twice a year. That cost is real money and it buys nothing; it’s pure friction between you and records you already own.
4. The same problem keeps coming back
This is the expensive one. Recurrence detection requires connecting today’s nonconformance with one logged eight months ago, by someone else, described in different words. Free-text spreadsheet rows make that connection essentially impossible, so every NCR arrives as if it were novel, root-cause investigations never trigger, and the same failure mode quietly ships to customers three times a year. If your team has ever said “wait, didn’t this happen before?” and couldn’t answer the question with data, the log has stopped being a quality tool and become a diary.
5. Training records lag document changes
A procedure gets revised. Who needed retraining, and did they get it before the next time they ran the process? In a spreadsheet system the answer depends on someone manually cross-referencing a revision log against a training matrix, so in practice the matrix updates in batches, weeks later, usually before an audit. The gap between “document changed” and “people trained on the change” is a nonconformance factory, and it’s invisible until an auditor (or an incident) finds someone working to a superseded revision.
6. Metrics require an archaeology project
Management review needs trends: NCRs by category over quarters, corrective action aging, first-pass yield, supplier performance. When the source data is scattered across workbooks with inconsistent categories, assembling those inputs takes days, so it happens quarterly at best, and decisions run on anecdote the rest of the year. The tell: management review slides that took longer to build than they take to present.
7. You’ve started building software in the spreadsheet
Macros to enforce dropdowns. Scripts that email overdue-action reminders. A “database” tab feeding lookups. Protected ranges to stop edits. Each one is reasonable; together they mean someone on your team is now the unpaid developer of an unversioned, untested, single-user QMS application. This is more fragile than either honest spreadsheets or real software, and when its author leaves, see sign #2.
What the signs have in common
None of these are discipline failures, and hiring a more meticulous quality manager won’t fix them. They’re all the same structural fact wearing different costumes: spreadsheets store rows, but a QMS is made of relationships. Documents to training, NCRs to corrective actions, findings to effectiveness checks, records to revisions. Manual systems ask humans to maintain those links by memory, and past a certain scale, humans lose.
When to move (and when not to)
If two or fewer signs feel familiar and your organization is small and stable, don’t rush; a lean, honest spreadsheet system beats a half-implemented software one. If four or more feel familiar, the migration will be cheaper than the next year of friction: the two-week audit prep, the recurring defect, the near-miss with the superseded work instruction.
One genuinely useful reframe for timing: migrate while the system is still healthy enough to migrate. The longer drift accumulates, the more cleanup precedes any import. Moving a QMS out of spreadsheets is not a months-long IT project. Done with import tooling and someone who knows how quality systems fit together, it’s measured in days. The expensive part is never the move. It’s the years of quiet friction before it.