Excel to web app: when should a spreadsheet become software?

Moving from Excel to a web app means taking the data out of the workbook and into a database, then rebuilding what people do with it as screens, sign-ins and rules. It is worth doing when the spreadsheet has become the system the business runs on: several people edit it, rows move through stages, and a mistake in it costs money or trust. If one person keeps a list for their own use, Excel is still the right tool.

Signs the spreadsheet has become the system

A workbook that started as a list can grow, a column at a time, into the way the work gets done. These are the signs it has:

• Several people edit it, and copies circulate. Someone emails “the latest version”, and someone else carries on working from last week’s.
• Each row has a status. A column saying where a customer, order or job has got to means the sheet is tracking a process, not just storing data.
• Tabs stand in for stages. Rows are cut from one tab and pasted into the next as the work moves on.
• It holds personal data. Names, phone numbers, addresses and notes about people, and everyone who can open the file can usually see all of it.
• The documents live somewhere else. The sheet says a form has arrived; the form itself is in an inbox or a shared folder, and someone has to go and find it.
• One person understands the formulas. When they are on holiday, nobody dares change anything.

One of these is a nuisance. Three or four together mean the business is running on a file that was never designed to carry it.

One example of spreadsheets replaced by bespoke software comes from my own work: for GK Finance, a mortgage and protection adviser in Northampton, I designed and built a case management console that replaced many spreadsheets. It manages customers, enquiries, case stages, documents and notes. I also designed and built GK Finance’s public website, which is a separate project.

What changes when a spreadsheet becomes a web app

The screens are the part people see, but most of the change happens underneath them.

The data moves into a database. In a spreadsheet, a customer is a row, and anything that doesn’t fit the columns ends up in a note or on another tab. In a web app, customers, jobs and documents are separate records linked to each other, so one customer can have several jobs without anyone copying their details from row to row.

Formulas become rules. A formula that flags an overdue job or checks a total becomes a rule the app applies every time, and nobody can overwrite it by typing into the wrong cell.

Tabs become stages. Instead of rows being moved between tabs, a record moves from one stage to the next, and everyone sees the same picture of what is waiting and where.

Sharing becomes sign-ins and permissions. Each person signs in, sees what their role needs and changes only what they are allowed to. The app can also record who changed what, and when.

That last point matters most when the sheet holds personal data. The ICO’s guide to data security says your security measures should seek to ensure that the data can be accessed, altered, disclosed or deleted only by those you have authorised to do so, and that you must be able to restore access to personal data after an incident. A single shared file makes the first of those hard to show.

Start with what Microsoft already gives you

Before paying for a build, check whether a tool you already have does enough. If the workbook lives in Excel, there are three Microsoft routes to try first.

• Share it in Excel for the web. Save the workbook to OneDrive, OneDrive for Business or a SharePoint Online library, and several people can work in it at the same time. By default, anyone in your organisation can use the sharing link to open and edit the workbook.
• Save it as a web page. This is the quick answer to “can I convert Excel to HTML?”. Microsoft’s help for Excel for Mac describes saving a workbook in the Web Page (.htm) format, and is plain about the result: on the web, the data “can be viewed but not changed”. That suits publishing a price list or a timetable, not running a process.
• Build an app on the data with Power Apps. Power Apps can create an app from Excel data, either by uploading the file, which turns the data into a Dataverse table, or by connecting to a workbook that stays in cloud storage. Microsoft asks for the data to be formatted as a table, and Power Apps can connect only to Excel files stored in the cloud. Check what your Microsoft licence covers before you build on it.

One limit catches people out: Microsoft says macros do not run when a macro-enabled workbook is opened in a browser window, so a sheet that depends on them stays tied to the desktop app.

Low-code platforms offer a similar starting point outside Microsoft. Mendix, for example, says that when you drop in a spreadsheet it generates a domain model and data management pages, and imports your data into the app. If one of these routes does the job, use it. A tool your team already understands is better than a custom build nobody needed.

How I would move a workbook into a web app

When those routes don’t fit, because the process has real stages, the data is sensitive or the app has to work the way your business does, this is the order I would work in.

1. Walk through the workbook with the people who use it. Every tab, every column and every colour that means something. Colour-coding and notes in cells are often where the real rules are hiding.
2. Name the records. Write down the things the business actually tracks, such as customers, jobs, orders or documents, and how they relate to each other. This becomes the shape of the database.
3. Turn the formulas and habits into written rules. What makes a record complete? What happens when a job is overdue? Who may close one? If nobody can say, the app can’t either.
4. Agree the stages. List every step a record passes through, from first contact to finished, and who acts at each one.
5. Design the few screens people use every day. A list to find things, a record to work on and a view of what needs attention. See working screens early, and change them while change is cheap.
6. Move the data and check it. Clean the old rows, import them, and check a sample against the spreadsheet with someone who knows it well. Duplicates and half-finished rows turn up here.
7. Run both briefly, then retire the spreadsheet. Set a date, make the old file read-only and keep it for reference. Two live copies of the truth is how the problem started.

Bespoke applications sit alongside websites in how I design and build websites and digital products, and you can see the websites and apps I have designed and built.

When to leave it in Excel

Not every spreadsheet should become an app. Keep the workbook if one person maintains it, if it is mostly analysis rather than a process, or if its shape changes every month. Excel is good at models, what-if sums and one-off reports, and an app would make those slower to change. A pivot table you rebuild each quarter is not a system waiting to be built.

The same goes when the process itself is unsettled. If the team can’t agree the stages or who does what, an app only fixes the disagreement in code. Settle the process in the spreadsheet first, where it is cheaper to change.

When a build does make sense, websites and applications are quoted on scope: the number of page types, the content, any integrations and what happens after launch. I don’t publish a price list. The guide to what moves the price of a website explains why a site with search and data behind it is closer to software than to a set of pages, and costs more.

You don’t need to send the spreadsheet to start. Book a free 30-minute project call to talk through what the workbook does and what an app would need to do, and if a build makes sense, I will set out the scope and fee in a written proposal.