When a spreadsheet becomes software: moving an Excel process into a web application

A spreadsheet is a sensible place to start a process: it is quick, flexible and familiar. The trouble starts when the file becomes the process itself, with several people working in it, copies in inboxes and nobody quite sure which version is right. This article is about that moment, and about what it takes to move the process into a web application.

When has a spreadsheet outgrown its job?

When it has become a shared system it was never built to be. The signs: several people edit it, copies travel by email, nobody knows which version is current, errors surface weeks later, only one person understands the formulas, and the same data is typed again into another tool. Two or three of these together are a clear signal.

• Copies that drift apart: "Offers_final_v3.xlsx" sits next to "Offers_final_v4_new.xlsx", and both are in use.
• Errors found late: a formula pointing at the wrong row, an entry in the wrong column, a filter left on.
• Knowledge in one head: the process works because one colleague knows which cells not to touch.
• Typing it twice: the same customer or order is entered again in the accounting.
• Personal data in a file that travels: customer or employee details sent around by email.

Spreadsheets can also fail quietly. In October 2020 the BBC reported that nearly 16,000 coronavirus cases had gone unreported in England because test results were collected in an old Excel file format. Each file "could handle only about 65,000 rows of data", and "when that total was reached, further cases were simply left off". Current versions of Excel hold 1,048,576 rows per worksheet, so the lesson is less the limit than the missing check: a process that matters needs checks built in, and a spreadsheet does not bring them by itself.

What changes when the process becomes software?

The data lives in one place, and everyone works on the same current version. Each person sees and changes only what their role allows. Entries are checked as they are made, the steps of the process are built in, and each change is recorded with who made it and when. Reports come from the same data instead of from copies.

• One place for the data: a customer's address is changed once, and every screen and report shows the new one.
• Rights per role: the field team enters hours, the office approves them, the owner sees the totals.
• Checks at entry: a date must be a date, an order needs a customer, a discount above a set level needs approval.
• A history: who changed what, and when.
• Every device: a web application runs in the browser, on a phone on site as well as on the office computer.

If the spreadsheet holds personal data, the Swiss Data Protection Act requires "a level of data security appropriate to the risk", by "suitable technical and organisational measures" (Art. 8). Rights per role and a record of changes are practical ways to work towards that; a file copied from inbox to inbox makes it harder.

Something is lost, too. In a spreadsheet anyone can add a column in a minute. In software, a new field is a change that is planned, built and tested. That is the price of the checks, and a good reason to move only the parts of the process that need them.

What should you decide before anything is built?

Which part of the process moves first, who works in it and with which rights, which data comes along, which rules the software must enforce, and what stays in Excel, such as an export for the accountant. The answers are what the software is built from, so they are best worked out with the people who use the file every day.

• Whether to build at all: a standard tool may already cover your process; see custom software or an off-the-shelf tool. For forms, lists and simple processes, a no-code tool can be enough; see no-code, low-code, vibe coding or custom software.
• The first part: start with the part of the file that causes the most trouble, not the whole workbook.
• The rules hidden in the file: every formula, colour code and comment column is a rule someone relies on. List them, and decide which ones the software enforces and which ones go.
• People and rights: who enters, who approves, who only reads.
• Connections: whether the data has to reach your accounting, for example bexio or Abacus.
• What stays in Excel: ad-hoc analysis can stay in a spreadsheet, fed by an export from the new software.

How does the data move over?

In three steps: clean, match and check. First the existing data is cleaned: duplicates merged, gaps filled, formats made consistent. Then each column is matched to a field in the new software. Finally the import runs in a test version and is checked against the spreadsheet, record counts and totals included, before the real switch.

Things to look for when cleaning: the same customer spelled three ways, dates typed as text, amounts with the currency in the cell, merged cells, and meaning kept in colours or comments. Colours need special care. When Excel saves a sheet as a CSV file, Microsoft's own help says it saves "only the current worksheet" and that "some features might be lost". So whatever a colour or a comment means has to become a field of its own before the move.

The switch itself needs a date. From that day the software is the only place where the process happens. The spreadsheet is kept, read-only, as an archive, so there are never two versions of the truth.

What does the team need to learn?

Less than they fear, if the software follows the way they already work: their own terms on the screens, their steps in their order. What takes real practice is a change of habit: entering data in one place, at the moment it happens, instead of collecting it in a file to tidy up later.

• Involve them early: the people who use the file every day know its exceptions.
• Let them try it first: before we build, you get a prototype that shows how your software will look and feel, and later the finished software runs in a test version you can try before it goes live.
• Name a go-to person: one or two colleagues the others can ask in the first weeks, with a short written guide.
• Pick a quiet time: switch over in a calm period, not during the month-end closing.