Once a platform has launched, the question “who is responsible for it?” returns with the first serious incident. Maintenance works when everyone knows in advance who will respond, what takes priority and what happens when the problem affects checkout, payments or an integration responsible for transferring orders.
We provide ongoing maintenance and development for Magento platforms. We take responsibility for business continuity and incidents, deliver day-to-day development work or support the client’s existing team wherever deeper Magento expertise is required.
During the first conversation, we will learn about your Magento platform, current support model and its importance to the business. This will allow us to determine a sensible scope of responsibility and cooperation model.
Responsibility
A banner change and a critical security patch should not wait in the same queue. Likewise, an error on a single product page cannot have the same priority as a broken checkout, B2B customers being unable to sign in or orders no longer reaching the ERP.
That is why platform maintenance means more to us than simply completing one ticket after another.
The first objective is to establish a clear response when a problem occurs. The second is to gradually reduce the number of such situations through updates, monitoring, improvements to the highest-risk areas and deliberate management of technical debt.
Over time, a well-maintained Magento platform becomes more predictable instead of teaching the organisation to accept constant firefighting.
Operational budget
In an ongoing engagement, we separate two types of work. Both run in parallel, but they have different purposes and rules of use.
This covers team availability, incident handling, patch and security updates, and the work needed to restore the platform to normal operation.
It is used for planned changes: configuration, development, technical consultation, improvements and subsequent roadmap items.
We separate the two areas for a practical reason: an incident does not consume the budget intended for platform development.
Depending on the selected support package, unused hours may roll over to subsequent months, for up to three months. When the limit has been used, we let you know before starting additional work. Every month, we provide a summary: a list of tickets, time spent on each one and the remaining balance.
Larger modernisation work is not automatically included in the monthly package. A major Magento upgrade, frontend rebuild or new integration is planned as a separate project.
Ticket classification
We classify every ticket according to its impact on the platform.
The store or a key sales process is unavailable: customers cannot place or pay for orders, a widespread error prevents use of the platform, or there is a suspected security incident.
An important feature is not working correctly, but the platform is still selling. This includes serious performance degradation or an issue affecting a large group of customers or an important administrative process.
Non-critical errors, isolated cases, issues with an available workaround and defects that do not stop sales.
New features, improvements, configuration and planned development work.
We assign priority based on the actual impact of the problem on sales and platform availability. In ambiguous situations, we consult the classification with the client so that genuinely critical tickets retain precedence.
SLA
It defines how quickly we begin handling a ticket after it is registered: we provide a substantive response with its priority classification and next steps, and we actually begin the work. An automated system confirmation is not a response.
It concerns restoring a key process or deploying a safe temporary solution. A complete fix may take longer if the problem requires a code change, regression testing and deployment in a subsequent release.
We do not promise a single “resolution time” for every incident. We define a guaranteed response and the way the team operates according to the incident class.
How we measure SLA
We measure response time from the moment a ticket is registered in our ticketing system. The clock may be paused when resolution requires action or information from the client, or when the cause lies with an external service outside our control.
The detailed timing rules, information required in a ticket and SLA exclusions are defined in the agreement.
Technical maintenance
Magento does not remain the same system for years. Security patches, new Magento and PHP versions, and changes to libraries, modules and external services all appear over time.
Routine patch management and security updates are part of maintenance. We treat an official vendor patch as critical when it is marked critical, has a CVSS score of 9.0 or higher, or has Priority 1 status. Deployment deadlines for critical and other patches are defined in the agreement and are measurable.
We plan major Magento upgrades separately because they require verification of custom code, module compatibility and regression testing.
The goal is to prevent the store from remaining on an outdated stack for several years, turning every subsequent update into a large and risky project.
A significant share of Magento incidents exploit known vulnerabilities for which a patch was already available. For platforms that require a higher level of protection, we extend maintenance with active security monitoring.
Some tools require a separate licence on the client’s side - we will identify this at the proposal stage.
The full system
A user reports that a category takes a very long time to load. The source may be Magento code, but it could just as easily be the database, indexing or the way data is imported.
A product does not appear in the store. Sometimes the problem lies in synchronisation with the ERP or PIM.
A customer cannot see the current order status. The frontend works correctly, but the data exchange process has stopped in a queue.
This is why, when maintaining complex platforms, we look at the whole system rather than store code alone. We work with MySQL and MariaDB databases, Redis, Varnish, OpenSearch and Elasticsearch, RabbitMQ, and integrations with ERP, PIM, CRM and bespoke systems.
We cooperate with the client’s administrators or infrastructure provider. When support is needed on our side, we assist with diagnosis, configuration and environment optimisation.
Taking over maintenance
You do not need to be our implementation client to entrust us with Magento maintenance.
Before placing the platform under an SLA, we learn about the project: its code, custom modules, integrations, environments, deployment process and division of responsibility between systems. This is not intended to be a months-long audit; it simply ensures that we do not declare response times for a system whose condition we do not yet know.
If the platform is unstable, errors keep returning and the project’s technical condition is difficult to assess, a better first step is Magento project rescue and takeover . After stabilisation, the project moves into a regular maintenance model.
Fit
A standard maintenance model will mainly deal with one incident after another. Diagnosis, takeover and stabilisation are a better starting point.
Magento project rescue →If the store works functionally but struggles with TTFB, Core Web Vitals, its database, cache or indexing, a dedicated optimisation project is the right entry point.
Magento performance optimisation →We do not sell server space alone as a support service. We work with the client’s infrastructure provider or help design and optimise the Magento environment.
Questions
Yes. Before placing the platform under a regular SLA, we familiarise ourselves with its code, integrations, environments and deployment process. If the project needs more substantial stabilisation, Rescue becomes the first stage.
Maintenance covers business continuity, incidents and operational work. The hours package is intended for planned changes and development. The two models run in parallel, so incidents do not consume the budget allocated to development.
That depends on the selected package. We offer packages in which hours can roll over to subsequent months, for up to three months. Every month, we provide a summary of completed work and the remaining balance.
For critical incidents, we provide an emergency route outside standard support hours. If the platform requires a guaranteed 24/7 SLA, this needs to be designed as a separate support model.
The final classification is ours, with consultation with the client in justified cases. Priority is determined by the impact on sales and availability.
Routine patches and security updates are part of maintenance. We plan major version upgrades as separate work because they require regression testing, module verification and often adjustments to custom code.
Yes. We provide specialist support for more difficult issues, integrations, performance, updates and architectural decisions. Not every such case needs to involve replacing the current provider.
We support the diagnosis, configuration and optimisation of the Magento environment, or work with the client’s administrator. We establish the exact division of responsibility at the beginning of the engagement.
Tell us about your current support model, critical processes and the problems you encounter most often.
We'll get back to you within 12 hours of submitting.