← All postsHow-to

How to move from spreadsheets to a database

The signs a spreadsheet has outgrown itself, and how to move without losing the flexibility that made it work.

How-toH

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.

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.

Frequently asked

Will I lose my formulas?

Calculated columns usually have an equivalent, but complex nested formulas rarely transfer as-is. Rebuild the few that matter and drop the rest — most stop being needed once relationships replace lookups.

How long does a migration take?

The import takes minutes. Cleaning a messy sheet is what takes a day, and it is unavoidable — importing mess produces a structured mess.

Can I go back?

Yes, if the tool exports CSV. Check that before you migrate, not after.

Do I still need spreadsheets?

Almost certainly. Use them for analysis and one-off models; keep the data of record in the structured store.

ET
Written by Ettex Team

Part of the Ettex team — writing about product, engineering and the future of work.

More posts
Get the best of the Ettex blogProduct news, guides and tips — straight to your inbox, no spam.