Why We Kept a Spreadsheet After Buying a Database Tool

The team migrated 8,400 rows into a proper database tool and kept the spreadsheet for another fourteen months. The database held the truth and the spreadsheet held the argument, and neither replaced the other.

The company tracked supplier performance: delivery times, defect rates and price changes across 260 suppliers. One operations analyst had built the spreadsheet over four years and knew it better than any documentation.

Why the migration happened

The spreadsheet had 61 tabs, nine of which were the same report at different stages of a month. It took 40 minutes to recalculate after an import and had corrupted twice, both times recovered from a copy that was three days old.

The case for a database was straightforward and the migration was approved without much debate.

What the database improved

Recalculation time went from 40 minutes to under a second. Two analysts could work at once without producing conflicting copies. Row-level history meant a supplier’s delivery figure could be traced to the person who entered it and the date.

Those three improvements were real and they were the whole of the promised benefit.

Why the spreadsheet survived

Any question that had not been anticipated required a new view, and a new view required a query. The analyst could answer a novel question in a spreadsheet in four minutes by dragging a column, and in the database tool it took either a saved view request or her own half-remembered query syntax.

Nine weeks in, she was exporting to a spreadsheet to think, then typing answers back. That is the pattern that persisted.

The export habit

The tool exported cleanly, which was the reason the hybrid worked at all. A weekly export of the current figures became a scheduled job, and the analyst’s working file opened with the current data already in it.

Without a clean export the team would have abandoned the database, which is a design lesson the vendor never hears.

What the hybrid cost

Two artefacts need to be trusted and only one is authoritative. New joiners were told the database is the truth and the spreadsheet is a calculator, which is a sentence that takes a while to absorb.

One error arose from the distinction in fourteen months: a figure was corrected in the spreadsheet and not in the database, and a report ran from the database a week later.

The argument the spreadsheet was making

A spreadsheet shows its own structure. A formula is visible in the cell and the dependency is visible in the column. A database hides its structure behind an interface, which is better for consistency and worse for reasoning.

Analysts reason with structure, which is why the export survived longer than the migration plan anticipated.

What the team eventually changed

Fourteen months later the team built three saved views that covered the nine recurring questions, which removed most of the export need. The spreadsheet remained for exploratory work and was no longer used for reporting.

Building the views took eleven hours spread across a month, and it is the step the original migration plan had left out.

Where it settled

The database is the system of record and the spreadsheet is a scratchpad that resets every Monday. Two artefacts, one truth, and a clarified rule about which answers questions.

The question the tool could not answer quickly

Fourteen months in, a supplier disputed a defect rate and the analyst needed the original entry, the person who made it and the comment attached to it. The database held all three and took six minutes to surface them. The spreadsheet would have taken forty seconds, because the comment sat in the cell next to the number.

That is the honest case for keeping two artefacts: provenance is easier to read when it lives beside the value rather than behind a detail panel.

Eight thousand four hundred rows once lived in a file that took 40 minutes to recalculate. They now live in a database, and the spreadsheet that held them for four years still earns its place on a Monday morning.