Replace Excel with a web application once a spreadsheet has quietly become a business system. You'll recognise it by several people editing one file, versions travelling by email, and formulas only one colleague understands. A business web application then gives you one current source, roles and permissions, checks on input, and a history of every change. Analysis and exports stay in Excel.
Below is a table of eight signs and what each one means in practice. After that comes a list of what moves and what stays in Excel, followed by the move itself in five steps with two common pitfalls. Throughout, a web application means business software, such as a planning tool, an order overview, or a portal for customers and suppliers. For the basics, read what a web application is.
Eight signs it's time to replace Excel with a web application
Most spreadsheets start as a handy overview kept by one person. Years later, planning, stock, or invoicing depends on it, and nobody ever decided that it should. A planner opens the file, sees that a colleague has it open, and saves a copy with their own initials at the end.
The eight signs below show that the file is doing work it was never made for.
| Sign | What happens in practice | What a web application does differently |
|---|---|---|
| Several people work in the same file | Changes overwrite each other, or colleagues wait until the file is free | Everyone works in the same data at once and the application saves each record separately |
| Versions travel by email | Two departments decide on different numbers and nobody knows which version counts | There is one current source and no file left to send |
| Nobody dares to touch the macros | The process adapts to the file, because any change might break something | Rules live in tested code, so you can change them safely |
| One colleague understands how it works | Holidays, illness, or a resignation bring the work to a halt | How it works is documented and can be handed to a team |
| Everyone can see and change everything | A wrong sort or a deleted formula goes unnoticed for weeks | Roles and permissions decide what each user can see and change |
| Nobody knows who changed what | An error can't be traced afterwards, so everyone checks everything again | Every change is stored with a name and a time |
| Input goes unchecked | The same customer appears three times under different spellings, and reports stop adding up | Required fields, fixed lists of options, and checks stop wrong input |
| Data gets retyped | Someone copies orders, hours, or stock from another system, with double work and typos as a result | Integrations fetch and send data with no retyping |
One sign can often be fixed inside Excel itself, for example with a fixed list of options or a clear agreement on who maintains the file. If you recognise three or more, the file is doing the work of a system with none of the safeguards of a system. A spreadsheet like that closely resembles a legacy system: it still runs, everyone depends on it, and nobody dares to touch it.
How often it goes wrong
Spreadsheet errors are common. In 2015, Raymond Panko of the University of Hawaii compared the results of intensive inspections of 85 operational spreadsheets, taken from studies published between 1995 and 2001. Errors turned up in 94% of those spreadsheets. Errors are rare per cell, he writes, yet in a large file at least one wrong result is very likely.
Sometimes an error like that makes the news. In early October 2020, the BBC reported that nearly 16,000 coronavirus cases had gone unreported in England. Public Health England, a government agency, collected test results in Excel templates using an old file format that holds about 65,000 rows. A spreadsheet had become a fixed link in a chain there.
Why it goes wrong: Excel as a database
The eight signs often share one cause: the file is being used as a database. According to Microsoft, Excel is built for data analysis and calculation. Data that refers to other data, such as orders and customers, isn't supported, its maker writes. As a result, Excel can't guarantee that every order belongs to an existing customer.
For data that has to stay consistent while several users work with it, Microsoft itself points to a database. A business web application is that kind of database, with screens that fit your work. The data sits centrally on a server and users log in through the browser. The application checks every entry, knows who may do what, and records every change.
Through an integration, it exchanges data with your accounting, ERP, or planning software. How that works is explained in what an API integration is.
What moves and what stays in Excel
Replacing Excel rarely means Excel disappears. It remains strong at calculating, exploring, and presenting. The test is simple: data that lives in the file moves. Data you only look at in the file stays.
This moves to the web application
- Data that several people enter or update, such as orders, schedules, stock, and registrations
- Steps with a status or an approval, such as a request that goes past a manager
- Calculation rules that a delivery time, schedule, or quote depends on
- Data that another system needs or supplies
- Anything where you later want to see who changed it
This stays in Excel
- Ad hoc analyses and explorations on an export
- Pivot tables and charts for a meeting or report
- Scenarios that one person works through
- Personal lists and rough notes
- Files that a customer or supplier wants to receive in Excel
That's why a good web application has an export button. You pull the current data, do your calculations in Excel, and throw the file away afterwards. The application remains the source.
Before you commission an Excel replacement, check whether standard software covers your process. For accounting, customer relationship management, or time tracking, that's often the shortest route. A custom web application suits a process that is specific to your organisation. That's usually also why it ended up in Excel in the first place.
Moving from spreadsheets to software in five steps
The move takes five steps. The first two each come with a common pitfall.
1. Take stock of everything the file does
Open the file together with the colleague who maintains it and walk through an existing order, request, or schedule from start to finish. For each tab, note who uses it, which data goes in, and which decision comes out. Look at what stays out of sight too: hidden columns, macros, conditional formatting, and references to other files. How to map a flow like this is covered in digitising a business process.
Pitfall: business rules hidden in formulas. A formula with three nested IFs sometimes holds an agreement that is written down nowhere else. One customer group gets a different delivery term, a quantity is rounded up, or a red cell means the planner has to call first.
Skip those rules and you get an application that looks right and produces different results from the file. Write each rule out in plain language and have the users confirm that it still applies.
2. Design the data model
A data model describes which kinds of data exist and how they relate. In the file, everything sits in rows and columns, while in the application these become separate tables, such as customers, orders, and order lines. Each fact is stored in one place, so a customer's new address is correct everywhere at once. In the same step, define which roles exist and what each role may see and change.
Pitfall: rebuilding the spreadsheet one to one. A screen with 40 columns and the same tabs as the file feels familiar, and it brings every limitation along. Take the process as your starting point: who does which step, with which data, and what happens next. Often, some of the columns turn out to be helper columns that the application can calculate itself.
3. Build the core first
Start with the part most people work in every day, and save exceptions and reports for later. A first version that handles one flow from start to finish delivers more than 10 unfinished screens. Show users regularly what has been built and act on their feedback. They know the exceptions that appear on no tab at all.
4. Import the existing data
The data in the file comes along, and that takes cleaning. Expect duplicate customers, dates entered as text, merged cells, and columns that changed meaning halfway through. Run the import several times as a trial and let users take samples.
Open cases always come along. For older years, the old file often works well as an archive that can only be read.
5. Run both side by side for a short period
Let the file and the application run side by side for an agreed period. During those weeks, compare the results, for example the weekly totals or one department's schedule. Every difference is either a rule you missed in step 1 or an error that had been sitting in the file for some time.
Running both side by side means double work, so keep it short. Agree in advance which system is leading and on which date the file closes. After that date, lock the file against editing. If it stays editable, a shadow version will soon appear.
From spreadsheet to business software
You don't have to replace Excel on your own. Isatis works with teams in Nijmegen, in the Netherlands, and in Sarajevo. We've been building software for more than 30 years, with 30+ engineers and more than 100 projects, and we're certified for ISO 9001 and ISO 27001.
Read how we approach custom software development. To talk through your spreadsheet and the options, book a conversation.
Frequently asked questions
When should you replace Excel?
As soon as the file has become a system. The signs are several users in one file, versions sent by email, macros nobody dares to change, and one colleague who knows how it works. If you recognise three or more signs from the table, it's time to look into the move.
What is a good Excel replacement?
That depends on the process. Standard software exists for standard work such as accounting or customer relationship management. For a process that is specific to your organisation, a custom business web application fits, with a database, roles, and integrations.
Can you use Excel as a database?
For a simple list kept by one person, yes. Excel doesn't enforce relationships between tables, so you get stuck once several users and related data are involved. Microsoft itself points to a database for that kind of data.
How long does it take to go from spreadsheet to web app?
That depends on the number of tabs, calculation rules, and integrations. The inventory and the data model make the scope clear. If you start with the core, you'll have a working first version sooner than if you try to replace everything at once.
Do you keep using Excel alongside the web application?
Yes. Excel stays useful for analysis, pivot tables, and scenarios on an export from the application. The application is the source, and the Excel file is a temporary copy to calculate with.
