Not a feeling - five signs you can check: concurrent editing, a value in two places, no change history, a sheet nobody dares touch, and automations that keep breaking.
Key takeaways
- Size is not the sign; behaviour is.
- Two people overwriting each other is the first and clearest sign.
- A value living in two places and diverging is already a tooling problem, not a tidiness one.
- No answer to "who changed this and when" is a third, independent sign.
- A sheet nobody dares touch is an operational risk even while it works perfectly.
The question is usually asked as a feeling - "we are outgrowing the spreadsheet" - and that is the worst way to decide, because sometimes the problem is the structure rather than the tool. There are five signs you can check in twenty minutes, and all of them are binary: either they exist or they do not.
The five signs
| The sign | How to check | What it means |
|---|---|---|
| Concurrent editing | Two people working together at a busy hour | Permissions and locking are needed |
| Duplicated data | The same customer in two tabs | One source of truth is needed |
| No history | Ask who changed a row last month | Change tracking is needed |
| Fear of touching | Ask who is willing to edit a formula | Knowledge locked in one person |
| Repeated breakage | How many times something broke this month | The structure no longer holds |
Three or more of the five is usually the answer. One sign is generally solved by tidying, as covered in fixing your spreadsheet before buying software, and two depends on the case.
Sign 1: two people in the same sheet
This is the easiest sign to check and the sharpest. When two people work simultaneously at a busy hour, one of two things happens: somebody writes over a row the other is editing, or somebody waits. Both cost money, and the second costs more.
Shared editing in Google Sheets works technically, but it does not prevent a logical conflict - two people updating the same status from different places produce a state where the last one won, with nobody knowing. A system has record-level locking, and that is the real gap.
Sign 2: the same value in two places
This is the easiest sign to miss, because it looks like convenience: one tab for customers, one for orders, and the customer name and phone in both. The moment one changes, the other stays - and within two months nobody can tell which is right.
The spreadsheet solution is a lookup by identifier rather than duplication, and that works up to a certain size. Beyond it, what is needed is a structure where a value exists exactly once, which is the definition of a database.
Sign 3: no answer to "who changed this"
Version history in Google Sheets exists and is useful for recovery, but it is not operational record-keeping: it is hard to search, it does not say why, and in an active sheet it floods technical changes alongside meaningful ones.
The deciding question is whether anyone needs to know who changed what. In a business where a particular value affects a payment, stock or a commitment to a customer, the answer is yes - and that requires a system recording events rather than only current state.
Sign 4: the sheet nobody touches
Every business running on spreadsheets for years has one everybody is afraid of: it works, nobody fully understands how, and its formulas were built by somebody who may no longer be there. That is an operational risk even while it performs perfectly.
The practical test: ask who is willing to change a formula in it. If there is no volunteer, the knowledge is locked, and the risk and the way out are covered in single-owner spreadsheet knowledge transfer.
Why three signs and not one
A single sign can almost always be fixed within the spreadsheet, which is why it is not enough to justify replacement. Concurrent editing alone is sometimes solved by splitting tabs per person; duplicated data alone is solved by a lookup on an identifier.
What changes things is accumulation. When three signs hold together, every fix to one makes another worse: splitting into tabs solves the collision and increases duplication, and adding linking formulas solves the duplication and increases fragility. That is the moment when the structure of the spreadsheet itself is the constraint.
The practical test: try fixing one sign and see whether something else got worse. If it did, this is not a tidiness problem.
Sign 5: what depends on the sheet keeps breaking
Once a sheet becomes the source for a form, a report or an automation, every structural change breaks something downstream - usually silently. A business experiencing that more than once a month is already paying the price of a system, just in the form of faults.
It is worth measuring simply: how many times this month somebody said "the report did not arrive" or "the form did not save". Three or more is data, not a feeling.
What does not mean it is time
Three things sound like signs and are not:
- Row count alone - a sheet with 30,000 flat rows works fine.
- The number of tabs - five well-organised tabs are not a problem.
- Somebody proposed a system - a proposal is not a finding.
- The business grew - growth changes volume, not necessarily structure.
- A new employee struggled - that usually signals missing documentation, not the wrong tool.
The last one confuses many businesses. An employee who cannot find their way around a sheet is evidence of no written explanation, and that is solved by one page rather than a purchase. If they still get stuck after the page, that is a real sign.
What do you do once you decide to move?
Do not move everything. A sensible migration takes what is an operational source of truth - customers, orders, documents - and leaves in the spreadsheet what a spreadsheet does well: analysis, scenarios and one-off calculation. Businesses that try to move the analysis too end up asking the system for reports they would have built in five minutes.
There is one step before migration that always pays: clean up. Exporting a messy sheet into a new system produces a messy system from day one, and that is one of the common reasons a migration does not feel like an improvement. The full logic is in migrating data from Excel to a CRM.
Sources
Frequently asked questions
How many rows is the limit?
There is no single number. Google Sheets has a technical cap on cells per file, but in most businesses fatigue arrives long before the technical limit - from heavy formulas, cross-file links and too many tabs, not from the row count itself.
Can you keep the sheet with a database behind it?
That is a real and legitimate middle state: the sheet stays as an interface, and the data sits elsewhere. It solves signs 2 and 3 and does not solve sign 4, so it suits mainly where the team is attached to the sheet and there is no wish to change behaviour.
How long does a migration take?
It depends on cleanup more than on rollout. In a small business with clean data it is weeks; with messy data it is usually the same project plus a month of cleaning.
Is a system always better?
No. There are businesses where three well-structured sheets hold for years, and that is the right answer. What cannot be left in a spreadsheet is a state where nobody knows which value is correct - there the cost is not inconvenience but errors in front of customers.
Keep reading
Related service
Business Automation
I build custom automations that remove repetitive work end to end.
About the author
Yehonatan Saadia
Freelance automation, web & MVP developer
I'm Yehonatan Saadia, a senior developer who builds business automation, custom websites, and MVPs for small and mid-sized companies across the US, Europe, and Israel. These guides come from real client work, not theory.
Work with meHave a project like this?
Tell me what you're trying to automate or build and I'll tell you the fastest reliable way to ship it.