A customization looks like a purchase. Someone scopes it, someone builds it, an invoice gets paid, and the feature shows up in the system. What almost nobody prices in is that the same feature has to be re-verified at every upgrade and every patch, for as long as the platform lives. That recurring cost is invisible on the day the work is approved. Years later it is usually the largest unnamed line in the PLM budget. In 2026, Deloitte’s survey of more than 660 technology leaders found technical debt consumes 21% to 40% of IT spending. In PLM environments, a large share of that debt has a specific name: custom code written against an API that was always going to move. What follows separates configuring from customizing, prices each, and names where custom code still earns its place.
Key Takeaways
- If it breaks on upgrade and the vendor fixes it, you configured. If it breaks and you fix it, you customized. That rule decides who pays for the next twenty years.
- Technical debt already eats 21% to 40% of IT spend (Deloitte, 2026), and each new project pays a 10% to 20% surcharge to work around it (McKinsey, 2023). Customization is how PLM accumulates its share.
- Falling behind on upgrades is now a security exposure. Vulnerability exploitation started 31% of breaches in the 2026 Verizon DBIR, up from 20% in the 2025 edition.
- Configure first. Reserve customization for requirements with no configured path and a lifetime cost, not a build cost, that the business has approved.
Configure and customize are not synonyms in PLM
The distinction fits on an index card, and most organizations have never written it down. If you configure something and it stops working after an upgrade, that is the vendor’s problem. They shipped a change that broke supported behavior, and they fix it. If you customize something and it stops working after an upgrade, that is your problem. You wrote code against an API, the API moved, and you own the repair.
A workflow is the cleanest example. Build a workflow by filling in the fields the platform gives you, and you now have a workflow nobody else has. It is yours. But you have not customized the platform. You configured it, and it will survive the next release without anyone touching it. Write Java against the platform’s API, compile it, and deploy it to the server, and you have customized. That code will need to be checked, and possibly rewritten, on every upgrade cycle from now on.
Both approaches produce a feature. Only one of them produces a maintenance obligation.
| Configure | Customize | |
|---|---|---|
| What you touch | Workflows, attributes, lifecycle templates, access rules, through the platform’s own tools | Code written against the platform API, compiled and deployed to the server |
| Who fixes it when an upgrade breaks it | The vendor | You |
| Survives the next release untouched | Yes | Only after re-verification |
| Example | A workflow built from the fields the tool provides | A custom listener or object type in Java |
ERP has been learning the same lesson in public. In 2024, ASUG and smartShift found 95% of surveyed SAP customers build and run custom code, and too many customizations is the top obstacle to migrating. The “clean core” movement is SAP’s name for what PLM administrators have known for years: the custom layer is what makes the next version expensive.
The math behind the recurring cost
Consider the economics from a vendor’s side, because that is where the pattern becomes obvious. A hosted PLM service charges a customer a fixed fee for a customization, call it $50,000. The fee covers the build. It does not cover what happens next. Quarterly upgrades each require someone to confirm the customization still behaves. Over five years, the total cost of that one feature runs to roughly $200,000, and three quarters of it was never billed to anyone.
I learned this arithmetic from the inside, years ago, working on a hosted PLM service. Customizations were sold at a flat fee, and the upgrade verification work that followed made the true economics visible in a way an on-premises budget never does. Hosted, the tail comes out of the provider’s pocket, so somebody notices.
On-premises, it comes out of the customer’s. There is no vendor absorbing the cost. The engineering organization pays every dollar of it, usually without a line item that names it. McKinsey’s CIO research describes the same surcharge at the portfolio level: companies pay an additional 10% to 20% on every project to work around existing technical debt, and 30% of CIOs said more than a fifth of their new-product budget is diverted to it (2023).
Customization freezes the PLM platform and forfeits the roadmap
The recurring cost is the first half of the case. The second half is opportunity cost, and it is larger: requirements management, quality management, and software configuration management all exist as modules that a frozen platform never gets to turn on. A heavily customized system tends to freeze at whatever version it was customized against. Upgrading means re-testing everything, so upgrades get deferred. Deferred upgrades mean the organization never gets the features the vendor shipped in the releases it skipped. Meanwhile the customizations themselves get in the way of new modules, because they were written against assumptions the platform no longer makes. Tech-Clarity’s 2022 cloud PLM research describes outdated PLM systems that have not been upgraded, “frequently due to dead-end customization approaches that make upgrades extremely challenging.”
The alternative is almost always cheaper and almost always delivers more. Turning a module on is a fraction of the effort of building a bespoke equivalent, and the vendor maintains it forever. The choice, put plainly, is between perfect and more. A customized feature can be tuned exactly to how one team wants to work. A configured module gives the organization a much larger set of capabilities that it did not have to build and will never have to maintain. Organizations that choose perfect for every feature end up with a system that does fewer things, later, at higher cost. Our earlier piece on getting business value from every PLM upgrade covers what those skipped releases actually contain.
There is a reason the out-of-the-box behavior is worth trusting. A major PLM vendor’s product decisions reflect conversations with hundreds of customers and the practices that industries converge on. A customization reflects one team’s preference on one day. Configuring first, and treating customization as the exception that requires justification, keeps the platform’s accumulated judgment working for you.
Falling behind is now a security exposure
The cost of a frozen platform used to be measured in missing features. It is now measured in breaches. Verizon’s 2026 Data Breach Investigations Report found vulnerability exploitation was the initial vector in 31% of breaches, overtaking stolen credentials for the first time in the report’s nineteen-year history. A year earlier the figure was 20%, itself a 34% rise on the year before that. Remediation is not keeping pace: the 2025 report found only 54% of edge-device vulnerabilities were fully fixed, at a median of 32 days.
For a manufacturer holding controlled technical data, an engineering backbone stuck two releases behind because nobody wants to re-test the custom layer is not a productivity problem. It is an audit finding waiting to happen. The federal estate shows where that road ends. The GAO reported in 2025 that about 80% of federal IT spending goes to operating and maintaining existing systems, the oldest of them 60 years old, several running unsupported software that cannot be patched without a modernization nobody has funded. Custom code that blocks upgrades is how an engineering platform starts down the same road.
Two systems, two ticket queues
The difference shows up in the support queue long before it shows up in the budget. A configured PLM environment, designed carefully before anything was deployed, generates very few tickets. Things work the way the platform expects them to work, so nothing breaks unexpectedly.
A heavily customized environment can run 75 tickets a month and consider that normal. The team ends up organized around a sprint cadence: define the requirement, design the fix, apply it, test it, and push to production, all in three weeks, then repeat. That rhythm is appropriate for software product development. It is not how a product lifecycle backbone should behave, and an engineering organization living inside that loop has stopped using PLM and started maintaining one.
One more distinction is worth carrying into any platform evaluation. Some systems are marketed as highly configurable, and on close inspection that means very little ships pre-built. Configuring everything is still configuring, but it is a different proposition from a platform that arrives with mature out-of-the-box functionality and lets you adjust it. The question to ask a vendor is not whether the tool can be made to do what you need. Almost any tool can. The question is how much of what you need is already there, supported, and covered by the upgrade path.
Where PLM customization still earns its place
Customization earns its place in the narrow set of cases where a genuine business requirement has no configured path and the value of meeting it exceeds its lifetime cost, not just its build cost. That set is smaller than most organizations assume. Companies built by acquisition raise the obvious objection. Business unit A works one way, business unit B works another, and consolidating them means somebody has to give something up. Customization looks like the way to keep the peace. The reasons organizations give for custom code are consistent across platforms. In the 2024 ASUG research, SAP customers cited industry-specific needs, reporting, innovation, and competitive advantage, in that order.
Most of the time, configuration covers the difference. Distinct workflows, distinct attribute sets, and distinct lifecycle templates are all configuration, and they can coexist on one platform without anyone writing code. The unit-specific behavior survives. The maintenance obligation does not. Reporting, the second most common justification, is the clearest example of a need that once required code and now rarely does.
When a case clears that bar, build it, document why it exists, and include its upgrade verification in the budget from day one. Panorama’s 2026 ERP research describes the failure mode when that discipline is missing: organizations “discover fatal misfits late in the project, so they turn to additional technology, scope expansion, and custom builds.” Custom code written under schedule pressure is the most expensive kind, because it was never designed to be maintained.
The question to put to any heavily customized system
Organizations one or two generations behind on their platform rarely got there by choosing to fall behind. They got there one customization at a time, each of which made the next upgrade a little more expensive, until upgrading stopped being a decision anyone was willing to make. Forrester expected 75% of technology decision-makers to see their technical debt reach moderate or high severity by 2026. In PLM, that debt has an inventory: the list of custom objects, listeners, and integrations that someone has to re-verify before the next release goes live.
The way out is the same question, asked of every item on that list: what would it cost to configure this instead, and what would the money we are spending to keep this alive buy us if we spent it on capability we do not have yet? For most of the list, the honest answer is that the customization is a subscription nobody agreed to, and it is time to cancel it.
Frequently asked questions
What is the difference between configuring and customizing a PLM system?
Configuration uses the platform’s supported options: workflows, attributes, lifecycle templates, and access rules set through the tool itself. Customization writes code against the platform’s API. The practical test is who fixes it after an upgrade. Configuration breaking is the vendor’s responsibility. Customization breaking is yours, on every release, for the life of the system.
How much does PLM customization really cost over time?
The build is the small number. Every customization must be re-verified at each upgrade and patch, which on a quarterly cycle can multiply the original cost several times over five years. At the portfolio level, Deloitte found technical debt consumes 21% to 40% of IT spend (2026), and McKinsey found projects pay a 10% to 20% surcharge to work around it (2023).
Why do customizations block PLM upgrades?
Because each one has to be tested against the new release before go-live, and any that fail must be rewritten. As the list grows, the test burden makes upgrades expensive enough to defer indefinitely. Tech-Clarity’s 2022 research attributes outdated PLM installations to “dead-end customization approaches that make upgrades extremely challenging.”
Is an old PLM version a security risk?
Yes. A platform that cannot be upgraded cannot take current patches. Verizon’s 2026 Data Breach Investigations Report found 31% of breaches began with a vulnerability exploit, up from 20% in the 2025 edition, which itself found only 54% of edge-device vulnerabilities fully remediated. For manufacturers holding controlled technical data, that is a compliance exposure.
When is PLM customization justified?
When a genuine business requirement has no configured path and its value exceeds its lifetime cost, including verification at every future upgrade. Document the reason it exists, budget the maintenance from day one, and revisit it at each release. Most requirements that look like they need code, including industry-specific processes and reporting, are met by configuration or a standard module.
The bottom line
Customization is not a purchase. It is a maintenance contract with no end date, signed on the organization’s behalf by whoever approved the build.
- Configure when the vendor owns the upgrade risk. Customize only when you have decided to own it.
- The build is the small number. The verification tail is the cost, and it is rarely on any budget line.
- Every customization makes the next upgrade harder. That delays new capability, and increasingly it delays security patches.
- Industry-specific needs and reporting, the two most common reasons given for custom code, are now served by configuration and standard modules.
- Inventory the customizations. Ask the configure-instead question of each one at every release.
ArcherGrey works with manufacturers running heavily customized PLM environments, and the first step is usually the same: an honest inventory of what is custom, what it costs to carry, and what configuration could replace. If your upgrade has been deferred more than once, start with the signs your PLM is holding your team back, or talk to our PLM transformation practice about building the case for configuring your way forward.