How do I turn my spreadsheet into a real system?

Question

VX-N · Accepted Answer

Identify what the spreadsheet is actually doing — usually a mix of database, workflow, and reporting — and replace those jobs separately. The spreadsheet is rarely the problem; the problem is that it is the only place the truth lives and only one person understands it. Warning signs it is time: two people cannot edit it at once, someone maintains a 'master' copy, formulas break when a row moves, or the business would genuinely stop if that file were lost. Add one more: when the spreadsheet has started to enforce process — cells people know not to touch, colors that mean something, a tab order that encodes how work flows — it has become software, just software with no permissions, no history, and no backup discipline. Decompose the jobs before replacing anything. The rows are a database: they become tables with defined fields, types, and one record per real-world thing. The formulas and the manual copying between tabs are workflow: they become triggers and rules that run without anyone remembering. The summary tabs are reporting: they become views over live data instead of snapshots someone rebuilds every Monday. Trying to replace all three with one monolithic 'app' is how these projects sprawl; replacing them as separate jobs keeps each piece small. The logic buried in the file is the part everyone underestimates. Years of edge cases live in nested formulas, in conditional formatting, and in the head of whoever maintains it — the customer that is billed differently, the column that means something else before 2024. Sit with the spreadsheet's owner and walk through the weird rows before designing anything, because every one of those exceptions is a requirement, and the ones you miss surface as bugs after launch when trust is most fragile. The migration nobody plans for is history. Decide early what past data has to come across and in what shape, because that is usually the expensive half of the job. Old rows are inconsistent — freetext where the new system wants a category, three spellings of the same customer, dates in two formats — and cleaning them is real work. The pragmatic call is often to migrate recent history fully, archive the rest read-only, and resist the urge to perfect five-year-old records nobody will query. Cut over deliberately: run the new system in parallel for a short, fixed window, reconcile the numbers, then freeze the spreadsheet read-only rather than deleting it. The freeze matters — as long as the old file stays editable, it stays the real system, and you end up maintaining both. A system like this is well inside the class of work that AI-era delivery ships in days or weeks, so the parallel-run window can be short.