Two ways an ERP system ends up shaped like the system it replaced.
The request never sounds unreasonable, and that is precisely the difficulty. It arrives in phrases like these:
Every one of these is asked in good faith by someone trying to protect their team from disruption. And in the short term they are right: familiarity genuinely does reduce day-one friction. People find things faster, ask fewer questions, and complain less in the first couple of weeks.
The problem is the shape of the trade. The training benefit is one-off and expires within a few months, as people learn the new system regardless. The constraint you accepted in exchange is permanent, and it compounds through every upgrade, every new hire, and every future process change, for as long as you own the system.
An established ERP is not a blank canvas with some manufacturing features bolted on. The process flows in it are the accumulated result of a great many manufacturers doing the same things and running into the same problems, refined over a long period. That accumulated design is a large part of what you paid for.
When a legacy workflow is rebuilt inside the new platform, that is not a neutral choice. It is a decision to override the refined version with your own, based on the assumption that your existing way is better. Sometimes that assumption is correct. Often nobody has actually tested it, because it never got framed as a choice at all. It got framed as a requirement.
There is one question that separates a legitimate requirement from an expensive habit, and it is harder to answer than it looks:
Is this how our business works, or is this how the old system made us work?
After a decade on a platform, those two feel identical from the inside. A limitation becomes a workaround, the workaround becomes a procedure, the procedure gets written down, and eventually somebody trains new starters on it as though it were policy. By the time it reaches a design workshop, it is described with complete sincerity as "how we operate," and the person describing it is not being difficult. They genuinely do not know it started life as a technical constraint.
Teams almost never separate these two categories unaided, because the evidence needed to do it left with the old system's original implementers. It usually takes an outsider asking, repeatedly and without irritation, what would actually break if the step went away.
This is also why skipping a step is riskier than it looks. In a well-designed module, each stage enforces the constraint that makes the next one trustworthy. Remove or bypass one of those because the old system managed without it, and you have not simply skipped an inconvenient screen. You have removed the guarantee that everything downstream was relying on. The consequences do not show up in testing, where volumes are low and everyone is being careful. They show up eighteen months later, as a class of problem nobody can explain, in a part of the system that looks unrelated.
I am not arguing for purity here. Some ERP customization is right, and a business with a genuine operational differentiator should absolutely protect it. But each request is worth putting through the same short test, and the test should be applied by someone whose job is not to keep the go-live date.
Would I be comfortable defending this decision to whoever holds my job in eight years' time?
It is a slightly uncomfortable question, and it changes the tone of the room in a good way. It shifts the discussion from "what do we want" to "what will this cost the people who come after us," which is the calculation that was missing from every inherited customization I have ever been asked to unpick.
New leadership takes over. They look at the ERP and find it heavily customized: legacy approval chains rebuilt faithfully inside the platform, bespoke screens, reports that replicate the format of a system decommissioned a decade ago. The people who made those decisions have moved on. The new team wants to modernize, simplify, and let the system work the way it was designed to, and they cannot easily do any of it, because users are attached to the current behavior and the customizations are load-bearing.
The first thing I say in these conversations, and I mean it: those original decisions were almost always reasonable at the time.
Read part one again and the reason is obvious. The people making these calls were under pressure, mid-transition, and being asked to sign off on decisions whose consequences would not surface for years. When a department says "we cannot work without this approval step," the safe answer in that moment is to build it. Nobody has time to relitigate the org chart, and refusing risks the date.
What was not visible then was the compound cost. Each individually reasonable exception makes the next upgrade slower, the next new hire's training longer, and the next process change more expensive. That cost only becomes legible years later, to people who were not in the room.
The instinct on inheriting a system like this is either to defend the past or to condemn it, and neither gets you anywhere useful. The good news is that it is almost never all-or-nothing. It is a sequence of small, separable decisions, and you can take them one at a time.
Separate what is genuinely custom code from what is configured behavior, and both of those from what is standard behavior everyone has forgotten is standard. These three get conflated constantly, and the third category is bigger than people expect.
In Visibility specifically, a real proportion of what customers believe is bespoke turns out to be a Master Control setting, or a variant of standard behavior that was switched on years ago and never revisited. Those can be reconsidered in an afternoon, with no development involved at all. Finding them is the cheapest win available to you, so do it first.
This question is more useful than asking what it does. Sometimes the answer is a genuine competitive differentiator, in which case keep it and stop feeling awkward about it. Not all customization is technical debt.
Sometimes it is protecting an approval chain from an organizational structure that no longer exists, or a report format that matched a system nobody remembers. Those retire easily once someone says out loud what they were for.
The temptation is to start with the easy ones. Resist it. Start with whatever is currently causing your users the most friction, because the first thing you remove sets the tone for everything after it. If simplification visibly makes someone's Tuesday better, you have support for the next one. If your first move is a technically tidy change nobody notices, you have spent effort and bought nothing.
Do not retire anything at month end, quarter end, or during your busiest production period. This sounds obvious. It is violated constantly, usually because the change was ready and the window looked open.
A large share of what gets customized in any ERP is reporting, and it is worth checking whether yours needs to be. In Visibility, IQ Plus covers a great deal of ground against the underlying tables without touching the application itself. If an inherited customization exists purely to produce a particular output, there is a decent chance it can be replaced with a report and retired outright, which is a materially better position to be in at your next upgrade.
The list of things you are unpicking today is the list of things somebody agreed to on a Tuesday afternoon in a design workshop, under deadline pressure, to keep a department comfortable. It was not carelessness. It was a series of small, defensible decisions taken without anyone holding the long view.
Which is the practical lesson for anyone currently mid-implementation. You are not choosing between disruption now and comfort now. You are choosing between a few uncomfortable months and a constraint your successors will spend real money removing. Familiarity is worth something, but it is worth much less than it feels like in the room, and it is being paid for on a very long installment plan.
If you are on the other side of that already: you do not have to defend the decisions you inherited, and you do not have to demolish them. Look at each one, understand what it was for, and decide whether it still earns its place. Most organizations that do this find that a meaningful fraction of what they thought was permanent turns out to be a setting, a habit, or a report, and that the genuinely entrenched customizations are fewer, and more defensible, than the sight of the whole list first suggests.
Whether you're mid-implementation or living with a system someone else shaped, we're glad to help you sort the settings from the code. Talk to our team.