How to replace Excel with business software

That file is your best specification

Before talking about replacing it, you have to understand why it won. A spreadsheet is available immediately, everyone can use it, and it matches the team's way of working exactly, because the team built it.

That is a considerable advantage, and it explains why so many serious pieces of software end up replaced by a shared file. The software imposed a process, the file followed yours.

A spreadsheet that has run an operation for three years is therefore not an organisational failure: it is a functional specification written by users and validated by use. No specification drafted in a meeting reaches that level of precision.

One regularity holds across almost all of these files: a small share of the columns carries most of the daily use, the rest being history, intermediate calculations and columns nobody fills in any more. Telling them apart is a replacement project's first value.

The signs that justify a diagnosis

The moment to switch shows up as operational symptoms, not technical ones.

• Several people need to write at once, and someone arbitrates versions.
• A column exists to record who did what, because the file does not know.
• Important rules live in formulas only two people understand.
• The file feeds something else, billing or scheduling, by copy and paste.
• Several copies exist and nobody knows which is authoritative.
• An entry error has already had a visible consequence for a customer.
• Someone regularly spends time consolidating versions and correcting discrepancies.

Three of these signs together do not settle anything on their own, but they indicate a diagnosis is worth doing. The criterion that decides afterwards is not the size of the file: it is the number of people who depend on it without being able to verify it.

What a tool brings that a file cannot

Business software is not a prettier spreadsheet. It brings four things a file structurally cannot.

• Rights: each person sees and edits what concerns them, and only that.
• History: who changed what, when, and what the previous value was. Often the most appreciated benefit, and the least anticipated.
• Rules at entry time: an end date before the start date is refused on entry, not discovered three weeks later.
• Connections: the tool talks to management, to billing, to the website, with no copy and paste.

Time savings come next, and they are real, but they come second. The first benefit is reliability: information nobody has to check is current.

The real risk: being less flexible than the file

Replacement projects that fail almost never break down. They are abandoned, and always for the same reason: the tool is less flexible than the file it replaces.

In a spreadsheet, adding a column takes fifteen seconds and asks nobody's permission. If the same operation takes three weeks and a quote, the team will open a file alongside for the new information. And they will be right: their work does not wait for the next sprint.

From there the script writes itself. Two sources coexist, the tool empties of its substance, and six months later someone notices everyone is back on the spreadsheet. The project did not fail technically, it failed on flexibility.

The remedy is decided at design time, not afterwards. List from the start what the team will be able to change on its own: dropdown lists, labels, document templates, thresholds, simple rules. Anything changeable without a developer is not invoiced and frustrates nobody.

That is the first criterion we look at on this kind of project, before the features: what will the team be able to change on Monday morning without calling us?

The transition, in the order that works

The effective method is the opposite of the one people imagine: you do not reproduce the spreadsheet, you first take over its daily use and nothing else.

• Observe. Half a day watching the team use the file teaches more than three framing meetings.
• Isolate the columns that carry the real use, and leave the rest aside.
• Migrate the active data, the rows that moved within the year, not ten years of history. A migration project then becomes a few hours of import.
• Deliver a first version in service after a few days, used alongside the file.
• Extend from use. The real gaps announce themselves within a fortnight, and they are never the ones that were listed.
• Close the file. The step that counts: as long as the spreadsheet stays editable, the tool does not become the reference.

A useful precaution: keep the spreadsheet read-only for a few months. Nobody goes back to it, but knowing it is there removes half the resistance.

Timelines and budget

An internal tool taking over a shared spreadsheet, with a few roles and one data source, goes into production in one to two weeks and sits on average between 3,000 and 10,000 euros, with no upper limit.

Three things push that number up: the number of connections to other systems, migrating the full history, and the number of exceptions to the rules. Exceptions weigh more than people expect.

Three things bring it down: accepting conventional screens, deferring statistics to a second stage, starting with one department rather than all of them at once.

The payback calculation is often immediate, and it is based on the time the team spends on the file today, without counting the errors avoided, which are harder to quantify but rarely negligible.

Why exceptions cost so much, and how to read a quote: what custom software costs

Where to start

Take the most shared file in the company, the one several people depend on every day. Look at who opens it, how often, and what each of them actually does in it.

That observation is enough to define a starting scope and estimate a budget. Above all it avoids the most common mistake, trying to take everything over at once when half the columns of an old spreadsheet no longer serve anyone.

And ask the flexibility question before the feature question. A tool slightly less complete than planned, but which the team can adjust itself, settles in for years. The reverse does not last six months.