Most Pimcore upgrades are deferred for the same reason: nobody can say what it will cost, so nobody can put it in a plan, so it stays on the list. The way out of that loop is to separate the assessment from the upgrade. Assessing exposure is a small piece of work. Doing the upgrade is a project. Confusing the two is what keeps instances stuck.
This covers how to measure where you stand, what typically breaks, and how to run the work so it lands.
Measure exposure before planning anything
Three numbers tell you most of what you need, and you can gather them in an afternoon.
- Your current Pimcore version, and the PHP and Symfony versions that go with it. PHP end-of-life dates are a harder constraint than Pimcore versions, because at some point your hosting provider stops offering the runtime you need.
- The third-party bundle list from composer.json, with a note against each: does it have a release compatible with your target version, is it abandoned, or was it replaced by something in core?
- The volume of custom code that touches Pimcore internals rather than public APIs. Admin UI extensions, event listeners on internal hooks, and anything extending a Pimcore class rather than composing with it.
Why the bundle list matters more than the version gap
A three-version gap on a near-vanilla instance can be less work than one version on an instance with five custom bundles. Pimcore core changes are documented and mechanical. An abandoned bundle is a decision: replace it, fork and maintain it, or rebuild what it did.
That decision is also the part that stalls projects, because it is not a technical question. Somebody has to decide whether a feature is still worth having. Making those calls before the upgrade starts, rather than during, is most of what separates a smooth upgrade from one that overruns.
What actually breaks
The reassuring part first: your data is not at risk in a normal upgrade. Data objects, assets, and documents survive. What needs work is the code around them.
- Bundles that have no release for the target version. Every one is a decision, and they need making early.
- Custom code calling Pimcore internals that changed signature or moved namespace. This is mechanical to fix once you can compile, and tedious in proportion to how much of it there is.
- Admin UI extensions, which historically take the most churn between major versions because the admin frontend has changed substantially over Pimcore 10, 11, and beyond.
- PHP version requirements that force their own migration underneath the Pimcore one, which is where a two-week estimate quietly becomes six.
- Integrations that depended on behaviour rather than on documented API, which is why the integration test pass matters as much as the application one.
How to run the upgrade
The mechanics are unremarkable and that is the point. An upgrade should be boring.
- Work in a branch environment with production-like data volume. Performance regressions do not show up against a hundred test products.
- One major version at a time. You get a testable state between steps, and when something breaks you know which jump caused it.
- Fix the bundle decisions first, before touching core. An upgrade blocked halfway by an abandoned bundle is worse than one that has not started.
- Test integrations, not just the application. The nightly ERP import and the Data Hub endpoints are what your business actually depends on.
- Have a rollback you have tested. An untested rollback plan is a paragraph in a document, not a rollback.
- Roll out in a window when the people who know the system are available, which sounds obvious and is regularly ignored.
The health check includes a version and upgrade path assessment with an effort estimate, so the number stops being unknowable.
Pimcore Health Check →The argument for upgrading on a schedule
The instances that stay current are not the ones with bigger budgets. They are the ones where the upgrade is a recurring maintenance item rather than a project that has to win an argument each time.
Minor versions continuously, security patches promptly, one major upgrade planned per cycle: that pattern keeps the gap at one version, which is the size where the work stays predictable. It is also considerably cheaper over any multi-year period than catching up in one large jump, because catching up means paying for several jumps at once plus the archaeology.
If you are already several versions behind
Then the first move is not an upgrade, it is an assessment. Find out which bundles are dead, how much custom code touches internals, and what the PHP path looks like. That produces a number, and a number can go into a budget.
The second move is to decide what not to carry forward. Instances that have been running for years almost always contain features nobody uses, and migrating them costs the same as migrating the ones that matter. An upgrade is a reasonable moment to stop paying for them.
We plan and execute Pimcore upgrades for manufacturers in Austria and Germany, including on instances we did not build.
Pimcore development and integration →