Switching Pimcore agency
Switch Pimcore agency without the business stopping
Moving feels risky, so most companies stay with an agency they dislike. Here is how the handover works, and when to stay put.
At a glance
- Sequence
- Health check, handover, first thirty days
- Requirement
- Access to the code and the environments
- Without cooperation
- Possible, slower and more expensive
- Afterwards
- Ongoing maintenance from €800 a month
- Area
- Austria, Germany, and the wider DACH region
Taking over instances other people built is what we do, not what we fall back on. Our founder spent two years maintaining a production Pimcore installation that another party had implemented, including the data model, the integrations, and the upgrades.
Where teams get stuck
The signs that it is time
On its own, none of these is a reason to move. If you find yourself nodding at three or four of them, the conversation is no longer about a bad stretch. It is about an arrangement that will not correct itself.
Quotes that do not match the work
An extra language or an attribute group costs a multiple of what you expected and the reasoning stays vague. Sometimes that is the data model. Sometimes it is disinterest. You should be able to tell which.
You only ever speak to account management
The people who built your instance moved on to other projects long ago. What you get now is a translation layer between you and a rotating set of developers who have to read your system from scratch each time.
The upgrade has been deferred for years
It appears in every annual review and in no quarterly plan. The longer that continues, the more expensive it gets, and the more plausible somebody eventually makes a rebuild sound.
Nobody can explain how the system is put together
There is no current documentation, and asking why a class looks the way it does produces a guess. That is the point at which the knowledge exists only in the code.
What works better
How the handover runs
Three phases. The first is a fixed price, the second is project work, the third is business as usual.
Establish the state
The health check at a fixed €2,500: version, data model, integrations, performance, security. It ends with a written report that stays useful even if you decide not to switch.
Take over and document
Codebase review, our own development and staging environments, and an orderly transfer of the repository, hosting, domains, and accounts. The documentation that has been missing gets written along the way.
Take over and keep going
After the handover, maintenance continues monthly at €800 to €2,500 depending on scope. Findings from the report get worked through in priority order rather than all at once.
The questions you actually have
What can go wrong, and which of it actually happens
What if our current agency will not cooperate?
It happens, but less often than people expect. Most agencies hand over properly, because a clean exit is worth more to their reputation than a client held in place.
When they do not: you need less from them than you think. What is required is access to the repository, the hosting, and the domains. Everything else can be reconstructed from the code and the running installation. Check your contract for who owns the code, the data, and the hosting accounts before you have the conversation. Usually more of it is yours than you realise.
What if the code is undocumented?
That is the normal case and not an obstacle. A Pimcore installation is readable: class definitions exist as configuration, integrations leave traces in logs and cron jobs, and the data model is visible in the objects themselves.
That is exactly what the codebase review is for. By the end of the handover the documentation exists that did not before, and it is yours regardless of who maintains the instance later.
What if we are mid-project?
Then the timing is usually wrong. Switching in the middle of live work splits responsibility between two parties who can each point plausibly at the other.
The exception is a project that is not moving anyway. In that case the switch is not the disruption, it is the thing that ends the stall.
When you are better off staying
If your agency does technically good work and is only slow to respond, that is usually a contract problem rather than a supplier problem. A maintenance agreement with committed response times fixes it more cheaply than a move does.
If the instance is stable, current, and you change something once or twice a year, switching is not worth the effort. And if the real dissatisfaction is that Pimcore is oversized for your use case, a different agency running the same system will not improve anything.
The first thirty days
- Week 1: access, our own development environment, and a full deployment rehearsed outside production
- Week 2: data model and integrations documented, monitoring added where there was none
- Week 3: the first small changes off the fix list, so both sides have seen the process work once for real
- Week 4: the upgrade path put in the calendar and priorities agreed for the next quarter
Why we do this at all
Inherited instances are not what we do between new projects. They are the specialisation, because our experience comes from running an existing installation rather than from implementing one.
Somebody who has operated a system for years that somebody else designed reads unfamiliar code differently. That is a different skill from setting a project up from nothing, and the rarer of the two.
Common questions
Frequently asked questions
How long does a handover take?
Do we lose anything?
Do we have to move hosting?
Can you do this without the current agency helping?
What does switching cost?
Related pages
Related
Auf Deutsch
Related services
Ready to talk
Talk first, decide after
Describe the situation. If switching does not make sense for you, we will say so on the call, because an inherited instance that nobody needed to move is a bad outcome for both sides.