Adobe Commerce Cloud: 12 questions answered.

ACC backs up your DB + media every 6 hours and retains 7 days by default (longer on Pro). However, vendor backups are necessary but not sufficient, for real DR you also want: (a) off-cloud backup copies (S3 to a different account), (b) tested restore runbooks (most teams have backups but never tested restore), (c) point-in-time recovery for transactional data, (d) annual DR drill. Standard Cloud Migration includes setting all of this up; Enterprise includes the DR drill.

ACC enforces a 3-tier git branch strategy by design:

• Integration: ephemeral feature branches per developer/PR. Each push triggers a deploy. Used for PR review.
• Staging: mirrors Production data (sanitised) and infrastructure. UAT happens here.
• Production: live store. Only promotions from Staging are allowed.

Done right, each branch has its own data-bridge so a Staging deploy can be tested against real-shape data without touching Production. We set this up properly on every project.

Yes, fully, ACC is just Magento 2 on AWS with managed orchestration. You ship custom modules via composer + git just like self-hosted. The constraints: (a) no kernel-level access (can’t install OS packages), (b) PHP extensions are restricted to Adobe’s supported list, (c) cron jobs run on Adobe’s schedule infrastructure. For 95% of stores, none of this matters. The remaining 5% are typically B2B with custom payment processors or ERP middleware, those need careful pre-project audit to confirm fit.

ECE-Tools (Magento\CloudPatches + magento/ece-tools composer package) is the deploy/build orchestrator for ACC. It runs your .magento.app.yaml + .magento.env.yaml hooks, generates static content, applies Adobe’s cloud patches, and configures redis/varnish/fastly. Tuning ECE-Tools is the difference between a 5-minute and a 40-minute deploy. Most stores never look at it. We do.

The default Fastly config that ships with ACC is generic, it’s a starting point, not the destination. Real tuning involves:

• Custom VCL for query-param normalisation, geo-routing, A/B-test splitting
• Image optimisation edge rules (WebP/AVIF on the fly)
• ESI fragments for personalised blocks (cart, customer name)
• Proper Surrogate-Key tagging so cache-purge is targeted not nuclear
• Bot-protection rules + rate limits

Done right, you go from 60% to 90%+ cache-hit rate, which cuts origin compute by 10× and bandwidth costs alongside.

Yes, with proper planning. The pattern: (1) spin up ACC Integration with a full database dump from your current production, (2) validate functionality on Integration + Staging, (3) set up real-time DB replication from old → new for the cutover window, (4) off-peak DNS swap with TTL pre-lowered to 60s, (5) keep old system warm for 72 hours as roll-back. Total downtime: typically 0-30 seconds during the DNS flip. Order data flows to new system immediately.

Adobe doesn’t publish list prices, but the formula is roughly: base licence (tied to your GMV tier, typically $40k-$200k/year) + infrastructure (compute, bandwidth, storage, typically $1k-$15k/month) + add-ons (extra environments, B2B module, AI services, etc.). Real total: Starter stores pay $5k-$30k/year all-in, Pro stores pay $50k-$300k/year+. The bill grows quickly with traffic and bad caching, which is why our cost-optimisation pass typically pays for itself within 2-3 months from invoice savings alone.

ACC Starter: Single AWS region, shared infrastructure, no Fastly Image Optimizer, max 4 envs, minimal SLA. Best for stores under $1M GMV. ACC Pro: Dedicated 3-node AWS cluster, Fastly Image Optimizer included, unlimited envs, 99.99% SLA, dedicated support. Best for stores over $1M GMV or with B2B / multi-region needs. Pro is roughly 4-6× Starter pricing but the SLA + Image Optimizer alone often justify it for serious stores.

The four biggest wins, in order:

• Right-size your environments, most ACC stores are 2-3× oversized on RAM & CPU. Adobe doesn’t volunteer this analysis.
• Fix Fastly cache-hit rate, moving from 60% to 90%+ cache-hit rate cuts origin bandwidth 10× and origin compute alongside.
• Audit add-ons, paid add-ons (extra environments, BlackHat, B2B, etc.) often carry beyond their useful life.
• Optimise asset storage, old media library, unused product images, orphaned PDFs, all billed monthly.

A 90-day audit typically uncovers 30-50% potential savings on the monthly invoice.

Common culprits:

• Static content compilation runs on every deploy, fix with SCD_ON_DEMAND_IN_PRODUCTION or skip-static-content build hooks.
• Composer install fetches from scratch, fix with cached composer + COMPOSER_AUTH proper setup.
• Deploy hooks run sequentially when they could parallelise.
• Database upgrade scripts on every deploy, fix with skip patches that haven’t changed.

Tuned correctly, ACC deploys go from 25-40 minutes to 3-5 minutes. We do this on every Standard Cloud Migration project.

Less than you think. ACC is just Magento 2 + AWS + Fastly + New Relic. Your codebase is portable, same composer.json works on a self-hosted server. The only ACC-specific bits are .magento.app.yaml + .magento.env.yaml + ECE-Tools dependency, all of which are open-source. Realistic exit time: 4-6 weeks to migrate from ACC back to self-hosted, vs 8-12 weeks the other way (because you’d need to set up the hosting from scratch). So lock-in is real but recoverable, much less sticky than e.g. Shopify.

It depends on your team and traffic profile. ACC is worth it when (a) you don’t want to manage servers, Fastly, New Relic, deploy pipelines, and Adobe-tier patching, (b) your traffic is variable and elastic scaling matters, or (c) you need the bundled support & SLA. It’s not worth it when (a) your team already runs DevOps fluently, (b) traffic is small and steady so a $50/mo VPS would do, or (c) you want full control over kernel-level optimisations. Most stores in $1k-$15k/mo MRR profit from ACC; below that, self-hosted on Hetzner/AWS is cheaper.