Replacing Excel with software: what stays, what goes, and what to clarify first

The hint is often in the file name: "Planning_final_new_Version3". Next to it sits "Planning_final_new_Version3_Copy", and everyone in the office knows that only one of the two is correct. Whoever opens them first asks in the hallway whether someone is working in it right now. In this scenario we assume a small business whose orders, appointments and calculations all converge in a single workbook.

The workbook is not badly built. It has grown over the years, and every extension was reasonable: a column for the status, a sheet for materials, a macro that turns rows into a quote. Together they form a system that works as long as one particular person operates it. When that person is absent, you only then realize how much knowledge sits in cell colors, filter settings and hidden columns.

The question is therefore rarely "Is Excel bad?". It is: when does the worksheet cost more than it brings, and what do we lose if we replace it? Anyone who wants to replace Excel with software should ask this second question first, because the answer decides whether the project succeeds or merely produces a new tool with the same old errors.

Add to that a moment many businesses know: a new employee is supposed to enter data and asks which column means "delivery date" and which "requested date". The answer is "You can tell by the color". Such sentences are harmless as long as the person who can explain them is there. They are a warning sign when the knowledge sits in a single place.

Excel rarely fails because of computing power, but because of concurrency and bindingness. Two people enter changes on the same morning, one version overwrites the other, and it only becomes apparent when a delivery is missing. Even with shared editing in the cloud the basic problem remains: every cell may contain anything, and nobody checks whether a date is really a date.

Add the invisibility of the rules. A formula refers to a hidden sheet, a macro converts values on saving, conditional formatting turns rows red that are older than ten days. Nobody ever formulated these rules as a requirement, and yet people rely on them. In a replacement, these are the places that get lost without warning.

Finally, traceability is missing. Who changed the price in row 214, and when? Excel can track changes, but in daily use the log is patchy or switched off. For businesses that keep quotes, inspection reports or customer data, this is more than a convenience question, because it touches liability, complaints and data protection.

A replacement begins with sorting. Excel is excellent for individual analyses, scenarios, quick calculation models and evaluations where someone explores data. It is weak with data that many people maintain at the same time, that must enforce rules and that need a history. Anyone who mixes both in one file has usually found the cause of the problem.

A useful distinction separates capturing, processing and analyzing. Capturing and processing belong in an application with forms, mandatory fields, permissions and a log. Analyzing may stay in Excel, fed from a clean export. That way employees keep the familiar tool where it needs freedom, and the data gets discipline where freedom produces errors.

Not every spreadsheet deserves software. A list with a few entries that one person maintains once a month is well kept in Excel. A replacement pays off where many people change the same data, where errors cost money or trust, and where processes repeat regularly. We would honestly name which files in the business can deliberately stay.

A touchstone is the question of who would have to take over the file tomorrow. If a new colleague can operate it safely after a week, the structure is sound. If she needs months and oral tradition, the file is already an operational risk, regardless of how well it calculates.

The tempting route is the big bang: the workbook is rebuilt, switched over on a cut-off date, and Excel is turned off. In our experience this fails on two things. First, the functional scope of the old workbook is larger than it looks. Second, a cut-off date brings pressure at exactly the moment when the first errors appear. We would choose this route only for very small, manageable files.

A replacement in slices is better suited. First the area is switched over that causes the most problems and has the clearest rules, such as order entry. The analyses initially stay in Excel and read from the new source. Each slice delivers a working state on its own, and the team learns from a manageable example instead of having to absorb everything at once.

Standard software is an alternative, such as a ready-made order management tool or a low-code builder. This is often the right choice if the business's processes are fairly common anyway. Custom software pays off when your own rules make up the competitive advantage or no product reflects them. We would compare both and leave the decision to the business, not to the vendor.

A third option is to keep Excel and build it with more discipline: separate input and calculation sheets, data validation, protected formulas, a central storage location with clear responsibility. That is cheap and fast, but reaches its limits as soon as many people work at the same time or permissions and a log are required. As an intermediate step it can make sense, because it makes visible the very rules that a later replacement needs.

The most important work step is unremarkable: we read the workbook like an expert assessor. Every sheet is checked for what it stores, what it calculates and what it relies on. Hidden, protected and linked items are made visible, and macros are described line by line. The result is not a program but a list of rules in plain language that the business can proofread.

Three kinds of rules come to light. There are explicit rules, such as "discount from ten units". There are implicit ones that apply only through habit, for example "orders with a red background are processed first". And there are error compensations, where the workbook calculates something wrongly and employees correct the deviation in their heads. This third kind must not be adopted unchecked.

As a safeguard, we interview those who work with the file every day, and not only management. Questions such as "What do you do when the number is wrong?" bring out what no document reveals. From both sources a list emerges that is decided on together: this rule stays, this one is simplified, this one is dropped because it was only a workaround.

This yields a side benefit that has nothing to do with software yet. The business learns how it actually works and can decide whether that is as intended. Some replacements become smaller as a result, because a superfluous rule disappears before it is cast into code.

During the move you see how forgiving Excel is. The same column contains "12.03.2024", "March 24" and "12/3". Names appear with and without titles, amounts with comma, period or currency symbol in a text field. A database demands uniqueness, which is why data cleansing determines the quality of the new system more than any interface. Plan a considerable share of the project time for it.

