Replacing a legacy configurator without stopping sales
Published · Yotec Configurators
Many manufacturers know their configurator holds them back, but sales depends on it every day. The way out is a migration that never asks sales to stop.
Signs it is time
- Only one person, or only the vendor, can change the rules.
- Small changes take weeks and nobody is sure what else they affect.
- Two people cannot work on the product model at the same time.
- Debugging means guessing, because there are no tests and little logging.
- The platform depends on a single vendor's hosting or roadmap.
Why a big-bang switch is risky
A legacy configurator often encodes years of decisions that nobody wrote down. Rebuilding everything and switching over on a fixed date means discovering missing rules in live quotes. That is how replacement projects lose the trust of sales.
A step-by-step migration
1. Inventory. List the products, rules, inputs and outputs: prices, bills of materials, drawings, exports. Decide which outputs must match exactly and which may improve.
2. Reference cases from real orders. Take a set of past configurations and record what the old system produced for each. These become automated tests for the new code.
3. One product family first. Move the family with the most quotes into code, run the reference cases and fix differences until they match or are explained.
4. Run in parallel. For a short period sales quotes in both systems, or the new one runs in the background and results are compared. Discrepancies are fixed before anyone depends on the new system.
5. Switch and repeat. When the family is stable, sales switches to the new configurator for it. The next family follows the same path.
Where AI helps, and where it does not
AI tools are good at reading old rule files and scripts, summarising them and drafting equivalent C# code. They are not a substitute for verification. The reference cases decide whether the new logic is right, not the model that wrote it.
What you get at the end
Product rules in a standard .NET project with version control and tests, which any C# team can maintain, and that you own. Changes become normal software changes that can be reviewed, tested and released.
We usually start with a pilot on one product family in 8–12 weeks. Tell us about your current configurator.