All guides
Support budgeting8 min read

How much does Magento support cost in the UK?

Plan a Magento support budget using published service prices, clear scope boundaries and a practical checklist for comparing retainers, fixes and upgrades.

Last reviewed:

The short answer: price the work, not just the monthly fee

Magento support does not have one useful universal price. A monitoring subscription, an engineer fixing checkout and a tested version upgrade buy different outcomes. Separate routine oversight, implementation work and incident response, then compare what each quote covers.

At Magento Patches, published starting points currently include managed plans at £99, £199 and £299 per month, a single patch installation at £99 and emergency support at £80 per hour. These are our own advertised prices, checked on 26 October 2026, not a UK market average or a quote for every store. The pricing page and agreed written scope govern the engagement.

Written and reviewed by Magento Patches, this guide helps merchants prepare a support budget and a comparable brief. It does not estimate Adobe licence fees or promise that a particular plan can resolve every incident. Confirm availability, tax treatment and exclusions before approving work.

1. Separate four budget lines

Keep recurring service charges separate from change projects. Otherwise a low monthly number can appear to include work that will still need approval and funding. Ask the provider to identify the charging model for each item rather than treating everything as maintenance.

  • Oversight: monitoring, advisory review, reports and agreed operational checks. Establish who reviews alerts and what action the subscription includes.
  • Implementation: installing a patch, repairing a defect, updating an extension or changing an integration. Define the deliverable and test evidence.
  • Planned upgrades: compatibility investigation, dependency changes, staging, regression testing and cutover. Budget for a scoped release rather than assuming it fits inside a small retainer.
  • External costs: hosting, Adobe subscriptions where applicable, extension renewals, third-party tools and payment-provider charges. Identify the supplier and renewal owner separately.

2. Use published prices as starting points, not a market benchmark

Our pricing page lists Bronze managed support at £99 per month, Silver at £199 and Gold at £299. The descriptions distinguish monitoring and patch alerts, monthly checks and priority support. Patch installation and upgrades are billed separately unless agreed; a monthly payment is not an allowance for unlimited engineering.

For defined changes, the same page lists a single patch installation at £99, a same-day urgent patch at £199 and an M2 patch-level update at £299. Version-upgrade starting points are £499 for a clean M2 minor upgrade, £999 for a typical store and £1,999 for legacy or major M2 work. An Adobe Commerce major upgrade requires assessment. A patch-level update and a larger upgrade are not interchangeable scopes.

Emergency support is listed at £80 per hour. An hourly rate does not establish the final incident bill: diagnosis, supplier coordination and remediation can require different amounts of work. Ask about any minimum charge, approval limit, update cadence and out-of-hours availability rather than guessing them from the rate.

Do not add every line together automatically. Ask which service matches the store and whether any elements overlap. Request a written quote stating whether VAT is included or excluded, what is payable to other suppliers and when a changed scope needs approval. This guide does not assume a VAT policy that the pricing page does not state.

3. Understand the factors that change a quote

Give each prospective maintainer the same technical outline. A store with a reproducible build, known extensions and working staging is easier to scope than an undocumented installation whose last deployment cannot be reproduced. Ask which uncertainties need investigation before a fixed delivery price is safe.

  • Edition and deployment: identify Magento Open Source, self-hosted Adobe Commerce, Commerce on cloud infrastructure or another Adobe product. Cloud alone is not a complete specification.
  • Version and change history: provide the installed release, patch record, last successful deployment and any interrupted upgrades.
  • Customisation: list custom modules, theme changes, paid extensions and who can supply compatible packages or renew licences.
  • Trading dependencies: explain payment methods, fulfilment, ERP, stock, tax, shipping and multi-store requirements. These determine what needs testing.
  • Release readiness: identify staging, backup coverage, restore-test evidence, deployment ownership and a merchant who can approve acceptance.
  • Timing and impact: describe a planned maintenance window or an active outage honestly. Urgency and unresolved supplier dependencies affect what can be committed to.

