Draft — pending editorial review by the 1Digital® content team. This post is a strategic foundation for a human writer to polish. Do not publish without review.
Adobe Commerce — what most of us still call Magento — is a platform that rewards discipline and punishes neglect. Unlike Shopify, where the platform itself is vendor-managed and the merchant rarely thinks about patches, Magento is an open-source application that the merchant or partner runs and maintains. That difference shapes everything about what a Magento support contract should actually cover.
A retainer that ignores patches, security, and upgrade hygiene is not a Magento support retainer. It is a deferred-maintenance bill with a monthly invoice attached.
The Adobe Commerce Patch Cadence
Adobe ships security patches and platform releases on a defined cadence:
Security patches are released periodically — sometimes on a regular monthly cadence, sometimes as out-of-band releases for actively exploited vulnerabilities. Critical security patches need to be evaluated within 48 hours of release and applied within two weeks for any store running real revenue. Stores that skip security patches accumulate exposure at compound interest.
Quarterly platform releases add features, deprecate older APIs, and update the underlying dependency tree. These releases require regression testing — not because Adobe ships breaking changes carelessly, but because the surface area of an extension-heavy Magento store means even contained changes can interact with module customizations.
Annual major releases — Magento 2.4 → 2.5, eventually 2.5 → 3.0 — require real upgrade planning. These are not patch-and-deploy operations. They are upgrade projects with their own discovery, regression testing, and cutover discipline.
A Magento support retainer that does not have a written patch policy is incomplete. The policy should specify:
- Which patches get applied automatically versus reviewed first.
- The maximum window between patch release and patch deployment for each severity tier.
- The regression testing scope for each patch level.
- The named owner for patch decisions on the merchant's side.
What Should an Adobe Commerce Support Retainer Cover?
The five workstreams that a serious retainer covers:
1. Security and Patch Management
Already covered above. This is the workstream most often underestimated by merchants and most expensive to neglect.
2. Performance Monitoring and Optimization
Magento stores degrade. Catalog growth, traffic growth, indexer load, cache invalidation patterns, and database growth all push performance in the wrong direction over time. A healthy retainer includes:
- New Relic, Datadog, or equivalent APM monitoring with defined alerting thresholds.
- Indexer schedule monitoring — Magento's indexers (catalog, price, inventory, search) need to run on a schedule that fits the catalog update cadence, and stale indexers cause storefront issues fast.
- Cache tuning — Varnish, Redis (for backend and session cache), and FPC strategies that match the traffic profile.
- Quarterly performance audits with a written remediation backlog.
3. Extension Hygiene
The extension marketplace is one of Magento's strengths and one of its largest sources of debt. A serious retainer maintains:
- A documented extension inventory with installed versions and vendor status.
- A policy on when extensions get upgraded versus replaced.
- A clear stance on custom-modified extensions (which are upgrade landmines if undocumented).
- Compatibility testing of extensions against the next platform release before that release ships.
4. Reactive Support and Bug Resolution
The reactive workstream — things break, the team fixes them. The right SLA depends on the merchant's risk profile. Our framework:
- Critical (storefront down, checkout broken, payment failure): response within 1 business hour, on-call coverage for stores with weekend traffic.
- High (major feature degraded, integration failure): response within 4 business hours.
- Standard (small bugs, UI issues, content fixes): response within one business day.
The on-call dimension is more consequential on Adobe Commerce than on Shopify Plus because the failure modes are different — a Shopify Plus store on a vendor-managed platform fails differently than a self-hosted Magento store with its own infrastructure.
5. Strategic Roadmap and Iteration
The fifth workstream covers conversion-rate work, merchandising experiments, new feature builds, and ongoing improvements. This is where a retainer becomes an extension of the merchant's team rather than a break-fix service.
What Should Be Explicitly Excluded?
Honest exclusions make the retainer scope cleaner:
- Major Magento version upgrades (these are projects, not retainer work).
- Net-new theme or design system builds.
- Multi-week integration projects beyond a defined hour ceiling.
- Migrations off Adobe Commerce to another platform.
- Hosting or infrastructure changes beyond routine maintenance.
Our Magento support practice scopes retainers with explicit inclusion and exclusion lists so the merchant and the team agree on the surface from day one.
The Hosting Topology Affects the Retainer Scope
Three hosting paths for Adobe Commerce:
Adobe Commerce Cloud (PaaS). Adobe manages the underlying infrastructure. The retainer scope focuses on application-level work — patches, extensions, performance tuning at the application layer, and operational support. The infrastructure work is Adobe's.
Self-managed cloud infrastructure (AWS, GCP, or equivalent). The retainer needs to either include or explicitly partner with an infrastructure team that handles servers, networking, database, cache layers, and observability. The line between application work and infrastructure work needs to be drawn clearly.
On-premises or co-located. Rare in 2026, but it exists for merchants with specific compliance requirements. The retainer scope extends to physical infrastructure considerations, which most agencies do not handle directly.
Most merchants we work with run on Adobe Commerce Cloud or on AWS — the third path is unusual. The retainer scope should be written against the actual hosting topology, not a generic template.
Magento-Specific Operational Considerations
Indexer Health
Magento's indexers translate raw catalog and pricing data into the structures the storefront actually queries. Stale indexers cause stale prices, stale inventory, and search misses. The retainer should include indexer monitoring as a baseline operational practice.
Static Content and Cache Strategy
Magento's static content generation, full-page cache, and block cache strategies all interact with deployment patterns. Deployments that do not properly flush or warm the cache cause performance dips that show up as inventory or pricing issues to operations teams. A retainer with deployment discipline avoids this entire class of incident.
Multi-Store Configuration
Merchants using Magento's multi-website or multi-store features have a more complex operational surface — store-scoped configuration, scoped customer accounts, scoped catalogs. The retainer should include the operational discipline to keep multi-store configurations coherent over time.
HPOS, Async APIs, and Adobe Commerce's Evolving Stack
Adobe Commerce continues to evolve. Asynchronous APIs, message queues, and recent architectural moves toward HPOS-style high-performance order storage (mirroring WooCommerce's High-Performance Order Storage in spirit) all change the operational surface over time. A retainer worth paying for tracks these changes and adapts the operational practice accordingly.
Frequently Asked Questions
How many hours per month does an Adobe Commerce retainer typically need?
Honest range: 40 to 80 hours per month for mid-market merchants with healthy operations, 80 to 160+ hours per month for enterprise merchants with complex operations, B2B requirements, or multi-store configurations. The hour count tracks operational complexity more than revenue.
What if my store is behind on patches?
This is common — and the right first step is an audit, not a retainer. We scope a security and upgrade audit as its own engagement, deliver a remediation plan, and execute the catch-up work before transitioning into ongoing retainer scope. Trying to absorb a multi-version catch-up inside a normal retainer hides the cost and rushes the work.
Should I keep my store on Adobe Commerce or migrate?
That is a separate question, and the right answer depends on operational fit and total cost of ownership. The Shopify Plus vs Adobe Commerce writeup walks through that decision framework. The BigCommerce vs Shopify for B2B writeup is the right read if BigCommerce is on the table. And our Magento to Shopify Plus migration practice runs those migrations when the math supports them. Our eCommerce platform migrations overview covers the broader migration framework.
How do I evaluate a Magento support partner?
The questions to ask: What is your patch policy? How do you handle out-of-band security releases? How do you maintain the extension inventory? What is your on-call structure? Do you have direct Adobe Commerce certifications on your team? A vague answer to any of these is a signal to keep looking.
Our Magento enterprise and Magento support practices specialize in this work. We have run Adobe Commerce engagements long enough to know what a healthy operational practice looks like — and what an unhealthy one looks like.
Scoping Your Magento Retainer
The right retainer is built around your specific operational reality — your hosting topology, your extension inventory, your traffic patterns, your team capacity, and your risk tolerance. A retainer scoped from a generic template will fit your store the way a generic template fits any store: not very well.
Start a conversation with our team and we can walk through your current state, your operational pain points, and a retainer scope that matches the actual surface of your Adobe Commerce instance.