The uncomfortable part is not that number. It is a separate finding from the same body of research: when Panko and Sprague compared error rates across undergraduates, MBA students with no spreadsheet experience, and MBA students with more than two hundred fifty hours of spreadsheet development experience, they found no significant difference.
Being careful does not help. Being experienced does not help. The tool has no safety net, and human attention is not one.
This is not an argument against spreadsheets
Spreadsheets are the best tool ever built for thinking about numbers. They are fast, flexible, and free of the assumptions a purpose built application forces on you. For a business figuring out what its process even is, that flexibility is exactly right.
The problem is never starting in a spreadsheet. The problem is staying there past the point where the spreadsheet stopped being the right container, which almost always happens quietly and without a decision.
A spreadsheet is a great place to work out what your process is. It is a poor place to run that process once you know.
The six signals
You do not need a rule about company size or revenue. You need to notice these.
1. More than one person edits it. This is the clearest signal and the most commonly ignored. The moment two people can change the same file, you have version conflicts, overwritten work, and no way to know who changed what. Shared cloud spreadsheets soften this but do not solve it, because they still allow anyone to delete a column.
2. You have started naming files with dates. Final. Final v2. Final v2 REAL. Inventory March updated. If your file names contain version information, the spreadsheet has outgrown itself and you are doing manual version control badly.
3. Something else depends on it being correct. When a spreadsheet feeds your invoicing, your ordering, or your payroll, an undetected error stops being an inconvenience and becomes money. This is where the ninety four percent figure starts to matter.
4. You are retyping the same data somewhere else. Copying customer details from a spreadsheet into an invoice, or from a form into a tracker. Every retype is both an error opportunity and a signal that two systems should be connected.
5. You need to know what changed and when. Spreadsheets have limited history and no real audit trail. If a question like "when did we change this price" or "who marked this paid" cannot be answered, the tool is wrong for the job.
6. It is slow to open. Not a small thing. A file that takes twenty seconds to load is one people avoid updating, and a tracker nobody updates is worse than no tracker, because it is confidently wrong.
Two or more of those signals together and it is time. One on its own is usually survivable.
What to move first
Not everything at once. Order by damage if wrong.
- 01Anything touching money moves first. Invoicing, payments, payroll
- 02Customer records second, because you lose relationships along with data
- 03Inventory or scheduling third, if you have either
- 04Project or task tracking fourth
- 05Reporting and analysis last, and possibly never
That last one is deliberate. Reporting is where spreadsheets remain genuinely superior. Pull clean data out of a real system and analyze it in a spreadsheet. That is the correct division of labor, not a failure to migrate.
Ask what happens if this file is deleted right now with no backup. If the answer is "I lose an afternoon of work," stay in the spreadsheet. If the answer is "I do not know who owes me money," you needed to move six months ago. The cost of moving never goes down, because the data only accumulates.
What you gain, stated honestly
A purpose built tool is not better at everything. It is better at four specific things.
- Validation. A field that only accepts a date will not accept "next Tuesday"
- Concurrency. Two people can work at once without overwriting the work of the other
- History. You can see who changed what and when
- Connection. It can talk to your other systems without a human retyping
And it is worse at three things worth admitting. It is less flexible, so a process change may require configuration rather than a new column. It costs money every month. And it imposes assumptions someone else made about how your business works, which occasionally will not fit.
The trade is real. It is worth making once the six signals appear, and not especially worth making before.
How to move without losing anything
The migration is where this goes wrong, and it goes wrong the same way every time.
- 01Clean the data before you move it. Inconsistent formats, duplicate records, and blank required fields will all follow you
- 02Decide what you genuinely need to bring. Old records that will never be referenced can be archived rather than migrated
- 03Map every column to a field in the new system before importing anything
- 04Import a sample of twenty records first and check them by hand
- 05Run both systems in parallel for two weeks. This is the step people skip and the one that catches everything
- 06Pick a cutover date, announce it, and make the spreadsheet read only that day
- 07Keep the final spreadsheet export permanently as an archive
Step five is not optional. Parallel running is how you discover that the new system rounds differently, or that a field you assumed was optional is required, or that your Tuesday process has no equivalent yet.
Where spreadsheets stay
To be clear about what should not move, because the temptation after a migration is to buy software for everything.
Modeling and forecasting. One off analysis. Anything you will do once and discard. Quick calculations. Pulling data out of a real system to answer a specific question. Prototyping a process before you know what it is.
All of those are spreadsheet work and always will be. The distinction is between thinking and operating. Spreadsheets are for thinking.
The version that fits a first year business
If you are early enough that this all sounds premature, the useful version is short.
Run your operations in a spreadsheet deliberately, knowing it is temporary. Structure it as though it were a database, with one row per record and one thing per column, because that makes the eventual export clean. Do not merge cells. Do not use color as data. Back it up somewhere automatic.
Then watch for the six signals. When two of them appear, move, and move the money first.
The businesses that get hurt are not the ones that used spreadsheets too long. They are the ones that never noticed they had crossed the line, and found out when a number was wrong and there was no way to tell how long it had been wrong for.