Moving a business off spreadsheets: what actually has to happen
Nobody has ever been stopped by the number of rows. What stops migrations is that half the columns mean something only one person knows.
The short answer
The row count barely matters; the state of the data does. Clean, consistent columns import quickly. Merged cells, one column holding three facts, the same customer spelled four ways, and history recorded as a cell colour take far longer, because a person has to decide what each row means. Migration is scoped and priced as part of a build starting at $2,000 over 30 to 45 days.
SHT-02What drives the number
The spreadsheet is not the problem until it suddenly is
A spreadsheet is the correct tool for longer than software people like to admit. It is free, it is flexible, everyone can read one, and it does exactly what you tell it. What ends the arrangement is rarely size. It is that two people edit it and one copy wins silently. It is that someone dragged a formula down one row too far and the totals have been slightly wrong since March. It is that there is no record of who changed what, so a disputed number cannot be settled. It is that everyone who can do the job can also see the payroll tab. Those are permission and history problems, and a spreadsheet has no answer to either. Recognising which one is biting you also tells you what the replacement must do first.
Five conditions that decide how long migration takes
One: does each column hold exactly one fact? A cell containing a name, a phone number and a note is three columns pretending to be one, and separating them is a judgement call per row. Two: is the same entity spelled one way? Duplicate customers under four spellings have to be merged by a human who knows which is which. Three: is any meaning carried by formatting? Colour, bold and strikethrough are real data in most spreadsheets and are invisible to an import. Four: are there merged cells or blank rows used as visual separators? Both break the shape of the table. Five: is there history, or only current state? A sheet that records what a job is worth now but not what it was quoted at cannot produce a report about anything that changed. Every one of these costs a decision, and decisions are the currency of a migration.
What actually has to happen, in order
First, decide what the things are. A spreadsheet usually has one row per job, but a business has customers, jobs, estimates and payments, and one row is quietly all four. Splitting them is the real work and it happens on paper before any code. Second, clean at the source, in the sheet, where the people who know the data can see it. Fixing data inside a half-built system is slower and less visible. Third, import in a way that can be undone: a run that can be reversed and repeated is the difference between an afternoon and a bad week, because the first import is always wrong somewhere. Fourth, reconcile with an exact count, not a spot check. Empty and broken must not print the same sentence; a query that errors and a query that finds nothing both look like zero, and a confident zero is how a failed import gets signed off. Fifth, run both in parallel briefly, then stop editing the sheet on a named day. A migration with no end date is a business with two records of the truth.
The formula in the sheet is the most valuable thing you own
Somewhere in most business spreadsheets there is a calculation the whole operation depends on: the one that turns measurements and materials into a price, or a price into a margin. It has been tuned by years of being slightly wrong. Migrating it is not copying it. It has to be written down in plain language, checked against real past deals where the answer is already known, put in exactly one module, and locked with tests. The failure mode here is not theoretical: when the same rule exists in the application and in the database and they are changed at different times, the database quietly computes one number while the screen shows another, and nothing fails loudly. The rule is that a fact lives in one place, or it will eventually disagree with itself on a screen a customer is looking at.
What not to migrate, and what the sheet is for afterwards
Not everything deserves to move. Rows for jobs that died three years ago, columns somebody added for a report nobody runs, and the tab that was an experiment all add cost and no value, and they make the new system feel cluttered on day one, which is when your team decides whether they like it. Move what the business actually uses, and keep the old file, read-only, as an archive you can consult. The point of migration is not that every byte survives; it is that the work stops depending on a file that one person understands.
SHT-03The options, side by side
What each route actually costs you.
| Option | Price | Timeline | The trade-off |
|---|---|---|---|
| Stay on spreadsheets | $0 | — | Free, flexible and understood by everyone. No permissions, no history, no protection against two people editing, and one dragged formula can be wrong for months. |
| Spreadsheet plus an off-the-shelf CRM | Per seat, per month | Days | Contacts and pipeline move; the calculation that decides your price does not, so the sheet stays open beside it and the numbers get retyped. |
| Import it yourself into a product | Your own hours | Days to weeks | Cheap and often fine for a clean contact list. Duplicates, merged cells and meaning stored as colour are where it turns into a project you did not budget. |
| Migration inside a build | Part of a build from $2,000 | 30-45 days | The entities get modelled properly and the pricing formula gets one home and a test suite. Costs more, and needs someone who can answer what a strange row means. |
SHT-04General notes
The questions people actually ask.
- N01How many rows is too many for a spreadsheet?
- The wrong question. Businesses run fine on large sheets and drown in small messy ones. What ends the arrangement is two people editing the same file, no history of who changed what, no permissions, and a formula that has been quietly wrong since somebody dragged it. Those arrive independent of size.
- N02How much does data migration cost?
- It is scoped inside a build rather than quoted per record, because the cost is decisions rather than volume. Clean consistent columns are quick. Duplicate customers, columns holding several facts, and meaning stored as cell colour all require a person to decide row by row, and that is where the time goes.
- N03Will I lose my history?
- Not if it is in the sheet in a form that can be read. What cannot be recovered is history that was never recorded: if the file holds only what a job is worth now and not what it was originally quoted at, no migration can produce a report about the change. The old file is kept read-only as an archive regardless.
- N04Should I clean the data before or after the import?
- Before, and in the spreadsheet, where the people who know what the rows mean can see them. Cleaning inside a half-built system is slower, less visible, and hides the scale of the problem until late. The import itself should be reversible and repeatable, because the first run is always wrong somewhere.
- N05What happens to the pricing formula in my sheet?
- It gets written down in plain language, checked against past deals where you already know the right answer, implemented in exactly one module, and locked with tests. A rule that exists in two places will eventually disagree with itself, and it will do so on a screen a customer is looking at.
- N06Can I keep using the spreadsheet alongside the new system?
- Briefly and with a named end date. Running both in parallel for a short overlap is how you build trust in the new records. Running both indefinitely means the business has two versions of the truth, and the one people believe will be whichever is open at the time.