Guide · business software
How do you replace a spreadsheet with software?
Before replacing it, you need to understand why it survived this long. Otherwise you deliver software that's stricter, slower to use, and abandoned.
To replace a spreadsheet with software, you first need to understand why it held on: its added columns, colour codes and notes are unwritten business rules that the software must carry over. Replacement is justified when the same data is entered twice, several versions circulate, or mistakes get costly. Otherwise, keeping the spreadsheet is sometimes the right call.
Why the spreadsheet wins
It never says no. You add a column, write a note in a cell, colour a row red to signal something no one has formalised. All this informal intelligence is what keeps the organisation running. Software, by design, says no. That's its value — it prevents errors — and its risk: if it says no to a legitimate case, the user will start another spreadsheet on the side. And you'll have two sources of truth instead of one.
The three warning signs
Three signs indicate it's time to replace the spreadsheet.
- Double entry: the same information is entered twice in two different tools — wasted time and a guaranteed mismatch
- Data you can no longer trust: no one knows which version of the file is authoritative any more, or a formula has been overwritten without anyone noticing
- No enforcement: the spreadsheet informs but prevents nothing; when safety or compliance information lives in a spreadsheet, the risk is no longer just administrative
What software must carry over from the spreadsheet
Software replacing a spreadsheet must carry over the columns added over time, each of which answers a real need that must be identified before removing it; the colour codes and writing conventions, which are unwritten business rules that scoping brings to light; the edge cases noted as comments, which hide the exceptions the software will have to handle rather than forbid; and the ability to export, failing which a user who can no longer get their data out will feel trapped — rightly so.
When you should keep the spreadsheet
Keep the spreadsheet when the process still changes every month, because formalising it too early costs more than it saves; when only one person uses it and they've mastered it, because the benefit of software is collective, not individual; and when there is no compliance stake, no double entry, and no data loss. In that case, replacing a tool that works is spending with no return, and we'll tell you so.
This guide describes a practice, not legal advice. Applicable obligations depend on your equipment, its use and your sector: check them with your inspection body or your legal counsel.
Frequently asked questions
Can the existing spreadsheet be imported directly?
Yes, and it's the starting point. We analyse it, produce a data quality report — duplicates, missing values, inconsistencies — you make the calls, then we import it. It's almost always the longest item in the project.
Will our users accept the change?
If they took part in the scoping, yes, because the software looks like their work. If it's imposed on them afterwards, no. That's why we scope with end users, not just with management.
What if the software is slower to fill in than the spreadsheet?
Then it's a design failure, not something to accept as inevitable. Data entry must be at least as fast, otherwise the tool will be worked around. It's a criterion we measure during the iterations.
A project, a question?
Describe what you need in a few lines: you deal directly with the team, in Lille.