Denshin / Blog / Process
Replacing a spreadsheet workflow without starting a revolt
The software is rarely why a spreadsheet replacement fails. A few habits that get a team to actually let go of the shared sheet: watch first, keep the export, import the history, run both for one cycle.
Denshin Team · Product & Engineering · 19 October 2026 · 3 min read
Some of the most useful software we build replaces a spreadsheet. A sales enquiry tracker at a manufacturer, a job sheet at a service company, a booking register that three people edit at once and one person quietly fixes every Friday. The business has outgrown it, everyone agrees it has to go, and then the new system launches and the team keeps using the spreadsheet anyway.
We have seen enough of these to know the pattern. The software was fine. The replacement failed because it treated the spreadsheet as a mess to be cleaned up, when the spreadsheet was actually a record of how the business works.
A spreadsheet that has been in daily use for a few years is full of rules nobody wrote down. The colour coding means something. The column with the cryptic header is how the accounts team knows which orders to chase. The row that says "DO NOT DELETE" exists because someone once deleted it. Before designing a single screen, we sit with the people who use the sheet and watch them work. Not a requirements meeting, just watching. You learn more from an hour of someone saying "oh, I just do this bit by hand" than from a week of workshops.
Then there is the column someone uses for their own notes. Every shared sheet has one. It is not in any process document, the manager does not know about it, and it is the thing that person depends on most. Take it away and you have made an enemy of the person whose cooperation you most need. We now ask about it directly, and usually the answer is a free-text notes field on the record, which costs almost nothing to build.
Keep the export. The first question after any spreadsheet replacement is "can I still get it into Excel?", and the answer should be yes, from every list, on day one. People use spreadsheets for things you will never anticipate: a pivot for the monthly review, a mail merge, a quick filter before a phone call. Taking that away makes the new system feel like a downgrade, even if everything else is better. An export button is cheap and it heads off a lot of resentment.
Bring the history across. A new system that starts empty forces people to keep the old sheet open "for reference", and once it is open, it gets edited. Importing a few years of rows is tedious, mostly because of the inconsistencies: dates typed three ways, a customer spelled four ways, merged cells. It is still worth doing, and doing it surfaces the hidden rules you missed while watching.
Run both for one cycle. Whatever the natural rhythm of the work is, a week, a month, a billing period, run the old and the new side by side for one full cycle and compare the outputs. Where they disagree, one of them has a bug, and it is not always the new one. Then pick a date, make the sheet read-only, and say so clearly. A sheet that stays editable after launch never dies.
Give the person who maintained the spreadsheet an admin panel. Usually one person owned the sheet: they added the dropdown options, fixed the broken formulas and cleaned up after everyone else. If the new system needs a developer to add a product category, you have taken power away from the person who knew the most, and they will notice. This is a big part of why we always ship the admin panel with the product.
None of this is technical. The code for a tracker that replaces a spreadsheet is usually the easy part. The hard part is respecting that a group of people built a working system out of rows and columns, and that the new one has to earn its place.
Tags: Spreadsheets, Change Management, Internal Tools, Product
All posts · Work with Denshin