Getting off the spreadsheet that runs your business

Somewhere in your business there is a spreadsheet that matters more than it should. It holds the jobs, or the bookings, or the stock, or the fees. One person built it, it has a tab nobody else fully understands, and if it were deleted tomorrow you would have a very bad week.

This is normal. It is also, eventually, a problem. The useful question is when.

The spreadsheet is not the enemy

A spreadsheet that runs a business is not a failure of planning. It is the most successful piece of business software ever made, it cost you nothing, and it fits your process exactly because you shaped it yourself while doing the work.

Plenty of companies should stay on theirs for longer than a software company would like to admit. If yours works, if one person maintains it, and if nothing on the list below is happening, keep it and spend the money on something else.

Signs you have outgrown it

Not one of these is about how big the file is. They are all about how many people need it.

• Two people need it open at once, and you have started emailing copies with names like final and final-2
• A number changed, nobody knows when, and there is no way to find out who did it
• There is a hidden tab of lookups that one person understands and everyone else is frightened of
• Somebody keeps a second spreadsheet that summarises the first
• People outside the office need to see part of it, so you send screenshots
• You cannot show someone the bit they need without showing them everything -- pay, margins, customer details, all of it, because a file has no roles
• There is a rule that says do not touch column M
• Sorting one column has broken the whole thing at least once

Three or more of these and the spreadsheet has stopped being a tool. It has become a system with no safety features.

What breaks first, in order

Two people at once. The first real failure. Copies multiply, and now nobody is certain which one is true.

Silent damage. Somebody pastes over a formula. Nothing looks wrong. Six weeks later a total is out and there is no way to find the moment it broke.

History. You want to know what a figure was in March. The cell shows today. The old value is gone, unless someone kept a copy.

Access. You need a part-time member of staff to update three rows, and there is no way to let them do that without giving them the whole file.

The person. The one who understands it goes on holiday, changes job, or is simply busy on the day you need an answer.

Three cheaper fixes to try first

Before building anything, spend a week on these. If they buy you another year, take the year.

Move the file to a shared cloud drive with proper version history and real simultaneous editing. That alone fixes the copies problem and gives you an undo that goes back weeks.

Lock the formulas. Separate the sheet people type into from the sheet that calculates. Most silent damage comes from typing into a cell that was doing arithmetic.

Split the working file from the archive, so the live one stays small and fast and last year lives somewhere else.

How a migration actually goes

We read the spreadsheet as the specification. Send the real file, not a tidied version. The columns are the fields. The shaded cells are the statuses. The comments in the margin are the exceptions. The rules that live in somebody's head are the validation, and getting those out of their head is most of the work. This is why custom software built from a spreadsheet is usually faster to specify than one built from scratch: you have already designed it, over years, by using it.

Then the awkward questions. What exactly does "pending" mean, and who decides when it stops being pending? Is a job with no engineer assigned still a job? Half of these turn out to be business decisions nobody ever made, which is a good thing to discover before the software forces an answer.

Clean the data while it is still in the spreadsheet. This is the cheapest place to fix it, and it is work only your team can do: one spelling per supplier, one date format, duplicates merged, required fields either filled in or explicitly left blank on purpose. Doing this after the import costs several times more.

Import, then reconcile. Record counts and totals from the new system printed next to the same figures from the spreadsheet. If they do not match, the import is wrong until proven otherwise. Nobody moves on until they agree.

Run both for a fortnight. The team works in the new system; one person keeps the spreadsheet updated alongside. It is duplicated effort and everyone hates it, which is why it is short. It is also the only honest way to find out whether the new system covers reality.

Freeze the spreadsheet, do not delete it.

Keep the old file as a read-only archive

Fear of losing history is the single most common reason a migration stalls. Remove the fear.

When you switch over, make the spreadsheet read-only, rename it with the date it was frozen, put a line at the top saying where the live data now lives, and keep it somewhere everyone can find. Three things happen because of this.

Someone will ask a question in the first month that the new system cannot answer yet, and the archive answers it. If the import got something wrong, the original is right there to check against. And the team stops treating the switch as a leap of faith, which makes them far more willing to make it.

Do not leave it editable. A live spreadsheet next to a live system means two truths within a fortnight.

What you will lose

An honest trade: you lose the ability to do absolutely anything in ten seconds by typing in a cell.

A system has rules. Rules say no. The same rigidity that stops somebody deleting a month of jobs also stops your best member of staff inventing a clever workaround at four on a Friday. Most businesses find that a good bargain. Some do not.

If your work genuinely changes shape every month -- new columns, new categories, a different way of counting each quarter -- a spreadsheet may still be the right tool, and forcing it into software will just mean paying a developer every time you change your mind.

When not to do this

If one person uses it and it works. Nothing else to say.

If the spreadsheet is a model rather than a record. Pricing calculators, forecasts, estimates: spreadsheets are outstanding at those, and rebuilding one as software usually makes it worse. It is the shared record of things that outgrows a file -- jobs, bookings, students, patients, stock.

If the real problem is that two systems do not talk to each other and the spreadsheet exists to bridge them. That is an integration, and it is a smaller job.

The test is not how complicated your spreadsheet has become. It is how many people need the same truth at the same time, and whether you can tell who changed it.