Somewhere in your business there is a spreadsheet that matters far more than it should. It allocates work, calculates fees, tracks compliance deadlines, or holds the client list. It has grown for years. One or two people really understand it. Everyone else trusts it because there's no alternative.
Here's the reframe that makes the next decision easier: that spreadsheet is not a stopgap before you have a system. It is a system. It has a data model (implicit), business logic (in formulas nobody dares touch), access control (whoever has the file), an audit trail (none), and a disaster-recovery plan (a person called Sue).
Judge it as a system
Once you see it as a system, you can judge it the way you'd judge any system that runs something important. Who can change the logic, and would you know if they did? What happens when two people edit at once? Where does personal data sit, and who can copy it? If the file corrupted this afternoon, how much of today would you lose, and how would you prove what it said yesterday?
For most businesses the honest answers are uncomfortable. That discomfort is useful. It converts the vague ambition to 'digitise' into a concrete engineering brief: keep the process the team knows, replace the properties that are quietly dangerous.
What replacement actually looks like
The good news is that replacing a spreadsheet-system is one of the highest-return engineering projects there is, because the requirements already exist: they're encoded in the sheet and in the heads of the people who run it. Discovery is archaeology, not invention.
The mistake is to treat it as a transcription exercise. The spreadsheet also encodes workarounds, dead columns and exceptions that stopped mattering in 2019. Build those in and you've paid for software that ossifies the mess. This is why we start inside the process, not inside the file.