10 signs your business has outgrown Excel

In October 2020, Public Health England lost 15,841 positive COVID-19 test results. The cause was not a server failure or an attack. An automated process was writing results into the legacy .xls spreadsheet format, which stops at 65,536 rows. Because each test produced several rows, each file filled after roughly 1,400 cases. Once a file was full, further results were simply not written.

Nothing crashed. No error was raised. For a week the reports looked entirely normal and were quietly wrong. That is what spreadsheet failure actually looks like in a working business, and it is the reason these problems run for years before anyone acts on them. The signs below are the ones that show up first, and every one of them can be checked in an afternoon.

Excel is not the problem

It is worth being precise about this, because most articles on the subject are written by companies selling the replacement. Excel is exceptional software. For modelling, analysis, one-off calculation and thinking through a problem numerically, nothing else is as fast, and a business that abandons it entirely has usually made a mistake.

The failure mode is narrower than that. It appears when a spreadsheet is used as a multi-user system of record: the authoritative place where operational data lives, edited by several people, referenced by decisions. A spreadsheet has no concept of a transaction, a uniqueness constraint, a permission, or a history. These are not defects. They were never in scope. Every sign below is a direct consequence of asking a file to behave like a database.

Signs your data has stopped being trustworthy

1. The same customer exists more than once, spelled differently

A database can be told that a customer reference must be unique, and it will refuse anything else. A spreadsheet cannot be told this, so nothing stands between a rushed entry and a second version of an existing customer. The cost is not the duplicate itself but everything downstream: revenue reported twice, a customer contacted twice by different people, and totals that quietly disagree depending on which rows were counted.

2. Nobody can say with certainty which copy is current

This is the mechanism behind the filenames everyone recognises. It is worth stating plainly because the distinction matters: a spreadsheet is copied, whereas a record is referenced. Every time a file is emailed, downloaded or saved locally, a new authoritative version exists. Cloud co-authoring reduces this considerably, but it does not eliminate it, because the moment somebody exports a copy to work on offline the fork reappears.

3. Formulas reference cells nobody is willing to change

Almost every long-lived operational spreadsheet reaches a state where part of it is treated as untouchable. Someone built it, it produces the right-looking answer, and nobody can fully explain it. This is the sign with the strongest research behind it. Raymond Panko, reviewing fifteen years of studies, concluded that spreadsheet errors are both common and non-trivial, and that only one technique has ever been demonstrated to find them reliably: cell-by-cell code inspection. No business reads every cell of a working spreadsheet. In practice that means an error, once introduced, is very unlikely to be found by anything except its consequences.

4. The same data is typed into two systems

Somebody closes a deal in the spreadsheet, then enters the same customer into the accounts package, and possibly again into a support tool. Every re-keying is an opportunity for divergence, and divergence between two systems is much harder to detect than an obvious error in one. This sign is worth noting separately because it is the one most often misdiagnosed. It is rarely a signal that the spreadsheet is wrong. It is a signal that two systems are not connected.

Signs the process depends on people rather than systems

5. You can see the current state but never how it got there

A cell shows a value. It does not show that the value was 4,000 last Tuesday, who changed it, or why. Version history in a cloud spreadsheet retrieves a whole file at a point in time, which is not the same as an audit trail on a record. The commercial consequence appears during disputes, and the compliance consequence appears during audits: the inability to answer who changed this and when is a governance gap, not an inconvenience.

6. Access is all-or-nothing

You cannot easily give a new salesperson one region, or a contractor one account list, because permissions in a spreadsheet apply to the file. In practice this resolves one of two ways: everyone sees everything, or someone maintains filtered copies by hand, which reintroduces sign 2. Where the data includes personal information this stops being an efficiency question. GDPR Article 32 requires appropriate technical measures to secure personal data, and access control proportionate to the data held is the ordinary reading of that obligation. A file everyone can open does not meet it comfortably.

7. The process works because one person understands it

There is usually somebody who knows which tab to update first, which column is stale, and which figure to ignore in the summary. That knowledge is not written down anywhere, because a spreadsheet documents its data and never its process. The exposure is straightforward and rarely priced: when that person is on leave, the work slows; when they leave permanently, part of the operation has to be reverse-engineered from the file.

Signs you are approaching a hard limit

8. The file has become slow to open or recalculate

