A company that has run a PLM system for six or seven years reaches a point where the sentence gets said out loud: this system is not working for us, we need a new one. It is usually said with conviction, backed by a list of real frustrations, and supported by engineers who have been complaining for two years. And it is usually the wrong conclusion, drawn from correct evidence.
The frustrations are genuine. Searches return nothing useful. Nobody trusts the data. Half the team has built workarounds in shared folders. Approvals take a week for changes that take an hour. Every one of those complaints is legitimate, and none of them is caused by the platform.
What actually happened over six years
Rewind to the implementation. Somebody configured the system: data model, part numbering, lifecycle states, approval workflows, access rules. Those decisions were made in a series of workshops, they were reasonable at the time, and they reflected how the company worked in that year.
Since then the company changed. It acquired a site, or opened one. Product complexity increased. Two departments merged and a third was created. The number of engineers doubled. A new product line arrived that does not resemble the old ones. Somebody left and took the configuration knowledge with them.
The configuration did not change with any of it. Nobody decided to leave it alone. There was simply never a moment where revisiting it was anyone’s job, and every year the gap between how the system is set up and how the company works widened by a little.
What people experience as “the system is bad” is usually the accumulated distance between a configuration and a company that both changed at different speeds.
Replacing the platform resets the distance to zero. It does not stop the drift, and in five years you are in the same place on a newer version.
Which complaints point where
The useful skill is distinguishing complaints that indicate a platform problem from complaints that indicate a configuration problem. They sound identical when reported by a frustrated user.
| The complaint | Usually indicates | Actual cause |
|---|---|---|
| “Search never finds anything” | Configuration | Attributes not filled in, or not searchable |
| “Approvals take a week” | Configuration | Workflow routes to people with no grounds to refuse |
| “The system is slow” | Configuration | Structures force loading far more than the user needs |
| “Nobody trusts the data” | Configuration | No ownership rules, so nobody maintains it |
| “People work in shared folders” | Configuration | The system makes a common task harder than the workaround |
| “It cannot handle our product variants” | Possibly platform | Depends on which platform and which variant logic |
| “Our vendor ended support for this version” | Platform | Genuine, and a real reason to move |
| “We need capability the platform does not have” | Platform | Genuine, if the capability is actually needed |
Six of the eight most common complaints are configuration. That ratio is roughly what an assessment tends to find, and it is why the recommendation is frequently to change nothing about the software.
Why the workarounds are the most useful evidence you have
When users abandon a system for shared folders, the instinct is to treat it as a discipline problem and respond with a reminder about policy. That reading gets the situation exactly backwards.
A workaround is a documented user decision. Somebody compared the official route with an unofficial one, and the unofficial one won. They are not being difficult. They are being efficient, and they have identified a specific place where the configuration is worse than a folder on a network drive.
An engineering team kept a parallel folder structure for drawings in progress. IT treated it as a compliance issue and blocked it. Within a month it reappeared under a different name.
The reason came out during an assessment. The lifecycle had no state between “in work” and “released”. Anything not yet released was invisible to colleagues, so two engineers working on related parts could not see each other’s progress. The folder existed because the system had no way to represent work in progress that others could see.
Adding one lifecycle state removed the workaround permanently. Six years of policy reminders had not.
Every persistent workaround marks a specific gap. Mapping them is the fastest available diagnosis, and it costs nothing but the willingness to ask people why they do it without implying they should stop.
What replacement actually costs
The case for replacement is usually built on licence cost comparison. That is the smallest number in the calculation.
- Data migration. Years of parts, documents, and revisions, cleaned, mapped, and validated. Typically the largest single item, and the one most often underestimated.
- Rebuilding integrations. Every interface to the ERP and other systems has to be rebuilt and retested.
- Configuration from scratch. Including all the decisions nobody documented the first time, which now have to be reconstructed from behaviour.
- Parallel operation. Both systems running during transition, with the licence cost of both.
- Adoption. Every user learning a new environment while output is still expected.
- The knowledge that leaves. Whatever institutional understanding was embedded in the old configuration does not transfer.
Reconfiguring an existing platform involves the third item on that list and none of the others. That is the whole difference, and it is usually an order of magnitude.
The uncomfortable version of this argument: a replacement project reproduces the original implementation, including the part where configuration decisions get made under time pressure by whoever is available.
If the reason the current configuration drifted is that nobody owned it, a new platform inherits that problem on day one.
When replacement is the right answer
Sometimes it is, and the argument above should not be used to talk anyone out of a decision that is correct. Four situations where moving platform is genuinely the answer.
Support has ended
A version the vendor no longer supports is a security and continuity risk that no amount of reconfiguration addresses. This is the clearest case, and it usually means an upgrade rather than a change of vendor.
The capability genuinely does not exist
Some requirements cannot be configured into a platform that was not built for them. Complex variant configuration, specific regulatory workflows, or particular multi-CAD requirements can fall into this category. The test is whether the requirement is real or whether it appeared on a wish list.
The customization has become the system
Where years of custom development have accumulated to the point that upgrades are impossible and nobody understands the whole, the platform has effectively become bespoke software with a vendor logo. That is a genuine reason to reset.
The strategic direction changed
A move to cloud, a merger that standardizes on a different platform, or a group-level decision. These are business decisions where the PLM question is downstream of something else.
How to find out which situation you are in
The distinction between platform failure and configuration drift is not obvious from inside, because you only see the symptoms. Three questions get most of the way there.
- When was the configuration last reviewed against how you actually work? If the answer is “at implementation”, you have a configuration question rather than a platform question.
- Can anyone explain why the current configuration is the way it is? If the reasoning left with a person, the system is not the thing that stopped being understood.
- List every complaint, and for each one ask whether the platform is incapable or configured differently than needed. The proportion of each tells you what kind of project you are looking at.
These questions are answerable internally, in a workshop, without engaging anyone. If the answers point clearly at the platform, you have saved yourself an assessment. If they point at configuration, that is the more common outcome and the cheaper one.
Where the answers are genuinely mixed, that is what a consulting assessment is for. It ends with a written report, and a recommendation to reconfigure rather than replace is a legitimate result.
What reconfiguration looks like
It is not a smaller version of an implementation project. The system stays live throughout, which changes the approach considerably.
It starts with the current state: what is configured, why, and where users have worked around it. Then the changes get prioritized by how much friction each removes relative to the effort involved. The lifecycle state in the example above cost a day and removed a six year problem.
Changes go into a test environment first, get validated with the users who reported the problem, and reach production in stages. Nothing about it requires a big bang, and the first improvements typically land within weeks rather than at the end of a project.
The part that matters most is what happens afterwards: assigning ownership of the configuration, so that in five years the drift has not silently returned. That is the actual fix. Everything else is repair work.
How do we know a consultant is not just protecting the platform they sell?
A fair question, and the answer is in the sequence rather than the promise. Requirements written from your process, before any platform is discussed, can be measured against any vendor including the incumbent. If the analysis starts from a product comparison, the conclusion was decided in advance.
Our users are convinced the system is the problem. How do we change that?
You generally do not, by argument. What changes the perception is fixing two or three specific complaints they raised and letting them notice that the platform did not change. That is worth more than any presentation, and it is a reason to prioritize visible friction first.
How long does a reconfiguration take?
The assessment is around three weeks. What follows depends on scope, and the useful thing is that it can be staged. Fixing the worst friction is often weeks rather than months, and the remainder can be scheduled around your own cycles rather than driven by a project plan.
What if we already decided to replace it?
Then the assessment is still worth doing, for a different reason. A replacement project needs the same output: documented process, transformation rules, requirements, migration scope. Those documents are needed either way, and they are what determine whether the new implementation avoids the mistakes of the old one.
Can we do this ourselves?
The three questions above, yes, and you should. Where external help earns its cost is in knowing which configuration patterns cause which symptoms, because that pattern recognition comes from having seen the same drift in other companies. If your team has that experience internally, use it.
Considering replacing your PLM system?
Ask the three questions above first. If the answers are mixed, an assessment settles it in three weeks and ends with a written report that is yours regardless of what you decide.