Pimcore maintenance and growth — ongoing support for the platform

We do not give a single rate. The estimate is driven by the scope of monthly work, the number of integrations and custom extensions, the platform version, the technical state of the project, the scope of development, the number of environments and the response requirements — all eight are set out in the section on the cost of maintenance. Specific arrangements follow in the proposal, after the takeover audit.

Yes, taking over an existing project can be the starting point of the cooperation. First we need to get to know the code, the environments, the integrations, the platform version, the documentation and the problems users report. Only then can the scope of stabilisation and ongoing maintenance be set.

With an audit, not with the first fix. We look at the Pimcore version and its modules, the architecture, the data models, the integrations, the custom code, the APIs, the scheduled jobs and queues, the infrastructure, the documentation and the backlog. The whole process, with the artefact each stage produces, is in the section on taking over maintenance.

Usually the code repository, access to the environments, logs, implementation documentation, a description of the integrations and contact with the people who know the business processes. The full list depends on the architecture and on how responsibility is split between providers.

Yes, updates and security patches are part of maintenance rather than a separate project — as long as the installation sits on a version it can be updated from without a rebuild. If the platform runs on an unsupported version, getting it to a current one can be a scope of work of its own, estimated after a compatibility assessment.

We start by analysing the version, the dependencies, the custom extensions and the change notes. The update goes onto a non-production environment, where processes and integrations can be checked. The production plan covers the way back and observation after the release. We check the compatibility of the whole stack rather than the core version number alone — modules and extensions have releases of their own.

Yes, and that is a typical part of maintenance. It brings new classes, fields, relations and dictionaries, migrations of data already entered, and changes to preparation stages and permissions. We settle the scope together with the effect on integrations and exports, because the data model is a contract for the channels receiving the data too.

The service can combine day-to-day maintenance with delivering a growth backlog. Both kinds of work have separate priorities, because a failure affecting data needs different handling from a planned feature.

Yes. Single tasks — a new export, extra fields in the model, a performance fix — can be delivered from an agreed pool of hours or estimated separately. For larger architectural changes or a new connector we go back to a project scope, so that a rebuild is not run as a series of tickets.

Yes, for the connections that already exist: we diagnose synchronisation errors, queues, schedules and APIs, and develop what is already running. Building a new connector or thoroughly rebuilding the data exchange is treated as a separate scope under the Pimcore integration service.

Yes. In projects with a large backlog it makes sense to start with an inventory, a risk list and a stabilisation plan. The permanent model of cooperation can be set once the real state of the platform is known.

The model follows from the number of requests, the expected response time, how critical the processes are, the monitoring scope and the planned growth. Specific variants, response times and SLA terms are provided at the proposal stage.