Moving from Excel to a web app: when, how and what it costs

Excel is a good tool for one person thinking through numbers. The trouble starts when a workbook becomes the place where the business records orders, prices or stock. The signs are easy to spot.

• Several people open and edit the same file every day, and someone regularly overwrites someone else’s work.
• There are copies: "final", "final v2", one per salesperson. Nobody is sure which is right.
• An error in a cell has already reached a customer as a wrong price, a wrong delivery date or a missed order.
• One person built it and is the only one who dares change the formulas. When they are away, nothing moves.
• The same data is typed twice: once in the spreadsheet, once in the ERP or the accounts package.
• You need to know who changed what and when, and the file cannot tell you.
• Customers or distributors ask for access, and you send them an export by email.

Three or more of these, on a process that touches revenue, and the spreadsheet is a system in everything but name. That is common: in the EU, only 41% of small enterprises use ERP software (Eurostat, 2026), so the rest run on something else.

• No rules of its own. Anyone can type text in a date column, delete a row or drag a formula over a value, and the file will accept it.
• Hard limits. A worksheet holds 1,048,576 rows by 16,384 columns, and a shared workbook can be opened by 256 users at once (Microsoft).
• A public failure. In autumn 2020, 15,841 positive Covid cases went unreported because Public Health England moved test results through an old Excel file format that could hold only about 65,000 rows per template (BBC News, 2020). The file simply stopped taking rows, and nobody was warned.

That is the real difference with a web application: a database refuses bad data, records who changed what, and lets fifty people work on the same order book without a copy.

1. Write down what the workbook really does. Every sheet, every formula that matters, every macro, and who uses what. The file is the best specification you have.
2. Separate data from rules. Customers, parts and prices are data. "Add 12% above 500 units" is a rule. Rules buried in formulas have to be written out in plain words and agreed.
3. Clean the data. Duplicates, three spellings of one customer, dates stored as text. Allow more time for this step than you think it needs.
4. Design the screens around tasks, not sheets. A good web app does not look like the spreadsheet. It shows each person the three things they do every day.
5. Build in short deliveries. Every two weeks, real users try the new screens with real cases and say what is missing.
6. Run both for a short period. For two to four weeks, compare the results of the app and the workbook on the same cases.
7. Switch, and lock the old file. Make it read-only on a set date, or people will drift back to it.

A link to the ERP or accounts package belongs in the specification from the start. If the app has to read stock or write orders, that decides a large part of the cost. The service is described on our bespoke software development and web application development pages.

What moves the price is rarely the number of rows. It is the number of rules hidden in formulas and macros, the number of roles (who may see and change what), the links to other systems and the state of the data. A workbook with five sheets and one hard pricing rule can cost more to replace than one with forty simple lists.

Moving to a web app does not mean banning spreadsheets. Excel remains the right tool for work that is personal, occasional or exploratory.

• Analysis: margins by product family, a what-if on a price rise, a board pack.
• One-off calculations that will never be repeated in the same form.
• Budgets and forecasts owned by one person.
• Checking: an export from the app, opened in Excel to verify a total.

A well-built app makes this easier, not harder: every list can be exported, and the export is always the current data. If part of the work is reading orders that arrive by email or PDF, look at sales order automation before building screens for manual entry.