How to move from spreadsheets to a database

Move off a spreadsheet when the same data starts being copied into several sheets, when two people editing at once causes real problems, or when you need history — who changed what and when. Until then a spreadsheet is the right tool, and switching early costs more than it saves.

The migration itself is straightforward: clean the sheet so one row is one thing, export to CSV, import it into a structured tool, then set the field types and relationships. The work is in the cleaning, not the moving.

Signs you have outgrown the sheet

• The same fact lives in several places, and they disagree.
• Formulas break when someone inserts a row, and nobody is sure which sheet is authoritative.
• You need to know who changed a value, and the sheet cannot tell you.
• Different people should see different things, and the sheet is all-or-nothing.
• There are so many tabs that finding anything requires a search.

The steps

1. Decide what one row represents — one customer, one order, one asset — and make the sheet obey that rule before anything else.
2. Split combined columns: full name into first and last, address into its parts, anything holding two facts in one cell.
3. Standardise the values that will become options: one spelling per status, one date format everywhere.
4. Delete the decoration — merged cells, blank spacer rows, colour-as-meaning. Colour does not survive export, so record what it meant as a real column.
5. Export to CSV and import it into the structured tool.
6. Set the field types: text, number, date, single select, link to another table. This is where a spreadsheet becomes a database.
7. Recreate the relationships. Instead of repeating the customer name on every order, link orders to a customer record.
8. Keep the original sheet read-only for a couple of weeks as a safety net, then archive it.

Colour-coding is the most common casualty. If a yellow row means “needs review”, add a status column before exporting — otherwise that knowledge is lost the moment you hit save as CSV. Spreadsheets that feed a regulated decision have their own problem: they fail most of the alcoa principles by default.

What you gain, and what you give up

• You gain: field types that reject bad data, relationships instead of repetition, per-person access, and a history of changes.
• You give up: the freedom to type anything anywhere. That is the point, but it is a real adjustment for anyone used to a blank grid.
• Keep spreadsheets for what they are good at — one-off analysis, modelling, scratch calculations. The structured store is for the data of record.

Doing it in Ettex

Ettex Records is a local-first structured store: tables, typed fields and queries that run on your device, syncing when you are online. It imports CSV, so a cleaned spreadsheet moves across directly — and Ettex Sheets stays available for the analysis you still want to do in a grid.