Spreadsheets are the most successful end-user programming environment ever shipped, and every SME runs on them. That is not the problem. The problem is the moment a spreadsheet silently turns into a multi-user database with no locking, no audit trail, no schema, and no backups anyone has tested — and the business only notices when an order ships twice or a payroll figure is wrong.
In SME digitalization work, the question is never whether to use spreadsheets. It is which workloads have outgrown them. This post is about recognizing that line, choosing what to replace the sheet with, and migrating without a big-bang ERP project that stalls for a year and burns everyone's goodwill.
Signs you have crossed the line
- ▸More than two people edit the same file: concurrent editing in a spreadsheet is last-writer-wins with extra steps. Shared drives and sync clients make the race conditions worse, not better.
- ▸VLOOKUPs reach across files: congratulations, you have foreign keys. You also have joins that break silently when someone renames a tab.
- ▸Version-suffix chaos: when the folder contains final_v3 and final_v3_REAL, nobody can say which numbers the business actually acted on.
- ▸Humans re-key data between tools: that is an unbudgeted integration running on manual labor, with an error rate you are not measuring.
- ▸The sheet drives operations: if orders, stock levels, patient bookings, or salaries flow through it daily, it is a production system and deserves production discipline.
Failure modes worth naming precisely
Vague warnings do not move decision-makers; concrete mechanisms do. Concurrency: two people open the file, both save, one set of changes evaporates. Formula drift: a sort applied to half a range quietly decouples rows from their calculations. Type coercion: leading zeros vanish from phone numbers and identifiers, and date parsing mangles anything that resembles a date — the genetics community literally renamed genes because spreadsheet software kept converting their symbols to dates. Hard limits: the UK's COVID-19 case reporting famously dropped thousands of test results when a legacy XLS format hit its 65,536-row ceiling. Add the absence of referential integrity, of field-level access control, and of any audit trail, and you have described a system that would fail the most basic review if anyone called it software.
What to replace it with, honestly
There is no single answer; there are four options with different trade-offs.
- ▸Vertical SaaS: fastest path when the fit is good. Risks are workflow mismatch you discover in month three and per-seat pricing that compounds. Check the export and API story before signing anything — data you cannot get out is data you no longer own.
- ▸Open-source suites: Odoo and ERPNext cover CRM through inventory and accounting with mature data models. The trap is treating customization as configuration; it is a real software project. Either budget for that or adapt your process to the defaults.
- ▸Internal tool platforms: NocoDB, Baserow, or Appsmith give you a real database behind a spreadsheet-like interface. Excellent transitional step for teams that live in grids. Scrutinize authentication, role granularity, and the backup story before trusting them with operations.
- ▸A thin custom app: Postgres plus a small CRUD application wins when the workflow is genuinely unusual. Highest upfront cost, best long-term fit, and no license fees scaling with headcount.
The common thread across all four: a real database underneath, with types, constraints, transactions, roles, and restorable backups.
The migration playbook
1. Pick one workflow — the highest-friction one — not the whole company. Momentum beats scope. 2. Reverse-engineer the spreadsheet schema. Every column is data, derived, or dead. Derived columns become computed logic in the new system; dead ones get archived, not migrated. 3. Write down the validation rules the spreadsheet never enforced: required fields, formats, ranges, uniqueness. This document becomes your acceptance test. 4. Migrate history with a repeatable script that has a dry-run mode. Copy-paste migrations are neither reproducible nor auditable, and you will run the migration more than once. 5. Run old and new in parallel for a few weeks on real operations and diff the outputs. Discrepancies are requirements you missed, not user error. 6. Revoke write access on the sheet. Keep a read-only export for the attached; the point is exactly one writable source of truth.
Keep spreadsheets where they win
None of this is spreadsheet abolition. Ad-hoc analysis, one-off modeling, and what-if scenarios belong in a spreadsheet, and forcing them into a rigid app is a different failure. The discipline is directional: the system of record feeds the spreadsheet through clean CSV exports or a read API, never the reverse. Skip that, and people will screen-scrape or re-key, and the shadow database will quietly regrow.
A system of record does more than prevent incidents. Reliable stock counts are what make an e-commerce channel possible; clean customer history is what makes credit terms defensible; structured invoice data is what e-invoicing mandates will demand from SMEs anyway. Every workflow moved off a fragile sheet returns hours to the team and unlocks an integration that was previously unthinkable. For most SMEs, digital transformation is exactly this unglamorous: one workflow at a time, compounding quarter after quarter.