Luma has no announced end-of-life date, so you are not on a deadline. You are on a runway. It shortens as your Magento version approaches end of support, as extensions stop shipping Luma-compatible releases, and as Core Web Vitals fall further behind competitors. Most stores have one to three years. The question is when to move, not whether.
That framing matters because the usual advice, which is that Luma is legacy and you should leave, is true and useless. It tells you nothing about sequencing against everything else on your roadmap. This is a way to work out how much runway you actually have, and what specifically shortens it.
Where Luma actually stands
Two facts are worth separating from the noise.
First, Adobe has not published an end-of-life date for Luma. It remains in the platform and is documented in Adobe’s themes documentation, alongside the Blank theme, which Adobe identifies as the actual default. Luma is described there as a sample theme demonstrating responsive design, which is a useful reminder of its origins: it was built as a reference implementation, and a large part of the Magento install base has been running a demonstration theme in production for years.
Second, Luma is in maintenance rather than development. Expect security patches and compatibility fixes, not new capability. Nothing is being invested in making it faster.
So there is no cliff. There is decay. That is a harder thing to plan against, which is why so many merchants drift.
Decay is also why the decision keeps getting deferred. A cliff creates a budget line and an owner. Gradual decline creates neither, so the frontend loses every quarterly prioritisation round to something with a date attached. The stores that handle this well are the ones that give the decision an artificial deadline, usually by tying it to an upgrade already on the roadmap.
What actually shortens your runway
Four clocks run independently, and the shortest one governs.
Your Magento version’s support date. This is the hardest constraint and the only one with published dates, in Adobe’s version lifecycle documentation. When your version leaves support you must upgrade, and an upgrade is the natural moment to change the frontend because you are already regression-testing everything. Moving frontends at any other time means paying the testing cost twice.
Extension compatibility drift. Vendors follow demand. As the market moves, more extensions ship Hyvä-compatible versions first and Luma support becomes an afterthought, then a legacy branch, then nothing. You will not notice this as an event. You will notice it as a module you cannot upgrade, then a second one, then a security patch you cannot take.
Core Web Vitals against your competitors. This is relative, not absolute. Luma’s performance is not getting worse; the bar is rising. If your competitors migrate and you do not, you lose ground on the same score you held last year.
Accumulated theme customisation. Every year on Luma adds overrides, and every override makes the eventual migration bigger. This clock runs faster the more actively you develop. A frozen Luma store has more runway than one under constant change.
A runway assessment you can actually run
Score each of these honestly.
| Signal | Comfortable runway | Shortening | Move now |
|---|---|---|---|
| Magento version support | More than 18 months left | 6 to 18 months | Out of support or under 6 months |
| PHP version | Current and supported | One version behind | On PHP 7.4 or unsupported |
| Extensions without Hyvä path | Few, all actively maintained | Several, some vendors quiet | Key modules abandoned |
| Mobile Core Web Vitals | Passing | Borderline on one metric | Failing, and competitors passing |
| Frontend change rate | Stable, few releases | Regular design work | Heavy ongoing customisation |
| Upgrade already scheduled | None planned | Planned next year | Planned in the next two quarters |
Read it this way. Anything in the right-hand column is a trigger on its own. Two or more in the middle column means you should be scoping now, not next year. All left means you have genuine runway and should spend this year fixing what you can inside Luma instead.
That last case is real and under-discussed. If you have runway, hardening the Luma store is a legitimate strategy, and we wrote up the specifics in our guide to fixing Magento Core Web Vitals without replatforming.
The scheduled-upgrade trigger
If there is one insight worth taking from this, it is that the cheapest time to leave Luma is during an upgrade you were already doing.
An upgrade forces full regression testing across your catalog, checkout, B2B flows, and integrations. A frontend migration forces the same testing. Doing them together means one QA cycle, one round of stakeholder sign-off, one deployment risk window. Doing them six months apart means two of everything.
The counter-argument is risk concentration, and it is fair: combining two large changes makes the failure surface bigger and diagnosis harder. Our honest position is that this is worth it when the upgrade is a minor version step and the extension audit came back clean, and not worth it when you are jumping several versions with a pile of unmaintained modules. In the second case, upgrade first, stabilise, then move the frontend as a separate project.
How to buy yourself more runway
If the assessment says you have time but not much, there are five things that genuinely extend it. All of them are worth doing regardless, because none is wasted when you eventually migrate.
Get to a supported Magento patch level and PHP version now. This removes the hardest clock from the board and is a prerequisite for a Hyvä migration anyway. Doing it early converts a forced decision into a chosen one.
Freeze frontend customisation. Every new Luma override is migration debt at roughly one-to-one. If you know you are moving within eighteen months, stop investing in templates you are going to throw away. Push design effort into content and merchandising instead, which carries across.
Audit your extensions and record the answer. For each frontend-touching module, note whether the vendor ships a Hyvä-compatible version, whether the module is still maintained, and whether you actually use it. That last column is the useful one. Teams routinely find a quarter of their extensions are dormant, and dropping them shrinks both the Luma risk and the eventual migration.
Fix what you can inside Luma. Script deferral, image handling, layout shift, and caching produce real Core Web Vitals movement without a replatform, and they buy relative position against competitors.
Keep the theme close to stock. The stores that migrate cheaply are the ones that resisted overriding core templates. If you are staying another year, spend it removing overrides you no longer need rather than adding more.
The pattern here is that buying runway and preparing to migrate are the same work. That is not a coincidence, and it is why an assessment is worth doing even when the conclusion is “not yet.”
Your three options in 2026, briefly
The decision is no longer binary.
| Stay on Luma | Hyvä | Edge Delivery Services | |
|---|---|---|---|
| Best when | Runway is long, budget is committed elsewhere | You want speed without re-architecting | You are in the Adobe content ecosystem |
| Effort | None now, more later | Moderate, scoped by extensions | Higher, different authoring model |
| Main risk | Compounding decay | Extension compatibility | Newer path, smaller talent pool |
Adobe’s Commerce Storefront on Edge Delivery Services is the newest of the three and brings a document-based authoring model, which is a genuine shift in how merchandising teams work rather than only a performance change. It suits organisations already invested in Adobe’s content tooling. For most mid-market Magento merchants whose problem is simply that the storefront is slow, Hyvä remains the shorter path, and we compared the frontends directly in our Hyvä vs Luma decision guide and took the wider view in it’s time to say goodbye to the Luma theme.
How Bemeir helps
Bemeir is a Brooklyn ecommerce agency and the USA’s first official Hyvä Gold Partner. We do this assessment as a paid engagement precisely because the honest answer is sometimes “stay where you are for another year,” and that is not an answer you get from someone selling a migration.
Our Hyvä development services handle the migration when the runway says move, and our Magento and Adobe Commerce development practice handles the upgrade, patching, and performance work when it says wait. We also build on Shopify and Shopify Plus, Shopware, and BigCommerce, and the extension and integration questions behind any frontend decision draw on our technology partner ecosystem.
More about the team is on the about Bemeir page, or start a conversation from the Bemeir homepage.
Frequently asked questions
Is the Magento Luma theme deprecated?
Luma is in maintenance rather than active development, and Adobe has not published an end-of-life date for it. It still ships with the platform and is documented alongside the Blank theme, which Adobe identifies as the actual default. Practically, expect security and compatibility fixes but no new capability or performance work, which means the gap between Luma and modern frontends widens over time rather than closing.
How long can I keep running Luma safely?
Most stores have somewhere between one and three years of comfortable runway, but the number is specific to you. It is governed by whichever clock runs out first: your Magento version’s support date, extension vendors dropping Luma compatibility, your Core Web Vitals relative to competitors, and how much theme customisation you keep adding. Assess all four rather than assuming a general timeline applies.
Should I migrate my frontend at the same time as a Magento upgrade?
Usually yes, because both force a full regression test and doing them together means one QA cycle instead of two. The exception is when you are jumping several Magento versions and carrying unmaintained extensions. In that case the combined failure surface gets hard to diagnose, so upgrade first, stabilise, then treat the frontend as a separate project.
What are my alternatives to Luma in 2026?
Three realistic paths. Hyvä replaces the frontend with a lightweight Tailwind and Alpine stack and is the shortest route for merchants whose core problem is speed. Adobe’s Commerce Storefront on Edge Delivery Services is a newer option with a document-based authoring model, suited to organisations already using Adobe’s content tooling. Staying on Luma and hardening it is legitimate when your runway assessment says you have time.
Can I fix Luma performance instead of migrating?
Up to a point, and it is worth doing when your runway is long. Deferring and trimming third-party scripts, fixing layout shift, optimising images, and tightening caching all produce real gains without a replatform. What you cannot fix is the underlying JavaScript weight Luma carries by design, so there is a ceiling. If you are failing Core Web Vitals badly on mobile, patching will narrow the gap rather than close it.
