A Change to a Pricing Rule Should Not Be a Leap of Faith. Here Is the Benchmark We Would Set.

Sales has asked for a simple change. Freight on orders to the northern region should be charged at a new rate from the first of the month.

The developer finds the freight rule in a program beside the ERP, changes one figure and tries three orders. All three look right. The change goes live on a Friday afternoon.

At month end, accounts notices that the margin on export orders is two points lower than usual. It takes a week to find out why. The export price calculation borrowed a figure from the freight rule. Nobody knew. Nothing showed an error.

What We Found

For this article we went through the public record on what a change to an old, much-customised system has to respect: a vendor’s account of one heavily customised system being replaced, a vendor’s article on one older ERP product’s support dates, and one survey on why firms hold back. None of it is about manufacturing.

The connections a change has to respect are many. A group of credit unions shared one heavily customised core system, which was due to be retired in 2024. Replacing it meant building hundreds of new screens and hundreds of APIs for its links with other systems. This is finance, not a factory, and the source is a vendor’s case study.

The largest change is already dated. For one widely used older packaged ERP product, mainstream maintenance ended on 31 December 2025 for some versions, and ends on 31 December 2027 for others, with a paid extension to 31 December 2030. The source sells support for the product. Every program built around such an ERP will have to work with whatever follows it: the freight rule above, many times over.

Fear of disruption holds change back. In one survey of about 500 IT professionals in the US, run by a firm that sells software services, more than a third named fear of disrupting operations among their reasons for not modernising old systems. The survey covers every sector, not manufacturing alone.

Our reading is narrow. In old programs, rules are rarely separate. They were written by different people over many years, so one calculation borrows a figure from another and the link is recorded nowhere. When nobody can see the links, the careful answer to a change is no, or next quarter.

What Opens Up When Every Rule Has a Place and an Owner

Our reading is that a change to a pricing rule is a business decision, usually taken without the facts.

• A rule can be changed knowing what it touches. With each rule written down with what it uses and what uses its result, the developer and the rule’s owner can see what a change will reach.
• An ERP move has something to be checked against. Each rebuilt part can be checked against a written list of rules.
• Progress can be counted. The number of rules that live only in old, unread programs is a figure the board can watch fall.

This is our reading. It is not a measured market figure.

Three Ways to Know a Rule Survived a Change, Weighed

Option	When it fits	What it risks
Try a few orders, and watch the month-end figures	The change is small and the rule stands alone	The first complete check is the accounts, weeks later, on real invoices
Your own team builds tests that record what each rule gives today, and runs them with every change	The firm has a team that will build the tests, choose the cases and keep them up to date	Tests protect an old mistake as faithfully as a good rule, cover only the cases chosen, and need real order records handled with care
Write every rule down with what it uses and who owns it, then rebuild module by module, each rule linked to its replacement in a traceability matrix	The rules are many, old and linked, and the programs around the ERP are due to be rebuilt or moved	It takes longer on the calendar, and the rules’ owners must give time to confirm them

Where You Are Now, and Where You Should Be

This is the benchmark we would set before the first module moves, and fill in as each module is accepted.

Measure	Typical starting point	Where it should be	How it is checked
Rules in the programs around the ERP	Known only as behaviour	Each written down in plain words, with where it lives	The specification and the map of the system
What each rule uses, and what uses its result	Not recorded	Recorded for each rule	The specification
An owner for each rule	Nobody named	A named owner in the business, or the rule marked as having none	The specification, confirmed by your own people
Rules confirmed by their owners	None	Every written rule confirmed, or listed for the business to decide	The record of confirmations and the risk register
Each rebuilt module’s rules	Checked on a few orders	Each rule linked to its replacement	The traceability matrix
Rules still only in the old programs	Not counted	Counted, and falling at every stage	Reported at every review
Rules inside the packaged ERP itself	Mixed in with the rest	Listed as outside our work, for your ERP specialist	The map of the system

The starting points above are what we expect to find. In an engagement they are replaced by your own position, taken in the first review. The targets are what we would work towards with you. They are not results we have already achieved for a manufacturer.

