From Excel to web app: when your spreadsheet becomes a system

Every business has one. The spreadsheet that started as a quick list and now has fourteen tabs, colour-coding only one person understands, and a filename ending in "FINAL v3 (Jason's copy)".

Excel is the most successful business software ever made, and for good reason. But there's a point where a spreadsheet stops being a tool somebody uses and becomes a system the business runs on. Spreadsheets aren't built to be systems, and the cracks show in predictable places.

Why sharing a workbook goes wrong

There are two ways to have several people in one Excel file, and each has its own headaches.

The old Shared Workbook feature

This is the one where you turned on "Share Workbook" and people's changes were merged when they saved. Microsoft now calls it a legacy feature and hides it by default. It switches off a long list of Excel features while it's on (you can't create Excel tables, merge cells or add charts, among others), and conflicting changes are resolved by whoever saves last, or by a dialog box most people click through. If you're still using it, it's worth moving off.

Co-authoring in Microsoft 365

The modern replacement. Several people edit the same file at once and see each other's changes. It's genuinely good, but it only works when the file is in OneDrive or SharePoint, in a modern format, opened in a recent version of Excel with AutoSave on. One person opening it from a mapped network drive, or in an older Excel, and you're back to "locked for editing by another user". Some older macro-heavy workbooks don't co-author well either.

And even when co-authoring works perfectly, it solves the editing problem, not the system problem. Nothing stops someone typing "tbc" in a date column, deleting a row by accident, or seeing data they shouldn't.

What converting Excel to a web application involves

There are tools that turn a spreadsheet into a web form, and for a simple list they can be fine. For a spreadsheet that's become a system, it's better to rebuild it properly. That goes like this:

1. Work out what the spreadsheet really is. Usually each tab is a list of something (customers, jobs, orders), and the colour-coding and notes columns are a status nobody formalised. These become proper tables in a database.
2. Turn the formulas into rules. Every formula that matters is a business rule: a price calculation, a due date, a margin. Each one is written down, agreed and built into the application, so it's applied the same way every time.
3. Build the screens people need. A form to add a job, a list to see what's due, a report for the Monday meeting. Not a copy of the grid, but the things people were using the grid for.
4. Add what the spreadsheet couldn't do. Individual logins, people seeing only their part, a history of who changed what, reminders, and links to the accounts package or your website.
5. Bring the data across. Clean it up on the way: the duplicate customers, the "tbc" dates, the rows in red that nobody remembers the meaning of.
6. Run both for a short while, then retire the spreadsheet. Keep a read-only copy for reference.

It's the same process as converting an Access database to a web application, usually on a smaller scale. If your spreadsheet has already been moved into Access, start with our guide on Access with multiple users.

What it costs

Less than you might think. We use AI-assisted development, so turning a spreadsheet into a web application takes far fewer developer days than it used to. Most single spreadsheets take four to eight weeks. One with lots of interlinked tabs, heavy macros or links to other systems takes longer. Send it to us and we'll give you a figure. There's more on how we work on the main replacing Access and spreadsheets page.