From spreadsheet to system

Running an operation on spreadsheets is not a failure. In most cases it was exactly the right call at the time.

A spreadsheet needs no setup, no subscription, no specialist and no commitment. When there are seven clients and one person doing the admin, a well-built sheet is responsive, free and completely adequate. Nothing is wrong with it.

The problem arrives later, and it does not arrive suddenly. A missed follow-up. A duplicate entry. A booking that existed in a message thread but never in the sheet. A customer who is certain they paid and a payment nobody can locate. An afternoon spent assembling a report that should take twenty minutes. Each of these is easy to dismiss on its own, and together they are a real drag on the week.

The spreadsheet is not broken. The operation has grown past it.

The signs you have outgrown it

The transition point is different everywhere, but the signals are consistent — and these are the ones I look for first when I walk into a business that is not sure whether it has a systems problem or a staffing one.

More than one person touches the data. Shared sheets are fragile in a way that has nothing to do with anyone's competence. Two people editing at once, different versions saved locally, a column added by one person that quietly breaks another person's formula — these are not edge cases. They are the normal week.

Things are being missed. Not catastrophically. Regularly. A follow-up that did not happen because the note was in a tab nobody opened. An invoice that was not sent because a column was not updated. A renewal that passed without the call it was supposed to trigger. The spreadsheet reminds you of nothing; it records only what you tell it.

Reporting has become a task. Assembling a picture of the pipeline, the outstanding invoices, or the month's throughput means building it by hand out of raw rows. In a system it is a screen you open.

The admin has started to be dreaded. This is the most honest signal of the four. When maintaining the record feels like a job rather than a tool, the tool has been outgrown.

None of these is a threshold you cross on a particular Tuesday. They accumulate, and the accumulation is the thing to watch.

The fear that keeps operations on spreadsheets too long

The usual reason a business delays is not cost and not complexity. It is fear of disruption during the change itself.

What if we lose data. What if the new thing doesn't work the way we expect. What if the team can't learn it. What if we go live and something breaks in front of a real customer.

Those are legitimate. They are also, in a well-run migration, preventable — and the anxiety almost always comes from imagining a cutover where everything switches at once. One day on spreadsheets, the next day on something new, no overlap and no safety net.

That is not how a good migration works. It is, however, exactly how a bad one works, which is why the fear is so well-founded.

How a migration actually happens

The sequence below is the one I use, and its whole design is to make the risky moment small.

Map before you build. Before anything is created, the existing sheet is audited. Every column is mapped to a field. Every relationship in the data — which client corresponds to which bookings, which invoices, which conversations — is understood and written down. Data that is incomplete or inconsistent gets cleaned up in the spreadsheet, before it moves, not after. Migrating a mess gives you the same mess with a login screen.

Import and verify. Records are imported and then checked against the source. Not every row — a sample, large enough to establish confidence and small enough to actually get done.

Train on real scenarios. The team learns on real records and real situations, not demo data. "Book the follow-up for this actual client" teaches more than "book an appointment for Test User 1", because the real one is where the awkward cases live.

Run in parallel. Both systems stay live for a defined period. New activity goes into the new one; the spreadsheet is kept current as a fallback. This is the period that surfaces the edge cases — the record that imported with the wrong number, the case the new system handles slightly differently, the document that needs one more field. They emerge somewhere low-stakes and get fixed before anything is retired.

Archive, don't delete. The spreadsheet stays reachable and read-only for a defined stretch after go-live. It is the safety net that makes the change psychologically manageable, and in my experience nobody opens it after the first fortnight. That is fine. Its job is to exist.

What changes in the first week

The benefits are felt before they are measured.

Everything scheduled sits in one view, across every person, so a double booking becomes structurally impossible rather than merely unlikely. Outstanding invoices appear as a list you can sort by age, and who hasn't paid stops being a question you answer by scanning a column. Any individual record shows the whole history on one screen — no opening three tabs to reconstruct who this person is and where the relationship stands.

And the machinery starts working on its own. Reminders fire. Follow-ups trigger. Reports generate on demand rather than on request. The administration runs whether or not anyone is attending to it, which is the actual point of the exercise.

The three things that break migrations

For completeness, the ones that go wrong nearly always go wrong in one of three ways.

Going live before the edge cases are found. Moving to production early means finding them in front of a real customer, and that is entirely avoidable — it is what the parallel period is for.

Scope changing mid-migration. The moment somebody says "while we're at it, can we also…", the timeline extends and the risk goes up. New capability belongs in a second phase, after the core is stable. This is the most common one, and it is almost always well-intentioned.

Never retiring the old system. Keeping the spreadsheet alive indefinitely leaves two sources of truth, and two sources of truth means no source of truth. The parallel period needs an end date decided in advance, and the sheet needs to be archived on it.

The first and third are the same mistake at different ends of the process: a reluctance to commit to the moment the change becomes real. Naming the date is most of the work.