When Should a Business Replace Excel With a Custom System?

Almost every custom system we build replaces a spreadsheet, and the spreadsheet is almost always impressive. Someone built it carefully, it encodes years of accumulated business logic, and it works. The question is never whether Excel is good. It is whether this particular workbook is still the right container for what it has become.

Seven signals that the workbook has outgrown itself

1. More than one person needs to edit it at the same time

This is the clearest signal. Spreadsheets are single-author documents by design. The moment two people need to work in one simultaneously you get file locks, "copy for editing" versions, and eventually two divergent truths. Shared cloud spreadsheets soften this but do not solve the underlying problem, which is that there is no concept of a record being owned by a transaction.

2. Nobody can safely change the formulas

When a workbook reaches the point where people work around a formula rather than modify it, the business logic has become unmaintainable. Formulas have no tests, no version history and no comments. A system with the same logic in readable code, covered by tests, can be changed with confidence.

3. You cannot tell who changed what

If a number is wrong, can you determine when it changed and who changed it? In most workbooks the answer is no. For anything touching money, stock or customer commitments, that absence of an audit trail is a genuine business risk, not a technical inconvenience.

4. The same data is typed into it from another system

A spreadsheet fed by manual re-entry from an ERP or e-commerce platform is a copy that is wrong from the moment it is made. This particular signal often has a cheaper answer than a full system: automate the feed, or integrate the two, and see whether the pain goes away.

5. It has become slow, or hit a limit

Recalculation taking thirty seconds, files that will not open on older machines, hitting the row limit — these are symptoms of a dataset that wants a database. A database handles millions of rows without noticing, and lets you query them in ways a workbook cannot.

6. Access cannot be controlled

Everyone who can open the file can see everything in it: costs, margins, salaries, customer terms. Spreadsheets have no meaningful concept of field-level permission. If your workbook contains information that should be restricted, it currently is not.

7. Breaking it would stop the business today

The final test. If the file were corrupted or deleted this morning, what would stop? If the answer is anything significant, you are running a critical system with no backup discipline, no access control, no audit trail and one author.

What a system does that a spreadsheet cannot

It is worth being specific, because "we need a proper system" is not a requirement.

• Concurrency — several people working at once without overwriting each other
• Validation at entry — impossible values rejected rather than corrected later
• Permissions — people see and change only what their role allows
• Audit trail — a durable record of who changed what, when, and from what value
• Relationships — a customer, their orders and their deliveries linked rather than repeated
• Automation hooks — the system can notify, generate documents and post to other systems on events
• Reporting on live data — no assembly step between the data and the report

If none of those matter for your workbook, it does not need replacing. Plenty of spreadsheets are perfectly appropriate and should be left alone.

What to do with the knowledge in the workbook

The single most valuable asset in a mature spreadsheet is not the data. It is the accumulated business logic — the pricing rule that accounts for a specific customer arrangement, the adjustment applied to one product category, the exception for month-end. Much of this was never written down anywhere else.

A replacement project should begin by extracting that logic explicitly: reading the formulas, asking the author why each exists, and documenting the rules in plain language. This is worth doing even if you decide not to build anything. It converts a fragile personal asset into an organisational one.

Migrating without losing anything

1. 01Document the rules from the workbook and confirm them with the person who maintains it.
2. 02Design the data model around the real entities — customers, orders, jobs — rather than replicating the sheet layout.
3. 03Build the core first and load a copy of the real data into it, not sample data.
4. 04Run both in parallel for a full cycle, comparing outputs and investigating every difference.
5. 05Switch over once they agree, and keep the final workbook as a read-only archive.

Step four is the one that gets cut under time pressure and the one that determines whether people trust the new system. A parallel run that finds three discrepancies has done its job — those three would otherwise have been found by a customer.

Excel afterwards

Replacing the workbook does not mean removing Excel from the business, and any vendor who tells you it does is not being practical. Excel remains excellent for analysis, modelling and one-off questions. The change is that it stops being the place where operational records live, and becomes what it is good at: a tool for thinking with data that a system exports on demand.