Short answer: Magento Open Source 2.4.9 shipped on 12 May 2026. Regular support runs to 31 May 2029. This is not a Composer one-liner. 2.4.9 needs PHP 8.5, OpenSearch 3, Composer 2.10, and a new database/cache layer. A realistic Estonian store project starts with an audit, happens on staging, and is not done until payments, shipping, ERP and checkout have been regression-tested.
Why Magento 2.4.9 matters to a store owner
The version number does not grow sales. The value is a supported stack whose security patches and dependencies you can still manage. The longer a store sits on an old release, the wider the gap between Magento core, PHP, search, database and third-party modules.
The business question is not “is the new version interesting?” It is: is today’s technical debt still under control, and can the next three years of upgrades be planned?
Moving to 2.4.9 can still make sense when 2.4.8 works today. A longer support window reduces the pressure to jump again too soon. “Newest” is not the same as “ship it this week.” Critical extension readiness and a real test result decide more than the version number.
What changed versus 2.4.8
2.4.9 is not just the next security patch. Adobe lists 580 fixed core issues and moves the supported stack to PHP 8.5, Valkey 9 and newer service versions. Not all 580 fixes matter to every store. These are the ones merchants should actually notice.
Checkout and promotions
Fixes include cart-rule application, multi-currency price handling, guest address validation, and checkout JavaScript mixins that failed to load on the first try.
Customer account and cart
Open Source gets a clearCart GraphQL mutation. Admins can control how guest and logged-in carts merge. Historical orders still show product data after an item later goes out of stock.
Catalog and integrations
The REST API can keep or restore store-view product-gallery inheritance. That matters in a multilingual store where PIM/ERP updates products and media through the API.
Payments and security
Braintree adds Google Pay card vaulting and card-update improvements. CAPTCHA coverage expands on REST/GraphQL account creation. None of that proves an Estonian payment module supports 2.4.9.
Recommendation by your current Magento version
2.4.8-p5
Holding for a while can be reasonable if the store is patched, PHP 8.5 or a critical module is not ready, and you have no business need for 2.4.9. Regular support for 2.4.8 runs to 31 May 2028 — write a 2.4.9 readiness plan anyway.
2.4.7-p10
Start the readiness audit now. Regular support ends 31 May 2027. Pick the upgrade window before the project is squeezed between end-of-support and peak season.
2.4.6
High priority on Open Source. Regular support ended 11 August 2026. Do not copy Adobe Commerce extended-support wording onto Open Source.
2.4.5 or older
Do not treat this as a small version bump. Plan platform, PHP, search, database and extension migration together with a restore test and possible replacement modules.
Magento 2.4.9 requirements: Cloud and on-premises
Adobe publishes different combinations for Cloud and self-hosted Magento. On Cloud, MariaDB 11.8 is a supported option. Adobe’s on-premises 2.4.9 table lists MariaDB 12.3 or MySQL 8.4, and adds Varnish 8.
Adobe Commerce on Cloud
PHP 8.5 · Composer 2.10 · OpenSearch 3
MariaDB 12.3 (recommended) or 11.8; RabbitMQ 4.3 or ActiveMQ Artemis 2; Valkey 9; nginx 1.30; New Relic 12.5.0+.
Commerce / Magento on-premises
PHP 8.5 · Composer 2.10 · OpenSearch 3
MariaDB 12.3 or MySQL 8.4; RabbitMQ 4.3 or ActiveMQ Artemis 2; Valkey 9; Varnish 8; nginx 1.30. AWS services have separate rows.
On-premises example: an upgrade is a full-stack project, not a single Magento package swap.
Should your store move to 2.4.9 now?
Start the project now if…
- your Magento or PHP version is at end of support, or close;
- patches are irregular and nobody can prove the current patch level;
- a larger checkout, B2B or integration build is planned in the next 6–12 months;
- hosting is changing anyway and the stack will be rebuilt;
- there is no staging, so every production change is already a gamble.
Do not rush production if…
- a payment, shipping or ERP extension has not confirmed 2.4.9 support;
- you have no restorable backup or a realistic rollback plan;
- peak season is about to start;
- nobody has mapped custom modules and who owns each integration.
Move to 2.4.9 now, or wait?
On a 30-minute readiness call we look at your current version, hosting and the three most critical integrations. You leave with a first direction: run a readiness audit now, patch the current version first, or wait for a specific dependency. That is not a promise to write a full upgrade plan in 30 minutes.
Ask for a 30-minute readiness callEstonian integrations: what 2.4.9 actually requires you to check
A Magento 2.4.9 upgrade in Estonia is work on local data flows: payments, shipping, ERP and hosting. Magentopood’s public services page covers day-to-day work with NOOM/ERPLY, supplier feeds, couriers and payments. The Ordi case describes ERP and payment integrations. That experience does not automatically mean every named module supports Magento 2.4.9 and PHP 8.5.
NOOM / ERPLY and ERP feeds
Magentopood services and the Ordi/bonprix cases confirm ERP integration work. The exact customer module, version and PHP 8.5 support still have to be checked in the audit.
Omniva
The public Magento 2 module repository released 1.3.7 on 26 March 2026. A public release does not confirm 2.4.9 or PHP 8.5 support — you still need a code and staging test.
DPD and SmartPost/Itella
Local delivery is business-critical, and there is no reliable public 2.4.9/PHP 8.5 support matrix. Confirm the exact module version before the upgrade. Test parcel lockers, rates, labels, manifest and status updates.
Maksekeskus, Montonio and EveryPay
Do not assume support from the brand name. Ask for the exact package/version, PHP constraint and vendor confirmation. Test payment start, callback/webhook, cancel, refund and duplicate notifications.
Directo and Merit
The link is often a customer-specific API or middleware, not one universal module. Check orders, stock, prices, customers, invoices, retry logic, and which system owns each field.
Estonian hosting
Do not generalise Zone, Veebimajutus or any other host. Get written confirmation for PHP 8.5, OpenSearch 3, MariaDB/MySQL, Valkey, Varnish, RabbitMQ, staging and restore.
A safe Magento 2.4.9 upgrade process
Map Magento patch, PHP, database, search, extensions, theme, integrations, crons and custom code. The output is a written risk list, not a verbal “we can do it.”
A file and database backup is useful only if restore has been tested. Name the rollback decision-maker and the maximum allowed outage.
Build an environment as close to production as you can. Upgrade infrastructure layers and Magento, then resolve Composer, compile, schema changes and indexes.
Replace unsupported packages, fix custom code, and write down temporary compromises. Do not leave a sea of warnings “for later.”
Cover the mobile checkout path, account, coupons, payments, shipping methods, invoices, email, stock, ERP, analytics and returns. A technical homepage 200 OK is not a working store.
Freeze changes, sync data, do a controlled deploy, flush/warm caches, and watch logs, queues, payments and orders at least through the next business day.
You do not buy speed by skipping tests. You buy it by finding risk early.
Five risks that blow an upgrade budget
| Risk | Early signal | How to cut it |
|---|---|---|
| Unsupported extension | Vendor will not name a supported Magento/PHP version. | Decide on a replacement or fork before the main estimate. |
| Undocumented custom work | Edits live in core or vendor files. | Code diff and an owner named in the audit. |
| Silent integration failure | The order is created, but ERP never sees it or stock never returns. | Test scenarios with ERP logs and a named owner. |
| Wrong staging | Test stack differs in PHP, database or config. | Production-comparable infrastructure and an anonymised data copy. |
| Rollback exists only on paper | Restore time has never been measured. | A restore rehearsal, a decision point and a controlled maintenance window. |
How long does it take, and does the store go down?
Calendar time depends on the starting version, custom work, business-side testing and vendor replies. These are planning ranges, not a deadline promise. The real schedule comes after the readiness audit.
| Level | Typical calendar | Assumption |
|---|---|---|
| Readiness audit | 2–5 working days | Access to code, package list and infrastructure facts. |
| Simpler upgrade | 2–4 weeks | Recent starting version, little custom work, ready extensions. |
| Typical store | 4–8 weeks | Custom theme and at least one important integration. |
| Complex or old store | 8–16+ weeks | Large version jump, B2B, several integrations or replacement modules. |
The public maintenance window is set only after a staging deploy rehearsal. Minutes of downtime can be a goal. Zero downtime is not a promise without proof of architecture, data volume and sync logic.
Magento 2.4.9 upgrade planning prices
The figures below are first planning ranges, not a quote or a package price list. The real price depends on starting version, custom code, integrations, infrastructure and third-party modules. VAT, licences and vendor work can add to the total.
| Level | Planning range | What moves the price |
|---|---|---|
| Readiness audit | €490–1,200 | Versions, packages, custom work, infrastructure and integration count. |
| Simpler upgrade | €2,500–5,000 | Recent starting version, little custom work, ready extensions. |
| Typical store | €5,000–10,000 | Custom theme, several extensions and at least one important integration. |
| Complex or old store | €10,000–25,000+ | Large version jump, B2B, hosting change, several integrations or replacement modules. |
Why the version number alone cannot set the price
Two 2.4.7 stores can be nothing alike. One has a standard theme and four well-kept extensions. The other has seven years of custom work, 40 modules, patches inside vendor, and an ERP with no test environment. The starting version gives direction. Workload is the real state of the dependencies.
Magentopood upgrade experience
The Magentopood results page describes the Ordi Magento version upgrade with ERP and payment integrations; the Webshop Interior Magento 2 upgrade with supplier feeds and checkout work; Raamatukoi’s large-catalog Magento/server upgrades; and bonprix’s large multilingual catalog ERP feeds.
Those projects cover version upgrades, integrations, checkout, large catalogs and server work. 2.4.9 readiness is still judged store by store. See the public project examples.
Owner checklist before you ask for a quote
- Current Magento full version and patch level are known.
- PHP, database, search and cache versions are documented.
- Every third-party module name and licence is on a list.
- Custom modules and integrations have an owner.
- Staging is comparable to production.
- Backup restore has actually been rehearsed.
- Critical test cases cover mobile, payment, shipping, ERP and email.
- Go-live window, owners and rollback limit are agreed.
- At least one business day of active monitoring after go-live is booked.
Frequently asked questions
Do we have to jump straight to Magento 2.4.9?
Not always. The right target depends on the current support window, critical extension readiness and the calendar. An audit can recommend a security patch now and a 2.4.9 project in a later controlled window.
Will the upgrade delete products or orders?
A correctly run upgrade must not delete business data. The risk is a bad schema change, a bad sync, or a deploy with no restore plan. That is why backup and a restore rehearsal are mandatory.
Does the theme have to be rebuilt?
Not always. Theme architecture, PHP/JavaScript compatibility and the extension set decide. Luma, Breeze, Hyvä and heavily custom themes have different test volume.
Does Magento 2.4.9 make the store faster by itself?
No. A new version gives a supported technical base. Speed still depends on theme, modules, cache, images, search, database and hosting. Measure the same pages and business flows before and after.
How long is the store down?
That can be said after a deploy rehearsal and a data-volume check. In a well-prepared project the public window is usually short. Do not promise zero downtime without architectural proof.
Are Magento Open Source 2.4.9 and Adobe Commerce 2.4.9 the same requirements?
The core stack is largely shared. Adobe Commerce extra modules, cloud infrastructure and B2B features change the test volume. The plan has to start from your exact edition.
Related guides
- Magento development, upgrades and maintenance
- Magentopood public Magento projects and results
- The real cost of running Magento 2
- How to choose Magento hosting in 2026
- Magento security checklist 2026
Sources and date
Technical sources as of 5 September 2026. Recheck official requirements before a project starts.
- Adobe Commerce released versions — release and support dates.
- Adobe Commerce system requirements — supported 2.4.9 software combinations.
- Magento Open Source 2.4.9 release notes — fixes and technical changes.
- Magentopood: projects and results — project examples.
- Magentopood: services — integrations and how the work is run.
- Omniva Magento 2 module v1.3.7 — public release; does not confirm 2.4.9/PHP 8.5 support.
Is 2.4.9 the right next step for your store?
Send the store URL, current Magento version and the main concern before the call. The 30-minute readiness call ends with a first recommendation: audit now, patch the current version, or a controlled hold. A full technical plan comes after the audit.
Ask for a 30-minute readiness call
