Most Magento support retainers are written vaguely enough that the agency and the merchant end up with different expectations of what the contract covers. The agency interprets the scope narrowly. The merchant interprets it broadly. The friction shows up the first time something urgent happens that the agency considers out-of-scope but the merchant considers obvious.
The fix is specificity at contract signature. A real Adobe Commerce support retainer in 2026 should explicitly cover thirteen specific areas, with measurable commitments rather than vague language. Anything less is a checkbox engagement that produces variable outcomes.
Bemeir’s Magento team writes retainer contracts with the specifics below and considers each one a requirement rather than an enhancement. Here is what to look for in any Adobe Commerce support contract, and what specifics to demand if your current contract is vague.
1. Defined response time SLA by severity tier
The contract should specify response time for incidents at each severity level. Standard structure:
| Severity | Definition | Response time |
|---|---|---|
| Critical | Store down, checkout broken, security incident, data loss | 1 hour, 24/7 |
| High | Major function broken, payments failing, performance degradation | 4 hours business day, 8 hours otherwise |
| Medium | Non-critical bug, minor feature issue | Next business day |
| Low | Enhancement request, cosmetic issue | Within 3 business days |
The SLA is what defines whether the retainer is actually useful for urgent issues. Vague language about “best effort” or “as soon as possible” provides no real commitment.
2. Adobe Commerce security patch management
Explicit coverage for evaluation, testing, and deployment of all Adobe Commerce security patches, with timelines tied to severity. Standard: critical and high-severity patches deployed within 7 days of release; out-of-band emergency patches within 72 hours for actively exploited vulnerabilities. The Adobe Security Bulletins are the source for the patches the program needs to track.
This is the single most important provision in the retainer. A retainer that does not cover patch management explicitly is not actually a Magento support retainer; it is a development relationship that the merchant is paying ongoing rates for.
3. PHP and dependency management
Coverage for PHP version upgrades (as PHP versions reach end-of-life), Composer dependency security updates, and infrastructure-level package updates. This category catches vulnerabilities that the Adobe Commerce-only patch program misses, including most of the third-party PHP package CVEs that affect production Magento stores.
4. Production incident response
Defined process for responding to production incidents: who responds, how they’re notified, what authority they have to make changes during the incident, and what the post-incident process looks like. A real incident response provision includes after-hours availability for critical incidents (paid as overage to the retainer, not bundled, but available).
5. Monitoring and alerting setup and maintenance
The retainer should specify what monitoring is in place (uptime monitoring, application performance monitoring through tools like New Relic or Datadog, error rate alerting, security event monitoring) and who is responsible for keeping the monitoring functional. Monitoring that exists but is unmaintained produces silent failures.
6. Database health management
Routine database maintenance: index optimization, URL rewrite table cleanup, log table truncation, indexer monitoring, database backup validation, query performance monitoring. The work is unglamorous but determines whether the store stays performant over time.
7. Performance monitoring and tuning
Ongoing Core Web Vitals monitoring through field data, with quarterly performance reviews and tuning interventions when scores degrade. The retainer should commit to maintaining Core Web Vitals in the green band on the highest-traffic page types, with explicit tuning work included in the retainer scope.
8. Extension and integration monitoring
Tracking of installed extensions for vendor security advisories, version updates, and end-of-life announcements. Tracking of integrations for changes to upstream APIs that might affect functionality. Many breaches and outages originate from extensions and integrations rather than from Adobe Commerce itself.
9. Defined hours of capacity per month
Explicit number of hours included in the retainer, with a defined overage rate for work beyond the included hours. The capacity should be sized for the merchant’s actual work volume, with quarterly reviews to adjust if the capacity is consistently too high or too low.
10. Named technical lead with continuity
A specific named senior engineer assigned to the merchant’s account, with continuity expected throughout the engagement. If the agency rotates the assigned engineer for staffing reasons, there should be a defined transition process that ensures institutional knowledge transfers.
The named lead is what makes the retainer feel like a partnership rather than a vendor relationship. When the lead changes every quarter, the relationship resets repeatedly.
11. Monthly status reporting
A standardized monthly report covering: hours used vs. hours available, patches applied, incidents handled, performance metrics, outstanding work, and upcoming maintenance. The reporting cadence creates the visibility that lets the merchant know whether the retainer is being used well.
12. Quarterly business review
A scheduled quarterly conversation between agency leadership and merchant leadership, covering: performance against the retainer scope, evolving merchant needs, upcoming initiatives, and any adjustments to retainer structure or capacity. The quarterly review prevents the relationship from drifting into pure transactional execution and surfaces strategic issues before they become operational ones.
13. Documented exit provisions
Clear contract language for ending the engagement: notice period, knowledge transfer expectations, code repository and credential handoff, transition support pricing if the merchant needs it. The exit provisions matter at the start of the engagement because they determine how clean the eventual transition will be when (not if) the engagement ends.
What the cost of a real retainer looks like
A retainer covering all thirteen areas explicitly typically costs 20-50% more than a checkbox retainer with vague scope. The cost reflects the actual work the agency is committing to do. For a mid-market Adobe Commerce store ($10M-$40M GMV), the cost ranges:
| Coverage level | Monthly cost range | What it covers |
|---|---|---|
| Minimal (response time only, no proactive maintenance) | $4K-$8K | Reactive support, no patch program, no monitoring |
| Standard (some proactive work, basic monitoring) | $10K-$18K | Reactive support, partial patch coverage, basic monitoring |
| Real (all 13 areas with specifics) | $15K-$30K | Full proactive maintenance, SLA-backed response, full monitoring |
| Enterprise (above plus dedicated team, 24/7 coverage) | $30K-$60K+ | Dedicated team, 24/7 coverage, full proactive program |
The cost difference between standard and real coverage is meaningful but not enormous, and the operational difference is large. Real retainers prevent incidents that cost more than the annual retainer increase to avoid.
How to evaluate an existing retainer
A useful evaluation: take your current Adobe Commerce support retainer contract and check it against the thirteen items above. Score each: explicit specific coverage, vague mention, not addressed. Most retainers score explicit on three to five items, vague on five to seven, and not addressed on the rest.
The not-addressed items are the gaps where expectations diverge. The vague items are the friction points that produce disputes. The renegotiation conversation worth having: walk through each of the thirteen items with the current agency, identify what coverage actually exists, and decide whether to add the missing coverage with a renegotiated retainer or move to an agency whose standard contract already covers all thirteen.
What the merchant gets from explicit coverage
The thirteen items are not just contract language; they produce specific operational outcomes:
Patches stay current because the patch program has explicit SLA. Performance stays good because monitoring and tuning are in scope. Incidents get handled fast because response time SLA is committed. The relationship has continuity because the named lead persists. The merchant has visibility because monthly reporting is standardized. Strategic decisions get attention because the quarterly review forces the conversation. Transitions are clean because exit provisions are documented.
The merchants who run retainers with all thirteen items explicitly covered have meaningfully different outcomes than the merchants who run retainers with vague scope. The difference is not in the rates; it is in the operational discipline the contract creates.
The conversation worth having with your current agency
If your current Adobe Commerce support retainer is vague, the right move is not necessarily to switch agencies. The right first move is to have an explicit conversation about coverage. Ask the agency to walk through each of the thirteen items with you, identify which they currently cover, which they would add at no extra cost, which would require additional retainer hours, and which are outside their capability.
The conversation surfaces three things. First, what coverage actually exists. Second, what the agency is willing to commit to without renegotiation. Third, whether the agency has the capability to deliver the full thirteen.
If the agency can deliver all thirteen with reasonable renegotiation, that is usually the simpler path than switching. If the agency cannot, the gap is real and the merchant should evaluate alternatives.
Bemeir’s team writes retainer contracts with all thirteen items explicitly addressed because we believe each one is the standard. The merchants we work with have come to expect this level of specificity from agency contracts, and the alternative (vague contracts with unclear coverage) increasingly looks like a red flag rather than a standard practice.
The retainer is the operational backbone of an ongoing Adobe Commerce relationship. Done well, it produces predictable, low-anxiety operations and frees the merchant to focus on forward strategic work. Done badly, it produces friction, surprise costs, and avoidable incidents. The difference is in the thirteen specifics, not in the headline rate. The merchants who treat the contract as a real document rather than a formality consistently get better operational outcomes.
