A Pimcore instance does not fail. It gets slowly more expensive, and because no individual month stands out, nobody notices until a quote comes back that is out of all proportion to the request.
This is about where that cost comes from. Not as a scare piece: the point is to make invisible line items visible enough to plan around.
The upgrade does not get more expensive in a straight line
A major upgrade from one version to the next is a manageable piece of work: adapt the custom code where interfaces changed, move bundles to current releases, test, roll out.
Two versions behind is not twice the work. You get the changes from both jumps at once, plus bundles whose successor is named differently or no longer exists, plus PHP and Symfony versions that force their own adaptations. And every year, fewer people are left who can explain the original state.
The practical effect is that beyond a certain gap, the upgrade moves out of the maintenance budget and into project planning. There it competes with work that promises visible benefit, and it loses. That is the mechanism by which instances sit on the same version for five years.
Beyond a certain gap the upgrade leaves the maintenance budget and becomes a project. There it competes with work that promises visible benefit, and it loses.
The data model drifts, and every change pays for it
A data model is designed for the requirements known at project time. That is correct. The problem starts when the requirements change and the model does not move with them.
Concretely: attributes added as class fields that belong in the classification store by now. Product families that have no clean place in the original inheritance tree and sit beside it as special cases. Localization designed for four markets and now carrying eleven.
None of that is broken. All of it makes the next change more expensive, because the change has to be built around the special cases as well as implemented. That is why quotes feel disproportionate: they contain work that is not in the requirement, it is in the structure the requirement has to fit into.
How far your model has drifted is answerable in a week, in writing, at a fixed price.
Pimcore Health Check, €2,500 fixed →Silent integration failures turn into manual work
The second largest cost is not an invoice, it is time inside your own company. An import fails, nobody finds out, and eventually somebody starts adding the missing records by hand.
Then that patching becomes habit. It is in no process, it appears in no report, and it still costs hours every week. In the instances we assess, missing monitoring is the single most common finding, and fixing it is usually hours of work rather than weeks.
Knowledge that sits with one person
This is the hardest item to quantify and the most expensive one. In most companies there was somebody who understood what the data model was meant to do, why a particular export looks the way it does, and which system wins when two disagree.
When that person leaves, the code stays and the reasoning does not. Every change afterwards starts with a small excavation. That is not the fault of whoever comes next. It is a documentation problem, and documentation has to be produced during operation rather than after it.
The remedy is unglamorous: write it down while you work. What each class is for, which system owns which field, which job runs when, and what happens when it fails. That is not administration, it is the only insurance against this exact situation.
Why the original agency rarely solves this
This is not an accusation, it is a business model. Implementation agencies live on new projects. A client four years past go-live with a half-day change request occupies capacity that earns more elsewhere.
You experience the result as slow answers and quotes that feel wrong. It is rarely disinterest and usually a prioritisation that works badly for both sides. That is exactly why maintenance agreements exist: they make the small, unattractive work the agreed normal case rather than the exception.
Ongoing maintenance with response times, a fixed hour budget, and upgrades that are planned rather than deferred.
Pimcore support and maintenance →What you can do this week
You do not need a consulting engagement to get a rough read on the state. Three questions are enough for a first picture.
- Which Pimcore and PHP version does the instance run, and when was it last updated?
- Which scheduled jobs run, and where does the alert go when one fails?
- Who internally can explain why the data model looks the way it does?
And if everything is fine
Then that is a good result and not wasted effort. An instance on a current version, with monitored integrations and a documented data model, is a state worth knowing about and holding.
The expensive case is not the neglected instance. It is the instance where nobody knows which of the two states it is in.