From Excel to Configurator: 12 Mistakes to Avoid

Almost every product selector and configurator we build starts the same way: with a spreadsheet. Someone in engineering or sales built it years ago, it has grown ever since, and today half the company quotes with it. It works — mostly. And now it is supposed to become real software.

That is a good decision. But the way the move is made decides whether you end up with a better tool or with the same spreadsheet, only more expensive. These are the twelve mistakes we see most often.

The basic mistake: copying instead of rethinking

The most common request is: “It should work exactly like the Excel file, just as software.” It sounds safe. It is the fastest way to make legacy worse. Every workaround, every hidden column and every manual step is carefully rebuilt — and now it is harder to change than before.

A spreadsheet is a snapshot of how someone solved a problem years ago, with the tools they had. It is a source of knowledge, not a specification.

Before anything is built, find out what the file actually contains: visible logic, hidden sheets, macros, lookups into other files, formulas nobody dares to touch. Most spreadsheets do three or four things at once — selection, calculation, pricing, documentation — and each of them belongs somewhere different.

Every mature spreadsheet carries dead weight: series that have not been sold for years, options nobody chooses, columns whose purpose nobody remembers, special cases for one customer from 2017. Be brave enough to delete them. Every line you remove is a line that never has to be built, tested or maintained.

A useful rule: if nobody can explain why something is there, and no quotation of the last two years used it, it goes. If it turns out to be needed, it can be added back — properly this time.

The spreadsheet shows how quoting works today. It does not show how it should work. Ask what the process is supposed to achieve, then design the tool for that — not for the steps the spreadsheet happens to require.

Use what already exists

In the spreadsheet, prices live in a tab that someone updates by hand. In the new system they should come from where they are already maintained: the pricing system or the ERP. A second price list is a second version of the truth — and it will drift.

Article numbers, descriptions, stock levels, lead times, customer data: almost all of it already exists in the ERP or the CRM, and those systems usually have interfaces. Use them. Copying data into the new tool recreates exactly the manual work the project was meant to remove.

Each line in this table is a manual step that disappears — and a source of errors that disappears with it. Why product data should live outside the configurator is covered in Your Configurator Should Not Own Your Product Data.

A spreadsheet mixes declarations and calculations in the same cells. In a configurator they belong in different places: options, dependencies and prices as data, calculations as tested code. Translating every formula literally produces a rule set nobody can read. The line between the two is explained in Product Rules Belong in Data. Computation Belongs in Code.

Spreadsheets tolerate inconsistency: flow in m³/h in one column and l/s in another, sizes written three different ways. Software does not forgive it. Clean it up during the move — one declared unit per quantity, one notation per value.

People and process

The author knows the logic. The people who quote with it every day know where it hurts, what they work around and what they would never miss. Talk to both — and involve the users before the new tool is built, not at go-live.

A big switch-over on one date is risky and slow. Move series by series: the first product line goes live, sales starts using it, the next one follows. Problems stay small, and the team gets used to the new tool step by step.

Take a set of real quotations from the last months and calculate them in both systems. Where the results differ, find out why. Some differences are errors in the new system — and many are errors the spreadsheet has been making for years. Decide consciously which result is right.

The last step is the hardest

This is the mistake that undoes all the others. As long as the old file is still on the drive, people will use it — out of habit, out of convenience, because it is faster for the one case they know by heart. Prices get out of step, two systems run in parallel, and the new tool never becomes the only truth.

So set a date, archive the file read-only where nobody quotes from it, and remove it from the places people open it. Then the new system is not one option among two. It is how quoting works.

Removing the spreadsheet is not a technical step. It is the decision that the project is finished.

A short checklist for the move

• Analyse what the spreadsheet really does — including hidden sheets and macros.
• Delete what nobody can explain and nobody has used.
• Take prices and master data from the systems that already own them, via their APIs.
• Separate data from calculations instead of translating formulas one by one.
• Move series by series, and compare results on real quotations.
• Set a date — and then really remove the spreadsheet.