There are two bad answers to this question and both are common.
The first is that spreadsheets are unprofessional and everything should be in a proper system. This is usually said by someone selling a proper system, and it is wrong: a spreadsheet is flexible, universally understood, and free, which makes it the correct tool for a very large range of problems.
The second is that the spreadsheet is fine because it has always worked. This is usually said the year before it stops working.
Here is the actual test.
The six questions
Answer honestly. Each "yes" is a point.
1. Does more than one person need to change it at the same time? Concurrent editing is the single clearest signal. If people take turns, or email versions, or maintain "their" copy, the spreadsheet is already failing at something a system does for free.
2. Does it need to enforce a rule? A spreadsheet will accept anything. If it matters that a date cannot be in the past, or a status must be one of four values, or a total must reconcile, you are relying on discipline where a system would rely on a constraint.
3. Does anyone need to see only part of it? Row-level access is the thing spreadsheets fundamentally cannot do. If the answer to "can they see everyone's numbers?" is "well, they shouldn't", you have a problem that no amount of hidden columns solves.
4. Is there a history you would need to reconstruct?
Who changed that figure, when, and what was it before? A spreadsheet's answer
is a file called final_v7_ACTUAL.xlsx.
5. Is it feeding something else? The moment a spreadsheet is an input to a report, an invoice run, or another spreadsheet, its errors stop being local. A wrong cell used to be a wrong cell; now it is a wrong invoice.
6. Would losing it hurt? Not "would it be annoying". Would it genuinely damage the business? Because it sits on someone's drive, it is edited without review, and there is no test that would catch a broken formula.
Reading the score
Zero to one. Keep the spreadsheet. Genuinely. It is doing its job and replacing it would cost more than it returns. Spend the money on something else.
Two to three. The spreadsheet is under strain but it is not the emergency. The cheapest useful move is usually to fix the spreadsheet rather than replace it: add validation, lock the formula cells, split the data from the presentation, document what it does. That buys years.
Four or more. It has outgrown itself, and the failure — when it comes — will not be gradual. It will be a wrong number in front of a client, or a person leaving, or a file that will not open. At four or more, the question is no longer whether to move, it is how to move without a six-month project.
How to move without a six-month project
The instinct is to replace everything at once. Resist it — that is what makes these projects fail.
The pattern that works: keep the spreadsheet as the interface and move the data underneath it first. People carry on working the way they always have while the data lands somewhere with rules, history and access control. Then replace the front end when there is something worth replacing it with, one piece at a time.
Nobody has to learn anything new on the day the risk goes away. That is the whole trick.