Why a Magento Open Source store moves its message queues off MySQL
Moving a Magento Open Source store's asynchronous work off the MySQL queue adapter and onto a message broker is a configuration and operations change, and it has to be planned around the consumers that Magento runs on your release. Stores usually start this work when bulk operations, asynchronous API requests or publishing jobs slow down, or when failures sit in database tables that nobody watches until a merchant asks why a change never appeared. The symptoms justify the work, but they do not tell you which consumers to move first, how each one will be supervised, or who will respond when a backlog grows.
Adobe's system requirements for Magento Open Source 2.4.9 list RabbitMQ 4.3, and the 2.4.8-p5 requirements list RabbitMQ 4.3 as well, so stores on either line have a documented broker version to target. Adobe supports only the listed combinations, so confirm the full stack against the system requirements page for your release before you select a broker version. ActiveMQ Artemis is a different case. Do not assume support for it. Confirm Artemis support against Adobe's documentation for the exact release you run, and keep a record of the page and version you checked, before any design work starts. If Artemis is a broker your organization already operates, that check decides whether it is a candidate at all.
DeployOpen plans and implements this change inside your own infrastructure, whether that is your cloud accounts, your data centers or an air-gapped network. The work covers which consumers your release runs, how each one is started and supervised, which queues each one reads, and which accounts, network paths and TLS settings the store and the broker use to talk to each other. These decisions belong in the design before anything changes on the store, because a consumer that is misconfigured or not running can leave messages unprocessed with no visible error on the storefront. Treat the broker, its access controls and its monitoring as part of the production estate from the first day.
Start with an inventory of what the database queue holds today. Record which topics have pending messages, how old the oldest pending message is, and which topics show repeated failures. Ask your developers and extension vendors which custom consumers exist, because each one needs a planned place on the broker. Then decide who owns the broker after go-live and who responds when a backlog grows past the threshold your team sets. The inventory, the custom consumer list and the ownership decision shape every later choice on this page.
What the platform, broker and hosts need before the change
This section lists what must be in place before you switch the queue adapter. The platform versions come from Adobe's requirements for the two supported release lines. The broker and host items are checks you complete against your own infrastructure and the broker vendor's documentation. Confirm each card before you order hardware or size the broker.
PHP, Composer, nginx and Varnish
Magento Open Source 2.4.9 requires PHP 8.5, Composer 2.10 and nginx 1.30 on Linux x86-64. The 2.4.8-p5 release lists PHP 8.4 or 8.3, Composer 2.10, nginx 1.30 and Varnish 8 for the full-page cache. Adobe supports only the listed combinations, so pin your PHP build and Composer version to one row of the table. Confirm that consumer hosts run the same PHP build as the web tier, because consumers load the same codebase as the storefront.
MySQL, OpenSearch and Redis or Valkey
Each release line pairs the queue work with specific data services. The 2.4.9 requirements list MySQL 8.4 or MariaDB 12.3 (recommended) or 11.8, OpenSearch 3, and Redis or Valkey 9. The 2.4.8-p5 requirements list MySQL 8.4 or MariaDB 11.4 or 11.8, OpenSearch 3, and Redis or Valkey 8.1. Consumers write to the same database and cache, so confirm that every service your consumers touch sits inside the supported row before you change the adapter.
RabbitMQ 4.3 on a dedicated broker
Adobe's requirements for both release lines list RabbitMQ 4.3. Run the broker on its own host or cluster, sized separately from the store, so that a backlog or restart does not starve the web tier. Confirm with Adobe whether ActiveMQ Artemis is supported for your release before you order or size anything, because the listed requirements name RabbitMQ 4.3. Record the broker version, node count and disk allocation you plan to use.
Network paths from web and consumer hosts
Every web node that publishes messages and every consumer host that reads them needs a route to the broker port and to the database. Map each path before the change, listing the source host, destination port and the firewall or security group rule that allows it. Consumer hosts often sit apart from the web tier, so check them separately. Confirm that the broker's management interface is reachable only from administrator networks.
TLS and broker credentials
Decide how connections are encrypted and authenticated before you write the queue settings. Confirm which TLS options your broker offers for the protocol your release uses, which certificate authority signs the broker certificate, and who renews it. Create a dedicated broker account for the store with only the permissions it needs, and keep its password in your secrets manager and out of version control.
A non-production copy of the store
Test the change on a copy of production code, configuration and a recent database snapshot before it reaches live traffic. The copy should run the same Magento release, PHP build, broker version and consumer count as production so that test results carry over. Load it with a representative catalog and order volume, and rehearse draining the existing MySQL queue backlog before cutover.
How Magento hands work to consumers and why the broker changes operations
The core operational change is where queued work lives and who watches it. When Magento code needs work done outside the page request, it publishes a message to a named topic, and a consumer picks the message up later and processes it. With the MySQL queue adapter, those messages are stored in database tables inside the same MySQL environment that serves the store. The queue therefore shares backups, replication, capacity and maintenance windows with the database. With RabbitMQ or ActiveMQ Artemis, messages move to a separate broker, and MySQL no longer holds the queue.
Consumers are the processes that drain the queue, and how they start and stay alive differs between the two designs. Adobe documents consumer startup for both cases, usually through a cron-driven runner or a process supervisor, and the choice has direct consequences. If cron stops, or a long-running consumer process exits without restart, pending work accumulates with no error on the storefront. Confirm in Adobe's documentation for your release the exact consumer names, the commands that start them and the configuration keys that control them. This page does not list those names or keys, and a mismatch is a common cause of silent backlogs.
A backlog looks different in each design. With the MySQL adapter, pending work appears as rows in database tables that keep growing, which you can query, but the tables are also the store's own data store, so a large queue adds load to the database. With a broker, the backlog is measured as queue depth, unacknowledged messages and consumer count per queue, and a queue with messages but no consumers is the most important signal to alert on. Dead-letter handling, where configured, moves messages that repeatedly fail into a separate queue, so failed work becomes visible rather than vanishing into retries.
Once the broker is in place, it is a separate service with its own availability, storage and monitoring needs. Ask who owns it, where it runs, how it is backed up, and how upgrades are tested against your Magento release. For 2.4.9, Adobe's system requirements list RabbitMQ 4.3, so check that version against your target release before you choose a broker. For ActiveMQ Artemis, confirm the supported version in Adobe's requirements for your release. Failure visibility moves from database tables and Magento logs to broker management tooling and metrics. Plan alerts for disk and memory alarms, unreachable broker connections, and growing queue depth before the first go-live.
Configuration sequence for the broker change
This sequence moves Magento Open Source asynchronous work from the MySQL queue adapter to a RabbitMQ or ActiveMQ Artemis broker in a fixed order. Each step closes with a check you can record, so the change is proven in a non-production environment before any production cutover.
Confirm the release and broker version
Start by matching your Magento Open Source release line to Adobe's system requirements for that exact patch level. For 2.4.9 and 2.4.8-p5, Adobe's requirements list RabbitMQ 4.3, but the supplied requirements do not cover ActiveMQ Artemis, so ask Adobe in writing which Artemis versions it supports for your release before choosing that broker. Your team or the partner records the chosen broker version and the matching PHP, MySQL or MariaDB, and OpenSearch versions. The step is done when the combination is written down and checked against Adobe's published list.
Provision the broker with TLS and separate credentials
Install the broker in a non-production environment inside your own network, enable TLS for client connections, and create a dedicated service account for the store and the consumers. Keep the broker administrator account out of the store configuration. The check is a successful authenticated connection from the web tier and a consumer host over TLS, with a rejected connection when the wrong credentials are used.
Back up the database and queue state
Take a full database backup and record the number of pending messages still held in the MySQL queue tables before any configuration changes. Restore that backup to a scratch database to confirm it is readable. Plan how messages still waiting in the old adapter will be drained or replayed during cutover. The step is complete when a restore test succeeds and the pending message count is written down with the backup reference.
Point staging at the broker
Point a staging store at the new broker by updating the queue connection settings in the environment configuration, then run the install or configuration steps Adobe documents for your release. Compile and deploy the store as Adobe describes, and confirm the broker host, port and TLS settings read back correctly. The check is that the deployment completes without errors and the queue consumer list shows the expected consumer names on the new connection.
Start consumers under the chosen supervisor
Start each consumer under the process supervisor or cron design your team selected, and make sure restarts after a crash or host reboot are configured. Confirm each consumer reports as running. Then publish a test message, for example a harmless bulk or asynchronous operation, and check that it is consumed end to end. The step is done when every consumer reports running and the test message completes.
Run test bulk and async API batches
Send a test batch of bulk and asynchronous API requests that reflects the operations your integrations really perform, such as product or order updates. Watch the queue depth on the broker while the batch runs, then confirm the backlog returns to zero once the load ends. Check that each request reaches a completed status and that results match the expected data in staging. The step is complete when the backlog drains and the results are reconciled.
Review broker and consumer logs
Review broker logs and consumer logs after the test batch for connection errors, repeated redeliveries, and messages that land in a failure or dead-letter path. Confirm that your failure handling, such as retry limits and alerting on stuck messages, behaves as designed when you force a controlled failure in staging. The check is a log review signed off by the operations owner, with every error either explained or fixed and logs forwarded to your monitoring.
Repeat the verified sequence in production
Once staging passes every check and the operations owner signs off, run the same sequence in production during the change window you agreed. Repeat the backup, the pending message count, the consumer status check and the test message before opening the store to live traffic. The step is done when production consumers report running, the test message is consumed, and the queue backlog stays at zero under normal load.
Queues, consumers and data mapped between Magento and the broker
This table maps each asynchronous flow in a Magento Open Source store to its producer, consumer, failure path and monitoring signal. Read each row as a question to answer for your chosen release, since consumer names and retry behavior can change between 2.4.x lines and must be checked in Adobe's documentation. The main takeaway is that broker credentials and message contents need the same design attention as the queues themselves.
| Flow | Producer and consumer | Failure and retry | Monitoring signal |
|---|---|---|---|
| Bulk operations | Admin or API actions publish a bulk operation, and a bulk consumer processes the batch. Confirm consumer names with the queue consumer list command for your release. | Failed items should be traceable per operation. Confirm whether failed operations can be resubmitted and how Adobe documents this for your release. | Consumer process status, queue depth for the bulk topic and operation status counts. |
| Asynchronous API requests | Client requests are accepted and published to a topic, and a consumer writes the result for later retrieval. Confirm the async route, headers and response format for your release. | Confirm how the consumer handles exceptions and whether failed messages stay in the queue. Define replay ownership before go-live. | Age of the oldest message, consumer restarts and status responses for polled requests. |
| Catalog and index update messages | Store events such as product saves publish messages, and consumers update derived data. Confirm which topics run under cron and which need a long-running supervised process. | Plan idempotent processing so that a reprocessed message does not change the result. After an outage, confirm which reindex or cache steps are needed. | Backlog trend and the time between a product save and the storefront update. |
| Order, stock and ERP exchange | Confirm which order and stock topics your extensions publish. Any consumer that calls the ERP must authenticate with its own integration service account. | Agree duplicate handling with the ERP team. Confirm broker redelivery settings and what happens to unacknowledged messages. | Unacknowledged count, redelivery count and ERP-side reconciliation totals. |
| Custom module topics | Each custom topic needs a declared publisher, consumer and message schema in the module configuration. Confirm the declaration format for your release. | Document poison message handling, including who inspects and replays messages that repeatedly fail. | Publish and consume counts per topic, compared with expected daily volume. |
| Broker support | Adobe's 2.4.9 and 2.4.8-p5 requirements list RabbitMQ 4.3. ActiveMQ Artemis is not in the requirements we reviewed, so confirm support with Adobe before choosing it. | Plan broker upgrades alongside Magento patch cycles and test queue behavior on the new broker version first. | Broker version in each environment compared with the version listed for your Magento release. |
| Broker credentials | Each environment (development, staging and production) uses its own broker service account, limited to the virtual host and queues it needs. Producers and consumers in one environment use only that environment's account. | Rotate credentials on a schedule and when staff change. Document the rotation steps and the consumer restart they require. | Failed authentication attempts in broker logs and connections listed by user. |
| Message payload content | Message bodies carry identifiers and status fields only. Customer records, card data and full addresses stay in the store, and consumers fetch details through the store's own access controls. | Treat personal data found in a dead-letter or retry queue as a data handling incident under your own policy, and involve your privacy lead. | Periodic sampling of queue contents in non-production and a schema check on new message types. |
Securing the broker, credentials and message content
A message broker sits between checkout, order and customer workflows, so it inherits the same security questions as the store. The cards below cover who can reach the broker, how connections and credentials are protected, where the broker runs, what messages and logs contain, and which Magento obligations still apply.
Separate broker users per environment
Give each environment its own broker user, with permissions limited to the virtual hosts, queues and actions that Magento publishers and consumers need. Production, staging and development should never share an account, and the broker administrator account should not appear in any Magento configuration. Review who can publish, consume and purge queues, and confirm the exact permission model in the documentation for your RabbitMQ 4.3 or ActiveMQ Artemis version.
TLS between Magento and the broker
Encrypt the connection from every Magento web and consumer host to the broker, including the ports used by consumers and any management traffic. Decide where certificates are issued, how they are rotated and which certificate authority the hosts trust. Test that a client rejects a broker certificate it does not trust, and confirm the supported TLS options with Adobe's system requirements for your Magento release.
Broker credentials outside web-readable files
Keep broker passwords out of files under the web root, out of version control and out of shared deployment artifacts. Store them in a secrets manager or in server-side configuration readable only by the deployment user and the consumer service account, and rotate them with a documented procedure. Check that error logs, debug output and phpinfo pages never print the connection details.
Broker isolation and management interface
Place the broker on a private network segment reachable only from Magento web and consumer hosts, with no route from the public internet. Restrict the management interface to a named administrative network, use individual accounts instead of shared logins, and turn off the interface on any host that does not need it. Confirm which authentication options your broker version supports for that interface.
Limit what messages and logs contain
Review each message type Magento publishes and keep payment data and unnecessary personal fields out of payloads where the design allows, since consumers can usually load the underlying record by its ID. Broker and consumer logs can capture message bodies, queue names and errors, so set log levels that avoid payloads and align the log retention period with your store's retention rules.
PCI DSS scope and platform duties
Add the broker to the architecture diagram before the PCI DSS scope review, because any system that stores, processes or transmits cardholder data, or that could affect its security, needs to be assessed. Magento's Content Security Policy and Adobe's patching guidance still apply to the platform itself, so keep the release and patch level current whatever broker you choose.
Which consumers to run and how to keep them alive
Start by deciding which hosts run consumers, because that choice shapes everything else. Keep the web tier, which serves storefront pages, admin requests and API calls, separate from the consumer tier, which processes queued work such as bulk operations and asynchronous API requests. Separate hosts let you add worker capacity without adding web capacity, and they keep a heavy queue job from slowing down shoppers. Build the consumer list from two sources: the consumer definitions in the Magento Open Source release you run, and the queue and communication configuration in every custom module your store uses. Custom modules often add consumers that appear in no standard list, so a review of the code is the only reliable check. Confirm the final list in staging before you assign consumers to hosts.
Consumers can run in two ways. On-demand execution under cron starts a process on a schedule, drains the messages waiting for it and exits. Memory is released between runs and failures are easy to see, but work waits for the next scheduled run, and overlapping runs need a guard so two processes do not claim the same messages. Long-lived execution keeps a process running under a process supervisor, so messages are handled as they arrive. Latency is lower and the process stays warm, but that process must stay healthy for long periods. Most teams run long-lived processes for queues that customers or staff wait on, and cron for slower batch work where a delay of several minutes is acceptable. Confirm with the release documentation whether each consumer supports both modes.
The main trade-offs are restarts, memory growth and concurrency. Long-lived PHP processes can grow in memory as they handle many messages, so plan a recycle point, either after a message count or at a memory ceiling, and let the supervisor start a fresh process. Each recycle briefly reduces capacity, so choose a limit high enough to avoid frequent restarts and low enough to bound growth. Concurrency is the number of processes per consumer. More processes raise throughput, but they also raise database connections, broker connections and load on any external service the jobs call. Start with a small number of processes per consumer, measure queue depth and database load, and increase only where the backlog is the constraint. Verify the message-count and memory options in the release documentation before you rely on them.
Process supervision needs three basics. First, a restart policy: the supervisor should restart a consumer when it exits for any reason, use a backoff so a crash loop does not exhaust the host, and raise an alert when restarts repeat. Second, a known log location with rotation and retention, so a failed message can be traced to its consumer, time and error without logging into the host by hand. Third, a controlled restart at deployment: after a code change, running workers keep the old code until they restart, so the deployment process must stop consumers cleanly, allow in-flight messages to finish, and start them again on the new code. Write these steps as a runbook, and test each one by stopping a consumer on purpose in staging before go-live.
Common failures when queues move to a broker
This table lists the failures teams most often meet after moving Magento Open Source queues from the MySQL adapter to RabbitMQ or ActiveMQ Artemis. Each row gives the symptom, the usual cause, the first check and the type of fix. Start with the consumer and connectivity rows, because most of the other failures only appear once messages are flowing through the broker.
| Failure | Likely cause | Check first | Fix category |
|---|---|---|---|
| Consumers not running after deployment | Consumer processes were stopped during a code deploy and never restarted, or the cron or supervisor entries were not reinstated on every host. | List consumers and their running state on each web and consumer host. Compare the cron and supervisor configuration with the previous release and review the deployment log. | Deployment process: restart consumers as a deploy step and add process monitoring with alerts. |
| Messages accumulating with no consumer | A consumer is disabled in the environment configuration, is not assigned to the queue, or runs on a host that cannot reach the broker. | Check queue depth per queue in the broker's management interface, then compare it with the consumers listed by Magento. Review the queue settings in env.php. | Configuration: correct consumer assignment and start the missing consumers, then add backlog alerts per queue. |
| Broker unreachable from consumer hosts | Firewall rules, DNS records, the wrong host or port, or a broker listener bound to an interface the consumer hosts cannot reach. | Test the connection from each web and consumer host to the broker port. Confirm the connection settings in env.php and check the broker's own logs for rejected connections. | Network or configuration: open the required path or correct the host, port or listener settings. |
| Certificate or credential mismatch | A broker password or permission was changed without updating every host, a TLS certificate expired, or the PHP client does not trust the certificate chain. | Compare the credentials and virtual host in the Magento connection settings with the broker user definition. Check certificate expiry dates and the chain presented by the broker. | Credential management: align credentials on all hosts, renew or re-chain certificates, and add both to the rotation runbook. |
| Duplicate or lost processing during restarts | Consumers stop while handling a message, handlers are not idempotent, or queues and messages are not set to survive a broker restart. | Review unacknowledged message counts on the broker during restarts, consumer shutdown entries in the Magento logs, and the durability settings of each queue. | Application design and broker settings: make handlers safe to repeat, use graceful consumer shutdown and confirm durable queues. |
| Bulk operations stalling | The consumer that handles the bulk or asynchronous API queue is not running, a batch is too large for the PHP memory or time limits, or the operation is waiting behind a long backlog. | Check the status of the bulk operation in the admin, confirm the consumer for that queue is running, and search the PHP and Magento logs for memory or time limit entries. | Operations and sizing: start the missing consumer, split large batches and adjust limits only after testing in staging. |
| Version mismatch between Magento and the broker | The broker version is outside the RabbitMQ version listed for the Magento release in use, or the PHP client extension does not match the broker. | Compare the broker and PHP extension versions with Adobe's system requirements for your exact 2.4.x release and patch. Adobe lists RabbitMQ 4.3 for 2.4.9 and 2.4.8-p5. | Upgrade: move the broker or Magento to a supported combination and test the full queue flow in staging first. |
Questions buyers ask before they hire help with message queues
How much does help with Magento message queues cost?
Cost follows the written scope, and DeployOpen does not publish a price list, so a quote is based on that scope. The main cost drivers are the number of consumers and the hosts that run them, your broker choice and whether the broker is self-hosted in your infrastructure, custom modules that publish or consume messages, the volume of testing you need, and how many environments must match production. One-time costs usually cover design, broker setup, consumer configuration, custom module work and load testing. Recurring costs cover broker hosting, monitoring and patch cycles, which you can keep in-house or place under a retainer. Ask every quote to split these lines and to state who pays for the broker infrastructure.
How long does it take to move Magento queues off the MySQL adapter?
Duration depends on the written scope, so ask for the timeline in the statement of work. The drivers are the number of consumers to configure, the number of custom modules that touch the queue, the number of environments to build, how much load testing you require, and whether a new broker must be built from scratch. Projects most often slow down while waiting for access, a staging store or test data, so a good schedule names each dependency and its owner. Ask the partner to show which milestones depend on your team and which depend on theirs before you sign.
Does Adobe support ActiveMQ Artemis for Magento Open Source 2.4.9?
Confirm ActiveMQ Artemis support for your exact Magento Open Source release with Adobe before you choose it. The Adobe system requirements for 2.4.9 and for 2.4.8-p5 name RabbitMQ 4.3 as the message broker, and Adobe supports only the combinations it lists. If your plan depends on Artemis, get written confirmation from Adobe that the version you run is supported, along with any configuration limits. Check this again at each patch and upgrade, because the supported combinations change with each release line.
What does my team need to provide for a Magento queue project?
Your team provides access, inputs and an owner. Access means administrative and shell access to the Magento hosts, the broker hosts and the monitoring tools, plus network paths between them. You provide a staging store that mirrors production configuration, load samples such as representative order, import and API request volumes, and test accounts for any payment or ERP integrations the queues feed. You also name an owner for the broker who approves changes, receives alerts and decides on incidents. Without that owner, consumer failures and backlogs often go unnoticed after go-live.
Can our in-house team set up Magento message queues without a partner?
Yes, an in-house team can do this if it has Magento developers who understand the queue framework, someone who operates message brokers, and people who can run Linux services under cron or a supervisor. The harder parts are consumer concurrency, retry and failure handling, poison messages, and load testing that matches real traffic. Test your team against this list before you commit, and run a pilot on staging first. A partner can take the design, build and load testing, or only the parts your team cannot staff, and the split should appear in the written scope.
How many Magento queue consumers should we run, and where?
Start by listing which asynchronous work moves to the broker, such as bulk operations, asynchronous API requests and integration tasks. Each consumer type reads from its own queue, so decide how many processes each needs and which host runs them. Run consumers under cron or a supervisor so they restart after a failure. Begin with conservative concurrency, measure backlog under your load samples, and adjust. Confirm the consumer list and the required settings against the documentation for your Magento release before you finalize the layout.
What breaks when Magento message queues fall behind?
Backlogs grow when consumers stop, crash or run too slowly, and they can build quietly if nobody watches queue depth. Common causes include consumers that did not restart after a deploy, supervisor misconfiguration, memory exhaustion, database locks, broker disk alarms and custom modules that throw exceptions on certain messages. Monitor queue depth, consumer count, the age of the oldest message and failure logs. Set alerts and a short runbook for the broker owner. Illustrative example: a custom module fails on one order type, retries pile up, and the backlog grows until the alert and runbook identify the failing message.
Does a Magento queue project need a separate broker host?
Not always, but a separate broker host is common because it isolates queue load from the web and database tiers and lets you size, patch and back up the broker on its own schedule. A small development or staging setup can run the broker on an existing host. For production, the choice depends on load, availability requirements and how your team operates infrastructure. Confirm the broker placement against Adobe's system requirements for your release. DeployOpen builds and documents the chosen layout in infrastructure you control, so the decision can be reviewed before the build starts.
How DeployOpen scopes and delivers the queue change
DeployOpen plans the move of Magento Open Source asynchronous work from the MySQL queue adapter to RabbitMQ or ActiveMQ Artemis as a written, fixed-scope change inside your own infrastructure. The work covers which consumers run, how they are supervised, how backlogs and failures are monitored, and how the team that runs the store operates it afterward.
How we scope
- Inventory the consumers, bulk operations and async API processes your store actually uses before choosing a broker.
- Confirm the RabbitMQ or ActiveMQ Artemis version against the Adobe system requirements for your exact 2.4.x release.
- Record the cron or supervisor model, queue names, worker counts and failure handling in the written scope.
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
How we build
- Stand up the chosen broker in your environment with access restricted to the Magento hosts that need it.
- Configure consumer runners under cron or a process supervisor and test restart behavior after a node reboot.
- Test bulk and async API requests against a staging copy of your catalog and order volume before cutover.
- Document the consumer map, configuration values and rollback steps so the change can be repeated in other environments.
How we hand over
- Deliver runbooks for starting, stopping and draining each consumer, with the commands your operators will use.
- Provide monitoring definitions for queue depth, consumer status and dead or failed messages, with alert thresholds agreed with your team.
- Walk your operations staff through backlog triage and failure replay using a documented procedure.
- Record what was changed, where it lives and which Magento version and broker version it was tested against.
How we support
- Ongoing support, patch-cycle upgrades and continuous testing are available as retainers after handover.
- Revalidate the queue setup when you move to a new 2.4.x release, since broker support follows Adobe's compatibility lists.
- Ask for a quote built from the written scope, including which parts recur under a retainer and which are one-time.