4. Keep Adobe licensing and independent support separate

Adobe's current product pricing page distinguishes Adobe Commerce as a Cloud Service (SaaS) from Adobe Commerce on Cloud (PaaS) and directs buyers to request customised pricing. Obtain the relevant Adobe proposal rather than copying an unattributed annual licence estimate into a support budget.

The Git deployment and server-side maintenance process for Commerce on cloud infrastructure is not a universal description of every Adobe cloud product. Establish the product and deployment model first, then ask which application, integration and platform tasks remain in the support scope. Do not budget a conventional Magento server patching project for a SaaS product without checking applicability.

Adobe product support and an independent maintainer are separate relationships. Adobe support cases depend on the merchant's entitlement and appropriate authorised access. A maintainer's fee does not create an Adobe entitlement or guarantee Adobe's response. Ask who prepares a case, who follows it up and which supplier owns the next action.

5. Compare response cover and delivery obligations

A response target measures acknowledgement or the start of triage; it is not a guaranteed repair time. Priority booking is different from a reserved engineer or continuous out-of-hours coverage. Put coverage hours, channels, escalation and update expectations in the agreement before using them in an operational plan.

Ask what happens after an alert: does the provider only notify you, investigate within a defined allowance, or implement a separately approved fix? Establish who can authorise containment or rollback if the normal decision-maker is unavailable. Monitoring with no named action owner leaves a gap even if every alert arrives.

For project work, compare acceptance evidence rather than just the day rate. Identify staging tests, critical payment and order journeys, production verification, rollback criteria and the support period for regressions. Ask how unrelated defects and third-party outages are distinguished from a regression caused by the change.

6. Build a twelve-month budget without hiding exclusions

Use a worksheet with separate recurring charges, confirmed projects, supplier renewals and an uncommitted incident reserve. Do not label a reserve as a predicted bill or assume that paying for monitoring removes the need for it. Review the worksheet when the platform, supplier or trading calendar changes.

For arithmetic only, twelve months at the currently listed £199 monthly price equals £2,388. Adding one separately agreed £99 patch installation would make those two items £2,487. This is not a recommended annual budget or a customer example: it excludes every other project, supplier cost, incident and any applicable tax. Real patch frequency and eligibility must be assessed for the store.

Do not turn that illustration into a flat annual all-in price. Replace its assumptions with the actual plan, confirmed scope and renewal dates. If the store has overdue maintenance or unknown custom code, ask for the discovery output and a prioritised backlog before approving a longer-term implementation budget.

7. Send a brief that makes quotes comparable

Send the store URL, edition, installed version if known, hosting model, main integrations and business priority. Include the next important trading date and describe existing support arrangements. Share credentials and sensitive diagnostic material only through an agreed secure process, not in the initial enquiry.

Ask each provider to complete the same decision record below. Mark unknowns explicitly. A quote that names investigation, approval gates and exclusions is more useful than a precise-looking total built on undisclosed assumptions.

Store / edition / deployment model:
Current version and outstanding maintenance:
Business outcome and deadline:
Recurring service / included actions:
Separately charged implementation:
Discovery needed before delivery quote:
Testing and acceptance owner:
Response hours / escalation / update cadence:
Supplier renewals and account owner:
Tax treatment / minimum charges / approval cap:
Exclusions and scope-change process:
Exit, handover and access-revocation requirements:

What to do next

If you know the change required, request a scoped quote with acceptance criteria. If you need ongoing oversight, compare managed inclusions and separately charged work. If trading is already disrupted, explain the incident and ask about triage availability before treating it as a routine maintenance enquiry.

The aim is an arrangement you can explain: what is covered, what costs extra, who acts when something breaks and what evidence closes the work. A small fee with clear boundaries can be useful; an apparently inclusive fee with unknown responsibilities is difficult to budget or rely on.

Official references

Next step

Need a support scope you can budget for?

Tell us your store URL, platform, current concern and deadline. Discuss the right scope and any assessment needed before a quote; do not send passwords or customer records.