Moving Off Spreadsheets: How to Do It Without Losing a Year of Records

Spreadsheets are underrated. They are flexible, universally understood, and free. Many businesses should not move off them at all.

But there is a point where a spreadsheet stops being a tool and starts being a risk. Recognising that point — and migrating carefully when you reach it — is the subject here.

Signs you have outgrown it

You have probably crossed the line if two or more of these are true:

• Two people cannot work in it at once without someone creating "Copy of Copy of Sales (final) v3".
• You cannot tell who changed a number, or when, or why.
• The same customer appears three times, spelled differently.
• A formula broke once and nobody noticed for weeks.
• Only one person understands it, and the business stops when they travel.
• You are afraid to reorganise it because something downstream will break.
• You need different people to see different things — a salesperson should not see everyone's commission.

That last one is decisive. Spreadsheets have no meaningful permission model. Once you need role-based access, no amount of tab-hiding will do.

Before you migrate, clean

The single biggest determinant of migration cost is data quality, and cleanup is work your own team can do far more cheaply than a developer can.

Pick one row per thing. Decide what a row represents — one customer, one order, one payment — and make sure it is that, consistently. Rows that mean different things in different sections are the most expensive problem to untangle.

Standardise dates. One format, everywhere. 2026-08-22 sorts correctly and is never ambiguous. Mixed 12/08 entries where some are day-first and some month-first cannot be reliably recovered later, by anyone.

Fix numbers stored as text. Currency symbols, commas, and trailing spaces inside numeric columns cause silent errors on import.

Deduplicate deliberately. Sort by name, scan for near-matches, and merge by hand. Automated fuzzy matching will merge two genuinely different customers eventually, and you will not find out until one complains.

One value per cell. "Chidi / 0803... / paid half" in a notes column has to become three columns before anything can use it.

Delete what you will not use. Columns nobody has filled in for a year are not worth migrating. Archive the original file and move on.

Do this before you get a quote. It frequently reduces the migration line item substantially.

Choose what to migrate

Not everything needs to come across.

• Active records — current customers, open orders, current pupils. Always migrate.
• Recent history — usually the last twelve to twenty-four months, for continuity of reporting.
• Deep archive — keep it as a read-only spreadsheet or export. Paying to migrate six-year-old records into a live system you will never query is a common and avoidable expense.

Write this decision down before migration begins, and keep the untouched original file forever, backed up somewhere separate. It is your only ground truth if something goes wrong.

Run the migration at least three times

A migration is not one event. Done properly it is:

1. Test migration one. Import into an empty test system. Everything will break. Fix the script, not the source file.
2. Test migration two. Now check totals. Row counts, sums of amounts, counts per category. They must match the spreadsheet exactly. If they do not, do not proceed until you know why — "close enough" is how a business loses a month of revenue records.
3. Spot check by hand. Pick twenty records at random, plus the five weirdest ones you know about, and compare them field by field with the source.
4. Final migration. Freeze the spreadsheet, run the import, verify totals again, then go live.

That freeze matters. Anything entered into the spreadsheet after the final export and before go-live will be lost unless you re-key it deliberately. Announce the freeze window in advance and keep it short.

Run both for one cycle

For one full cycle — a month, a term, whatever your business runs on — keep entering into both the old spreadsheet and the new system.

Everyone hates this and everyone who has skipped it regrets it. It is the only way to catch a rule the new system got subtly wrong, and the cost of finding that in parallel is an afternoon, while the cost of finding it three months later is a rebuilt quarter of reporting.

Expect the process to change

Here is the part people are unprepared for: the system will not just store your process, it will expose it. Half-rules that lived in one person's judgement have to become explicit. "We sometimes give a discount to loyal customers" must become a rule with a definition.

This is uncomfortable and it is most of the value. The clarity is worth more than the software.

Keep the spreadsheet habit that was good

The reason people love spreadsheets is that they can answer a new question in two minutes without asking anyone. Do not lose that. Any system you adopt should let you export any list to CSV, immediately, without a support ticket. Then the spreadsheet becomes what it should always have been — an analysis tool, not a database.

If you are weighing up a move and want a realistic view of the effort, book a consultation and bring the file. We will tell you what state it is in.