A spreadsheet that became a database: choosing when to move

Every option on the market is an answer to one question: who holds the rows. A grid tool, a hosted database, a database with an interface over it, and a custom application differ less in what they display than in who may change a record and what happens when two people try at once. Moving off the grid is worth it once it has started behaving like a system — and a mistake when the real wish is a tidier sheet.

When has the grid stopped being a spreadsheet?

Four signals; any two mean the sheet is already load-bearing.

Linked records. A row refers to another table, so a customer exists once and orders point at it. A lookup formula copies the value; it does not point.

A permission per person. The accountant may change the invoice total, the salesperson may not. In a spreadsheet that is a file per person, or a lock nobody respects.

A view someone cannot see. The moment the purpose of a filtered view is "they must not see the margin column", the grid is doing access control, badly.

Automation that runs overnight. Something creates records while nobody is watching — a system, and one that can write a wrong record unwatched.

The fifth is quieter: a number computed by a rule nobody may override. Once that number must be right, the row is a record and not a cell.

What are the four families?

Grid tools are typing on the row: typed fields, linked records, views, forms, an API, automations. The fastest way to a working internal list.

Hosted databases keep the guarantees and give up the face: real tables, constraints, transactions, concurrent writes. What is missing is somewhere for a person to type.

A database with an interface puts the arithmetic in a store that refuses bad writes and adds screens through an admin panel or a reporting layer. This is what most teams need and what gets skipped: the panel is a second thing to build.

A custom application starts from the process instead of the table: the order, its states, who may move it, what it posts. The only family where the software matches the work.

What does each cost you in the second year?

Not money — constraint. A figure would be wrong within months; what stays true is what each family refuses to do later.

Family	What it gives you early	The constraint you inherit
Grid tool	Records, views and forms in a day; nobody needs training	No transaction across rows; history and permissions are coarse, so the ceiling arrives in a busy month
Hosted database	Constraints and concurrent writes enforced by the store	No interface; someone must own the screens or a spreadsheet reappears beside it
Database with an interface	Enforced arithmetic, plus a screen people accept	Two things to maintain, and a permission model designed twice
Custom application	The process as it is, checks included	You now operate software: releases, backups, support, and a named person who understands it

Read the third column as one question: who does this work, and what happens when they leave?

Why does migrating the shape not migrate the rules?

Because the rules were never in the cells. They live in conventions someone explained once: this column is filled only by whoever handles returns; a negative quantity means a credit; orders are cancelled, never deleted. A header comment is the closest most sheets come to documentation.

Copy the columns into a new tool with the same names and those rules disappear while looking preserved. Four thousand imported rows pass validation because nothing was built to check them, and then a clerk types a negative quantity to mean a return, and stock goes up.

So write the rules down before the migration in three lists: the enumerations (which values are legal), the transitions (an order goes from confirmed to shipped, never back), and the deletions (who may remove a row, and whether removal means archive). Each rule becomes a constraint in the new store or a check at the door; each rule nobody writes becomes a bug with a plausible explanation attached later. The data exports. The meaning does not.

How do you test an option before choosing it?

Three questions for every family, in this order.

1. Can two people edit at once and both survive? Open the same record in two windows, change different fields, save both. If the second save erases the first, that is fine for a meeting note and wrong for a stock level.
2. Can you export everything? Not a comma-separated file of the visible view — the relations, the history, the attachments, the schema. The W3C's data on the web best practices treat machine-readable access and persistence as a baseline of publishing data, not a courtesy — a fair way to judge a vendor too.
3. Who is allowed to delete a row? If the answer is "whoever can open the table", the history is decoration and will be tested by an argument you cannot settle.

Run the move in five steps:

1. Count the rules, not the rows. Twenty columns and fifteen conventions is a bigger migration than two hundred columns and two.
2. Write down who does what, per table: who creates, who edits, who reads, who may never see a column.
3. Choose the smallest family that passes the three tests, not the most capable one.
4. Move one workflow end to end, then leave the old grid read-only for a month. Writes in two places are how the disagreement starts.
5. Name the owner of the new thing in writing. Not a role, a person.

Where this goes wrong

• The permanent pilot. One table is imported and the grid stays authoritative because it is where the work happens. Two sources, one truth claim each.
• The interface without an owner. A panel gets built by whoever was free that month; it works, nobody can change it, and the first new requirement starts a second one.
• Permissions copied as views. A shared filtered view is treated as access control; a link travels, a permission does not.
• Unwatched automation. An overnight job fails silently for three weeks, and every record created in that window is missing a field the business assumed was filled.

What this advice leaves out

There are no prices here on purpose. Every family is sold per user, per row or per hour of build, the limits move between plans, and a figure would be wrong before the page was indexed and then quoted back as a specification. Read the plan you would actually buy.

It also leaves out data-protection obligations, procurement at scale, and estimating a build, which depends on the rules more than the technology. We build and integrate systems around tools like these; we resell none of them and take no commission.

We build the boundary first — which rows are records and which system owns them — because that decision survives whichever tool wins.