Replacing the spreadsheet without replacing the people
A diagnostic look at when a spreadsheet is still the correct tool, the four signals that it has stopped working, and what a custom internal tool has to preserve so the team actually uses it.
Replace the spreadsheet only where it fails. Move into an app the parts that break when more than one person touches them: edits at the same time, permissions, change history, and anything typed twice because it lives in two systems. Keep the parts people invented themselves. The extra column, the color coding, the hidden helper tab, the notes cell used as a scratchpad. Strip those out and the spreadsheet comes back.
Key points
- A spreadsheet is usually right with one owner, small volume, and no two people editing at once. I have talked people out of replacing one.
- Signals that a spreadsheet has failed come from people and copies, not row counts.
- A replacement more rigid than the file it replaced loses to the file.
- Most internal tools fail on permissions, who can see and change what, not on features.
When is a spreadsheet exactly the right tool?
When one person owns it, the volume is small enough to scan, and the format changes as often as the work does. Under those conditions the file beats anything I would build. Adding a column takes four seconds. Adding a field to an app takes a conversation with me, a database change, and a new version pushed live. If the process is still being figured out, freezing it into software buys rigidity instead of time.
Some work stays in a spreadsheet permanently, even after the app exists: modeling next season, or sorting a one-off list somebody asked for on a Tuesday. When I move a client off a spreadsheet, I assume they will still pull data into one to think with. I build the export accordingly.
What are the signals a spreadsheet has stopped working?
There are four. The first is two people editing at once. Somebody has the file open, somebody else gets the read-only warning, and work waits or gets lost. Cloud spreadsheets soften that without solving it. Two people can still overwrite each other's intent in cells that merge cleanly.
The second is versions traveling by email. Once an attachment named something like schedule_v4_final_JT.xlsx circulates, the true record is whichever copy someone opened last. I have watched an office reconcile two of these by hand and call it a normal Monday.
The third is the formula nobody dares touch. It was written by someone who left, it pulls from a hidden sheet, and everyone has agreed not to look at it. That formula is a rule the company runs on. It deserves a name, a test, and a place someone can read it.
The fourth is the same information typed into more than one system. The same customer gets entered in the file, the accounting software, and a scheduling tool. Within a month the three disagree about a phone number. That is the signal I take most seriously. The cost is quiet, and it compounds.
No single signal settles it, and row count almost never does. What settles it is how many people the file serves, and what a wrong number costs when it escapes.
Where does the line fall?
| What the file is doing | Better as a spreadsheet | Better as an app |
|---|---|---|
| One person's working scratchpad | Yes | No |
| Modeling a scenario before a decision | Yes | No |
| A record several people edit in the same week | No | Yes |
| A record an outside party has to see | No | Yes |
| Numbers that must agree with another system | No | Yes |
| Fields that change shape every month | Yes, until they settle | Later |
What should a replacement preserve?
The flexibility people actually use, which is narrower than it looks:
- A notes field that accepts any text, with nothing checking it.
- Custom fields or tags staff can add without calling me.
- Saved filters matching how each person already sorts.
- Fast keyboard entry instead of a five-screen wizard.
- A draft state, so a record can sit incomplete without complaint.
Export matters more than people expect. A spreadsheet moved into a database still gets a view that hands a spreadsheet back. GrantCue does this on the post-award side, where line-item budgets, disbursements, and compliance requirements all export to Excel. The finance person has a workflow and my opinion about it is irrelevant.
Then there is what a spreadsheet was never going to do. I run a back office for my own work as a registered Pennsylvania home improvement contractor (PA HIC #PA2199962). Projects carry photo galleries and a document builder for estimates, invoices, and proposals. Each document gets a share link, a private web address the homeowner opens without an account. I write real estimates in it. That share link justifies a move like this. No version of the spreadsheet gets you there.
Permissions are the other half. On Volunteer Clinton County, the platform I co-founded and developed, all the tables sit in one walled-off Postgres schema. Access runs on row-level security, a per-record rule about who sees what. Organizations have a four-level membership hierarchy, and the database enforces the submission workflow, so no screen or API call can quietly skip a step.
A five-person office does not need that machinery. It needs the same principle: who can see a record and who can change it gets decided in one place, not in whichever screen is open.
How the migration runs
Cleanup comes before automation, because automating a mess only produces the mess faster. I read the real file, including the tab everyone forgot about, and map the workflow as it runs rather than as the org chart describes it. That work is closer to data cleanup and automation than to app development. It often takes longer than the screens.
The first release gets cut narrow, usually to the one workflow costing someone a morning a week. The old spreadsheet stays readable until you sign off. Whoever built it belongs in the room for the mapping, because that file holds decisions nobody wrote down.
Common questions
Do we lose what is in the old file?
No. The original stays available until you confirm the new system holds the same records. Migration includes a cleanup pass on the data, the part nobody wants to do by hand. Anything the file tracked informally, like a status color or a margin note, becomes a real field so it survives the move.
What if the person who built the spreadsheet does not want to give it up?
Then I want them in the mapping early. They are usually the most informed person in the building. They know which columns are load-bearing and which are leftovers. If the new tool takes away the speed they had, they are right to resist. I treat that as a design problem on my end, not a training problem on theirs.
Can we replace part of it and leave the rest?
Yes, and that is often the better plan. Move the piece where several people collide. Leave the analysis and the one-off lists in a spreadsheet, and connect the two with an export. Scope is fixed per project, so a narrow first release is a real option and the next piece can wait for the next budget cycle.
Does it have to be a custom build?
No. Sometimes a shared database in an off-the-shelf tool covers it. Sometimes the answer is a shared drive plus one rule about who edits what. If that is where I land, that goes in the proposal. Custom earns its keep when permissions, outside access, or matching another system are the actual problem.
If your team has hit two or three of those failure signals, start at internal tools.
Need this kind of work for your organization?