A Magento upgrade is bought on a date, and the date is not the agency's. Adobe's lifecycle page ended regular support for 2.4.6 on 11 August 2026 and gives Adobe Commerce customers on it until 31 August 2027, then security-only fixes to 31 May 2028 under what it calls a one-time exception; Magento Open Source stores on 2.4.6 have been unpatched since August. 2.4.8 has regular support to 31 May 2028 and 2.4.9, released 12 May 2026, to 31 May 2029. Start from where the store is on that table, then from what the host can run, and only then from who should do the work.
Start from the host, not the version number
Adobe's system requirements page lists PHP 8.5, OpenSearch 3 and Valkey 9 for 2.4.9, and PHP 8.3 or 8.4 for 2.4.8. A managed host that has not shipped PHP 8.5 turns a 2.4.9 upgrade into a hosting move as well. The right first question to any agency is therefore which PHP minor its proposal assumes and whether your host offers it. An agency that names 2.4.9 before asking about the host is quoting a version, not a project.
The eight questions for the first call
- Which of your last five upgrades were Magento Open Source and which were Adobe Commerce? Adobe's Upgrade Compatibility Tool is restricted to Adobe Commerce, so an Open Source store needs the agency's own compatibility check
- Can we see a past audit deliverable with the client name removed? integer_net and Inchoo publish what theirs cover and cost; scandiweb publishes the audit as the first of five steps. Ask the others for the equivalent
- What do you run in place of the Upgrade Compatibility Tool on an Open Source store? The answer should name static analysis over composer constraints and a module-by-module review
- How do you handle a paid extension whose vendor has shipped nothing for the target release? The answer should be a verdict per extension with hours against each line
- Which PHP minor does the proposal assume, and does our host offer it? This decides 2.4.8 against 2.4.9 before any code is touched
- What does the cutover runbook look like, and what is the longest rollback you have executed? scandiweb's upgrade page states a rollback path ready on every release; Vendic's takeover page states rollback for the first weeks; nobody publishes a runbook
- What is the upgrade price with the frontend left untouched? Then price the Hyvä rebuild against it; four agencies here are Hyvä Platinum partners on hyva.io
- Who applies the next Adobe security patch after go-live, and under which contract? Vendic publishes 48 hours, Elgentos a monthly fee with patches inside it, scandiweb a patch cycle of 1 to 2 weeks priced after an audit; the others publish no cadence
What the eight agencies publish against those questions
On upgrade evidence, only scandiweb publishes a case with source and target versions, in its Classic Football Shirts (2.4.0 to 2.4.4-p2) and IONTO (2.2.10 to the latest release) write-ups. On the audit, integer_net publishes a 3,999-euro scope and Inchoo a 3,000-euro scope. On edition, scandiweb's upgrade page states both editions, Wagento's upgrade page states both, SwiftOtter's Adobe Commerce page states both, and Netresearch's Magento page states Open Source hosting on AWS. On rollback, scandiweb and Vendic publish a step, SwiftOtter's Adobe Commerce page says migration cutovers are rehearsed and documented, and the rest publish nothing. On patching and response terms, Vendic publishes the most, then scandiweb and Elgentos. On the frontend, scandiweb, Vendic, integer_net and Elgentos are Hyvä Platinum on hyva.io. The ranking page holds the detail; the point here is that no agency publishes an answer to all eight, so all eight go on the call.
Reading a quote
A quote that arrives before an audit is a guess with a signature. scandiweb's upgrade page gives $15,000 to $35,000 as a market range and says the audit sets the number; Wagento's page guarantees the quoted price but quotes after scoping; Clutch hourly bands, from $50 to $99 for scandiweb and Inchoo to $150 to $199 for SwiftOtter, are rates and not totals. A quote of a few days for a store with a real extension estate describes patch application, not a version upgrade. A quote that bundles the frontend hides the comparison that matters. Ask for the extension-by-extension verdict with hours, the frontend as its own line, and the post-go-live patching as a third line, and read the three separately.
Reference checks
Ask for one reference whose upgrade crossed as many minor releases as yours will, on your edition, with a comparable integration. The published cases on this site are the places to start, with scandiweb's IONTO write-up for an ERP connector during a multi-version jump, Wagento's Lapp Tannehill write-up for an Epicor ERP integration on Adobe Commerce, and Vendic's takeover page for a store inherited from another agency. Where an agency publishes no case, which on this site is SwiftOtter, integer_net, Inchoo, Elgentos and Netresearch for version-numbered upgrades, the reference call is the only evidence you will get, so ask for versions and dates on it.