Companies stay with agencies they are unhappy with for a reason that has nothing to do with the agency: moving feels riskier than staying. The system works, more or less, and nobody wants to be the person who broke it by changing supplier.
That instinct is right often enough to be worth taking seriously, and wrong often enough to be worth checking. This is about how to tell which case you are in, and what the handover involves when the answer is to move.
The signs, and how many of them matter
None of these on its own is a reason to move. A bad quarter happens. What matters is how many are true at once, because together they describe an arrangement that will not correct itself.
- Quotes that do not match the work, with reasoning that stays vague when you ask. Sometimes the data model genuinely makes a small change expensive, and a good supplier can explain exactly why.
- You only ever speak to account management. The people who built your instance moved on, and each new request is read from scratch by somebody different.
- The upgrade appears in every annual review and no quarterly plan.
- Nobody can explain how the system is put together. Asking why a class looks the way it does produces a guess rather than a reason.
- You have started routing work around the agency: an internal person patches data by hand rather than raising a ticket, because the ticket is not worth the wait.
What to ask for before you decide
Before any decision, ask your current supplier three questions and pay attention to how they answer rather than what they answer.
First: what version are we on, and what would it take to get current? A supplier who knows their instance answers this in a sentence. Second: what documentation exists, and can we have a copy? The answer tells you how much reconstruction a handover would need. Third: which of our integrations are monitored, and where do the alerts go? This one catches more real problems than the other two combined.
A good supplier answers all three without defensiveness. If the answers are vague, that is information about the state of your instance as much as about the relationship.
The handover, mechanically
What actually transfers is smaller than most people expect. The list is short and worth having in writing before the conversation starts.
- Repository access, including the full history rather than a zip of the current state
- Hosting and server access, or the account transfer if the hosting is in the agency name
- Domain and DNS control, which is the item most often overlooked and most disruptive when it is missing
- Credentials and endpoint details for every connected system: ERP, shop, DAM, translation, payment, anything scheduled
- Whatever documentation exists, in whatever state it exists
How a takeover runs on our side, including the first thirty days and the cases where we advise against it.
Switching Pimcore agency →Red flags on the incoming side
The supplier you are moving to deserves the same scrutiny as the one you are leaving. Three answers should give you pause.
An immediate recommendation to rebuild, given before anybody has read the code. A rebuild is the most expensive option and the easiest to sell, and it is almost never what an instance in this position needs.
Reluctance to work on somebody else's codebase, expressed as a preference for "starting clean". That is a preference for their convenience over your budget.
No willingness to assess before committing. Anybody who will quote ongoing maintenance on an instance they have not looked at is either guessing or planning to renegotiate later.
When staying is the better call
If the technical work is sound and only the responsiveness is poor, that is a contract problem. A maintenance agreement with committed response times and a defined hour budget fixes it for less than a migration costs, and you keep the accumulated knowledge.
If the instance is current and stable and you change something once or twice a year, the effort of switching will not pay back. And if the actual dissatisfaction is that Pimcore is a bigger system than your catalogue needs, then no agency running Pimcore will fix that. That is a platform question, and it deserves its own honest conversation.
The one thing to get right
Whatever you decide, insist that documentation is a deliverable rather than a promise. The reason handovers are hard is almost never the code. It is that nobody wrote down what the code was for.
A supplier who documents as they work is worth more than one who is slightly cheaper per hour, and the difference shows up the first time somebody leaves.