Adobe Commerce support in the UK

Adobe Commerce support should keep your store trading safely, resolve faults and make changes repeatable. That means more than responding to a ticket: someone needs to understand your checkout, extensions, integrations, hosting and deployment process, with clear ownership when something fails.

Magento Patches provides independent technical support for UK merchants, covering security patches, version upgrades, troubleshooting and managed maintenance. This is not Adobe's own support desk or a replacement for your Adobe contract. The right starting point depends on whether you have an active incident, a defined piece of work or an ongoing maintenance gap.

A useful scope names the affected workflow, the change required and how success will be demonstrated. 'Fix checkout' is too broad; reproducing a payment failure, identifying the responsible component and verifying order placement gives both sides something testable.

Adobe's current packaging distinguishes Commerce as a Cloud Service (SaaS) from Commerce on Cloud (PaaS). This guide's Git deployment, server configuration and patch-installation discussion concerns conventional Magento / Adobe Commerce installations, including Commerce on cloud infrastructure; do not apply it unchanged to every product described as Cloud.

Check the product name in the merchant's contract and identify the actual deployment model during discovery. For a SaaS engagement, agree the supported storefront, integration and extension boundaries for that product before proposing work. Do not assume an engineer has server access or should run the same patching procedure as on a PaaS installation.

Adobe Commerce on cloud infrastructure uses a Git-based build and deployment workflow. Support therefore needs to consider the application, environment configuration and deployment history together. A successful build does not, by itself, prove that checkout or an integration works in production.

For a Cloud issue, prepare the project and environment identifiers, failing deployment reference, relevant build or runtime logs and the last known working revision. Review differences between integration, staging and production, including service versions, configuration and extension behaviour. The environment layout depends on your Cloud plan; establish it before proposing changes.

Agree which work belongs to the application maintainer and which needs Adobe or another provider. Where an Adobe case is needed, we can help assemble the reproduction steps, timestamps, impact and supporting evidence. Adobe support access depends on the merchant's entitlement and authorised account access; independent support cannot promise Adobe's response or override platform controls.

Keep the merchant in control of account ownership and approvals. Use named, limited-access accounts and the appropriate shared-access process, rather than handing over a shared Adobe login. The official Cloud and support guides are linked below.

Check this before an incident. Adobe's support guide requires the appropriate product entitlement and organisation selection. Shared Access to a Commerce account does not automatically grant Cloud Console access; the account owner must arrange separate Cloud project access where needed. Check that the authorised maintainer can see the correct organisation and project without submitting an unnecessary support case.

Record the Adobe case reference, affected environment, merchant impact, timestamps with timezone, reproduction steps and relevant sanitised logs. Name the person who follows up and the engineer who can act on Adobe's advice. A case waiting for merchant information is not the same as a fix being deployed, and third-party extensions or payment services may need their own supplier escalation.

For planned support, begin with discovery and a baseline audit before changing production. The managed service starts with an onboarding audit; its pace depends on access, documentation and the state of the store. An emergency instead starts with triage and stabilisation, with the wider audit following once trading is protected.

Prepare the following for a secure handover. Send only the store URL and a short problem summary in the initial enquiry; arrange access separately and remove customer data and secrets from diagnostic material.

Our emergency service publishes an initial response target of two hours during UK business hours. That is a response target, not a promise to repair every fault within two hours, and it does not imply 24/7 cover. Confirm the applicable hours, availability and escalation route before relying on a support arrangement.

A useful first response should establish business impact, access needs, the immediate containment or recovery options and when the next update will arrive. A resolution estimate follows investigation: a failed deployment, a payment-provider outage and a compromised host need different work and may involve other suppliers.

Choose a one-off project when the outcome is clear: a security patch, a version upgrade or a specific defect. Agree the assumptions, testing responsibilities, acceptance criteria and what happens if investigation reveals additional work before committing to a release.

Managed support is more suitable when the store needs ongoing monitoring, patch awareness, regular reviews and a familiar technical contact. Our retainers do not include unlimited development: patch installation, upgrades and development are billed separately at agreed prices. Confirm third-party licences, hosting charges and any out-of-hours work separately too.

Existing developers do not have to be replaced. A support engagement can sit alongside an internal team or agency, provided deployment authority, code ownership and responsibility for each issue are explicit.

Agree closure before work starts. For a fix, retain a sanitised reproduction, the affected code or configuration reference, tests of the original failure and critical adjacent journeys, and production verification after release. For a change with recovery risk, identify the tested recovery point and who decides whether to roll back. Do not put customer records or credentials in the evidence log.

For ongoing maintenance, ask for a short action register rather than alerts alone: issue, business impact, owner, decision, next action and review date. Mark items waiting on approval, access or another supplier explicitly. These are recommended acceptance practices, not a new contractual deliverable or resolution-time guarantee.

Tell us your store URL, Commerce version, hosting setup, what is failing or needs changing, when it started and the business deadline. For an incident, add the number of affected stores or customer journeys, any workaround and the last deployment time. Do not include passwords, API keys, payment details or customer records.

Ask us to help establish whether the next step is emergency triage, a scoped fix or a managed-support audit. For planned work, use the call request below; for an urgent trading problem, use the direct phone option and explain the impact first.