Start with the work you actually need.
“Magento support” can mean fixing incidents, applying patches, improving a storefront or supplying development capacity. Write down the work you expect before comparing suppliers. Include the customer journeys affected, business deadlines and who already owns hosting and integrations.
If checkout is failing, distinguish immediate incident response from a longer-term improvement backlog. If releases are difficult, the problem may be delivery process rather than the number of development hours available. A useful proposal should address the specific constraint.
Find out who will understand and change the code.
Ask who investigates problems, who scopes changes and who completes implementation. Understand how context reaches the developer and who is accountable when the work crosses hosting, an extension and an external service.
- Will you speak directly to the person doing the work?
- How are findings, decisions and handovers documented?
- Who reviews changes before release?
- What happens if the named developer is unavailable?
Ask for relevant project scope and an explanation of the supplier’s contribution. A client logo establishes a relationship; it does not establish which work the supplier completed or how a claimed uplift was measured.
Separate maintenance, development and emergency coverage.
Agree supported hours, how incidents are raised and the response expectation for each priority. A response time is different from a resolution time. Some faults depend on a hosting provider or payment service; the agreement should explain coordination and escalation.
Clarify whether the fee includes security patch planning, extension updates, compatibility testing, monitoring and development. Also ask what consumes the allowance, how additional work is approved and whether unused time carries forward. Do not assume a maintenance arrangement includes 24/7 support.
Look at how a change reaches production.
A dependable supplier should be able to explain the path from an agreed ticket to tested code and a controlled release. Confirm access to source control, the availability of a suitable staging environment, and how a failed release would be reversed.
Test the paths affected by the change as well as checkout and the business-critical integrations. Agree who confirms the commercial requirement has been met and who can approve deployment. The depth of testing should reflect the risk, rather than relying on a single homepage check.
Compare proposals against the same boundaries.
Give each supplier the same platform summary and backlog. Ask them to state assumptions, exclusions, required access, dependencies and the first useful deliverable. This makes it easier to compare responsibility and value instead of simply hourly rates.
A technical review can be a sensible first engagement when the platform is inherited or the cause of a problem is uncertain. Agree its scope, fee and output before commissioning it. The findings should help you decide what to do next, even if implementation is carried out by another team.
Bring these details to the first conversation.
- Your store URL, Magento version and hosting provider.
- The most important issue and its effect on customers or operations.
- Known custom modules, extensions and integrations.
- The current support arrangement and any handover deadline.
- Upcoming trading dates or changes that cannot be delayed.
Share the overview first. Access credentials should be transferred through an agreed secure process, not pasted into an enquiry form.
For platform-specific maintenance practices, refer to Adobe Commerce maintenance guidance. For a supplier change, use the Magento agency handover checklist.