Technically, the migration runs in scripts, not by hand. The data is read in, checked, normalized and written into the target structure. Rows that violate a rule end up in an error list that specialists in the business work through. After each run we compare counts, totals and spot checks with the source. Duplicates and orphans are decided deliberately, not deleted silently, and the original remains unchanged as an archive.

The application consists of a few building blocks. A database stores orders, customers and line items in separate tables, an application layer enforces mandatory fields, permitted status transitions and calculations in a single place, and a web interface reflects how the business works. Permissions are thought of in roles: dispatch changes appointments, accounting sees figures but no customer communication. Whoever does not need data does not see it; the business clarifies the details with its data protection advisor.

A change log records the user, the time, and the old and new value, including for deletions. “Who changed this?” becomes a look at the history. Export stays a standard feature: every list can be output as a CSV or Excel file, and the data is stored in an open format. That keeps the business independent of the vendor, and analyses can carry on in Excel.

The transition is the moment when projects tip over. We would run old and new in parallel for a limited period: the same transactions are recorded in both systems, and a regular reconciliation shows discrepancies. This costs time and is unpopular, but it uncovers rules that were missed during the inventory. Every discrepancy is a finding about either the new system or the old workbook.

How long the parallel operation lasts depends on the rhythm of the business. If you invoice monthly, you should see at least one complete billing run in both systems. A clear fallback option is also needed: as long as the reconciliation shows open questions, Excel remains the leading source; after that the lead changes, and the old workbook is set to read-only, not deleted.

You don’t win over staff with training slides. It helps to involve the people who work with the workbook every day early on, and to take their workarounds seriously. A shortcut that someone invented usually points to a real need. Short introductions using real cases, a contact person in the company and a point of contact for questions in the first weeks have more effect than comprehensive manuals.

It is also worth talking honestly about resistance. Someone who has been efficient with a file for years loses speed at first in the new system. This effect is normal and temporary, but it should be planned for, for example by relieving people during peak periods. Anyone who hides it creates mistrust, which later harms the project more than the learning curve.

A special case is macros that call external programs or generate documents. Here it is not enough to read the code; you have to know the result: what does the quote the customer receives look like, and what must never change about it? Such outputs are rebuilt as templates and compared sentence by sentence with old documents before the first real transaction runs through them.

Software promises no miracles, but it eliminates certain classes of errors. Version conflicts disappear because there is only one data state. Invalid entries are caught at the form instead of being discovered in the report. Changes are traceable, and permissions limit the damage an oversight can cause. These are structural improvements that do not depend on how someone is feeling that day.

The benefit becomes measurable through figures that the business itself defines before the project starts. These include the number of corrections after data entry, the time for month-end closing and reports, the number of follow-up questions caused by unclear versions, and the time until new employees work independently. A baseline from the weeks before the switch is important; otherwise every later statement remains a feeling.

What cannot be promised: specific time savings in hours or percent before the processes are known. It would also be dishonest to claim that everyone involved will love the new system. A realistic goal is that the work becomes more reliable, the business depends less on individuals, and data remains available. Whether this pays off becomes clear over several months, not in the first week.

Against this stand ongoing costs that should be addressed openly. An application needs hosting, updates, backups and occasional adjustments when processes change. Excel seemed free because the follow-on costs were hidden in working time and errors. The comparison is only fair once both sides are set out honestly.

The quality of the data itself also becomes a yardstick. After the switch you can count how many records contain all required information and how many entries had to be corrected afterwards. These numbers are uncomfortable because they show weaknesses that Excel silently concealed. But they are exactly what a business needs to improve its processes in a targeted way instead of just putting up with errors.

A few principles can be derived from the method. First: the rule list is more important than the code. Whoever maintains it properly can extend the system later without having to dig up the knowledge again. Second: cleaning the data is a subproject of its own, with its own responsibility in the business, not a by-product of programming.

Third: small slices beat big leaps. An area that runs cleanly within a few weeks builds trust and delivers insights for the next one. Fourth: don’t declare Excel the enemy. Leaving the file in place as an analysis tool removes resistance to the project and preserves a proven capability. Fifth: export is part of the system from the start, because it secures independence.

The cases in which a replacement is not advisable are just as instructive. If the processes themselves are still unclear, software will only cement them. If the file is kept by one person for one person, a better-built worksheet with input validation and brief documentation is often enough. That, too, is a legitimate outcome of a consultation.

Another principle concerns responsibility after launch. An application is not an object you accept and forget. Someone in the business needs to collect requests, maintain permissions and prioritize feedback; otherwise a sprawl of special solutions quickly grows again in the new system, only in a different form. This role does not have to be big, but it should be named and given some time.

Replacing Excel with software is rarely a technical task and first of all an organizational one. You need to know what your workbook actually does before you can judge what a successor has to deliver. The replacement succeeds when rules are documented, data is cleaned, transitions are planned and people are involved. It fails when you build an interface and hope the rest will sort itself out.

A first step costs little. Open your most important workbook and note who edits it, which sheets are hidden and which macros run. Ask two colleagues what they do when a number is wrong. With this list you can decide soberly whether a replacement is worthwhile, whether a better Excel file is enough, or whether the processes should be clarified first.

We are happy to look at such a workbook with you and give a clear assessment of what should be replaced, what may stay and what effort to expect. We make no commitment on savings until the processes are known.

Plan soberly: a replacement takes longer than the first impression of the workbook suggests, because the hidden rules only surface while reading it. A clearly defined first phase with a fixed scope is therefore a better entry point than an overall quote for everything.