A small part of the filled-in benchmark might look like this.

Module	Rules written down	Owner	Status
Freight charges	14 rules, one borrowed by the export price	Head of logistics	Accepted; old freight report retired
Customer special prices	23 rules, 3 with no owner, listed for the business to decide	Head of sales	Under review; old price program still running
Overhead by product family	9 rules written down, not yet confirmed	Finance head	Waiting; old costing report still running

The rows above are an illustration, not taken from a real firm.

How We Work With You, and What You Are Left With

1. We listen: a free Reliability Review. A first conversation about your programs and the changes that keep being put off. You leave with a short written note of what we found. You can start with a conversation about the system; we ask for read-only code access only when the assessment begins.
2. We research. We research your sector, the regulator’s position and what the public record says about firms in your situation. This article is an example of that work.
3. We read the system and propose: the Legacy System Specification Assessment. Here the system is the custom reports, add-on programs, database procedures and tools that feed figures in, which you built or had built around your ERP. It produces a map of the system as it stands, a written specification of what it does, a risk register, a cost comparison between keeping and replacing the system, and a staged plan with a fixed quote. AI does a first pass, our senior engineers review it and trace it to the code, and your own experts confirm it. Code access is read-only and logged, never used for training, and deleted within 30 days of the evaluation ending unless we engage. You get the options and our recommendation.
4. If you approve, we build. We replace a system one module at a time while the old one keeps running. Here that means the programs around your ERP, rebuilt one module at a time, with each rule in the module linked to its replacement. We never do a single cutover. A traceability matrix links every old function to its replacement. The work is billed by milestone, each milestone tied to a module you accept, and you can pause after any accepted module.
5. We review against the benchmark. Before work starts we set the benchmark above. As each module is accepted we show you where each measure stands, and the filled-in benchmark is yours at the end.

The Review is free. Every paid step is fixed price, agreed at scoping. Stop after any step. The findings are yours. The assessment fee is credited in full against the first build stage if it starts within 90 days of the report.

This has a price. Having each rule’s owner confirm it takes your people’s time, and the work takes longer on the calendar than a quick change. A module whose rules all match can still disappoint, and we promise nothing more. We write down what a rule does, not whether it is right; we are not costing, tax or accounting advisers, and if a rule turns out to have been wrong for years, what to do about the past is for your own finance and legal advisers. We do not read, change, convert or test customisations inside a packaged ERP product, and we do not install, configure or upgrade one; those rules are for your ERP specialist. We do not keep the old programs running, maintain them or secure them; your own team or supplier does. We have no published case of this work for a manufacturer.

At the end you hold the specification, with every rule, where it lived and who owns it; the traceability matrix for every module we rebuilt; and the filled-in benchmark.

What changes for the business:

Role	What they gain
CEO	A new price or customer term can be agreed knowing which other rules it reaches, before the change goes in.
CTO or CIO	Each rebuilt module carries its rules across one by one, with a record the ERP move can be checked against.
CFO	A change to a cost or a price is weighed against a written list of what it touches, not discovered in the month-end margin.
COO	Dispatch and planning hear about a rule change from the rule’s owner, with a record of what it reaches.
Head of risk or internal audit	A record, module by module, of which rules were confirmed, by whom, and how many still live only in old programs.

The cases in this article, and what IOanyT does about that kind of problem:

The case	What IOanyT does
This article names no organisation. Its figures come from a vendor’s case study of a group of credit unions, a vendor’s article on one ERP product’s support dates and one vendor survey, none of them about manufacturing.	We write down the rules in the programs a firm built around its ERP and, if it approves, rebuild those programs one module at a time, each rule linked to its replacement. Rules inside the ERP itself are for the firm’s ERP specialist.

IOanyT is a consultancy with its own engineering team: we study the problem, recommend, and prove it by building only what you approve. We agree the benchmark before any rule moves, so the firm can count what is written down, who owns it, and what is left in the old programs.

Book a free Reliability Review →

Get a fixed quote →

See the Legacy System Specification Assessment →