The practical limit almost always arrives long before the documented one. Recalculation time grows with the number and complexity of formulas rather than with row count alone, so a file with tens of thousands of rows and heavy lookups can become unpleasant to work in while remaining a small fraction of the theoretical maximum. Waiting for a file to respond is the visible symptom. The real cost is that people stop opening it, and start keeping the working version somewhere else.

9. Reporting is reconstruction rather than retrieval

If producing a monthly figure means combining sheets, correcting for known quirks and reconciling two sources by hand, the underlying issue is that the data is not structured for the question being asked. A system designed around records and relationships answers that question by querying what it already holds. A spreadsheet answers it by having somebody rebuild the answer, which takes hours and produces a slightly different result each time depending on who did it.

10. You are near a published limit you did not know existed

Microsoft publishes these figures. A modern .xlsx worksheet holds 1,048,576 rows by 16,384 columns, and a single cell holds up to 32,767 characters. The legacy .xls format stops at 65,536 rows, which is the ceiling Public Health England reached. The specific numbers matter less than the behaviour at the boundary, which is the lesson worth taking from that incident: limits in a spreadsheet pipeline are not always announced. Data can stop arriving while every report continues to render normally.

What the research actually says

The evidence base here deserves an honest description. Systematic research into spreadsheet error rates is a real field, maintained by groups including the European Spreadsheet Risks Interest Group, but the corpus is modest and much of the foundational work is now some years old. It does not support the confident percentages that circulate in articles on this subject, most of which are quoted without a traceable source.

What it does support is more useful anyway. Panko's central findings are that errors in operational spreadsheets are common rather than exceptional, that they are extremely difficult to detect once present, and that the people who build and rely on those spreadsheets are consistently overconfident about their accuracy. That last point is the one that matches what we see on engagements. The spreadsheet nobody has ever audited is invariably the one described as reliable, and both statements are usually true at the same time.

Not all ten of these are a CRM problem

The title of this article promises a CRM, and for most of these signs that is genuinely the right answer. Four of them are not, and treating them as CRM problems is how businesses end up paying for a platform that does not address the thing that was actually hurting.

Sign 4 is integration work. If the spreadsheet and the accounts package simply need to agree, connecting them through their APIs is a fraction of the cost of replacing either, and a workflow automation platform such as n8n can often do it without modifying either system. Sign 3 is a modelling problem that survives migration untouched, because a CRM will happily store a number that was calculated incorrectly. Sign 7 is process documentation, which a CRM supports but does not perform for you. Sign 8 sometimes points to a database rather than a CRM, particularly where the data is operational rather than customer-facing.

Before you migrate anything

Whatever you move to, the spreadsheet you have now is two things at once. It is the most accurate specification available of how the business actually works, including every exception the official process does not mention. It is also the largest liability in the project, because its data quality determines whether the new system is trusted in month three.

Cleaning data before migration is materially cheaper than cleaning it afterwards. Before the move, a duplicate is two rows. After the move, it is two customer records with separate activity histories, linked invoices and assigned owners, and merging them means deciding what happens to everything attached. The order of operations is worth respecting even under time pressure.

1. 1

   Profile the data before choosing a platform

   Count true distinct customers rather than rows. Identify which columns are genuinely populated and used, and which were added once and abandoned. This tells you the real size of the problem, which is usually smaller than the row count suggests.

2. 2

   Decide what history is worth carrying

   Not all of it is. Migrating five years of records that nobody queries adds cost and risk to the migration and value to nothing. Archive rather than migrate where the data has no operational use.

3. 3

   Resolve the duplicates while they are still rows

   This is the single highest-value hour of the project and it happens in the spreadsheet, before any platform is involved.

4. 4

   Rehearse the cutover, including the rollback

   Load into a test environment first, have the people who use the data daily check a sample, and know what returning to the spreadsheet looks like if the load is wrong. A migration you cannot reverse is a decision you cannot revisit.

This work is required regardless of which direction you choose, which is what makes it the safest first spend. Even if the conclusion is to stay on Excel for another year, you finish with cleaner data and a documented process, and neither is wasted.

Frequently asked questions

Conclusion

If fewer than three of these signs apply, the reasonable course is to stay where you are, fix the specific irritations, and look again in six months. Spreadsheets are cheap, familiar and fast, and replacing one that is working is a poor use of money.

If three or more apply, particularly if they cluster in one group, the problem is structural. Structural problems do not improve through care and attention, and the cost of them is paid continuously in small amounts that never appear on an invoice. At that point the question changes from whether to move to what to move to, and the honest answer is not automatically a custom build.