OpenMage LTS: Magento 1 on PHP 8, Installed with Composer

If you run Magento 1, you have been told for six years that you have two options: migrate to Magento 2, or accept that you are running unpatched software on a PHP version that stopped receiving security fixes some time ago.

There is a third option, it is not a workaround, and a surprising number of merchants have never had it explained to them properly.

OpenMage LTS is a community-maintained fork of Magento 1 Open Source. It runs on current PHP, installs through Composer, and has continued to receive security backports every year since Adobe walked away. At the time of writing the project has shipped 94 releases, the latest in May 2026, and had commits landing within the last day.

That does not make it the right answer for everyone. It does make "migrate or rot" a false choice.

What it actually is

OpenMage LTS is the Magento 1 Open Source codebase, forked and maintained by the community under the same OSL-3.0 license, distributed as a Composer package:

composer require openmage/magento-lts

The important properties, all of which are the opposite of stock Magento 1.9:

The PHP line is the one that matters most, and it is worth being precise about why. The problem with stock Magento 1 was never only that Magento stopped patching it — it was that it pinned you to a PHP branch that also stopped being patched. You ended up with two layers of unsupported software stacked on each other. OpenMage running on PHP 8.4 collapses that to one, and the remaining layer is actively maintained.

The Composer change is less dramatic but changes the day-to-day. Stock Magento 1 patching meant downloading .patch files and applying them by hand, which is exactly the workflow that causes patches to get skipped. A Composer-managed install makes updating a dependency bump, and that difference is most of why stores fall behind.

What it does not fix

This is where honest advice separates from enthusiasm, and it is the part usually left out.

Your extension vendors are still gone. OpenMage maintains the core. It does not maintain the commercial extension you bought in 2016 from a company that no longer exists. Extensions written for Magento 1.9 generally work, but anything doing something clever with PHP internals may need fixing for PHP 8, and there is nobody to call. In practice most stores find a handful of modules need attention — occasionally one needs replacing outright.

No new commerce features are coming. This is a preservation project, not a product roadmap. The admin will not modernize, the frontend will not get faster on its own, and the headless and composable capabilities merchants ask about in 2026 are not arriving. If your commercial requirements are still growing, you are choosing a platform that has stopped.

There is no vendor and no SLA. The maintainers are volunteers doing genuinely good work with no obligation to you. The project is healthy today — active commits, real release cadence, hundreds of contributors' worth of forks — but "healthy today" is a different assurance from a contract. That is a legitimate risk to weigh, not a reason to dismiss it.

Hosting and infrastructure are still your problem. Nothing about the fork changes the fact that you are running a decade-old application architecture, with the performance characteristics that implies.

The compliance question, honestly

The PCI DSS argument is the one that usually forces the decision, and it deserves more care than it typically gets.

The case against stock Magento 1 is airtight: PCI DSS requires critical security patches to be applied within a defined window, and when a platform receives no patches at all, that requirement is impossible to satisfy in principle. There is no argument to make.

OpenMage genuinely changes that. Patches exist, they ship, and you can demonstrate a process for applying them. The impossibility goes away.

What it does not do is settle the question for you. Whether a QSA accepts a community-maintained fork as meeting the intent of the requirement is a judgement call, and it is one to have before your assessment rather than during it. Some assessors are entirely comfortable with it. Some will want to see your patch process documented in a way you would not otherwise have bothered with. Go in having asked.

Moving to it is not a replatform

Here is the part that changes the economics, and the reason this option deserves consideration rather than a footnote.

Because OpenMage is a fork of the code you are already running, the things that make a Magento 1 to Magento 2 migration expensive largely do not apply. The database schema is the one you have. The theme structure is the one you have. The module architecture, the templating, the layout XML, the admin — all the same. There is no data migration, because there is no new database to migrate into.

What you actually do:

1. Get to the final Magento 1.9 patch level first, so you start from a known state rather than an arbitrary one.
2. Move the codebase to Composer-managed OpenMage, which is the structural change and the one to rehearse on staging.
3. Step PHP up deliberately — this is where the real work surfaces, in extensions and custom code written against PHP 7 idioms.
4. Audit every third-party module for PHP 8 compatibility. Assume this is the largest line item, exactly as it would be in any upgrade.
5. Regression test checkout hardest, then catalog and admin, on production-like data.

Scope it as an upgrade with a meaningful compatibility pass. Compared with a Magento 2 rebuild it is a fraction of the cost, and for a store whose functionality is genuinely settled that ratio is the entire argument.

Who should actually do this

Good fit: a profitable, stable store with a settled feature set, a manageable extension list, and no appetite for a six-figure replatform this year. Also anyone who is planning a Magento 2 move but needs two or three years of supported operation to plan and fund it properly — this is a far better holding position than staying on 1.9 and hoping.

Poor fit: a business whose commercial requirements are still expanding, anyone who needs modern integrations or headless delivery, and any team without the engineering capacity to own an extension audit without a vendor to escalate to. If you are going to end up on Magento 2 within eighteen months anyway, the double migration is hard to justify.

The trap to avoid is treating it as a decision you never have to revisit. The failure mode is not technical — it is moving to OpenMage, feeling relieved, and finding yourself in 2032 having had the same conversation twice.

What we'd do

If you are on stock Magento 1.9 today, moving to OpenMage LTS is almost certainly better than what you are doing now, whatever you eventually decide about Magento 2. You gain a supported PHP branch, a real patch process, and Composer-managed dependencies, for meaningfully less than a replatform.

Treat it as a deliberate two-to-three-year position rather than a permanent answer. Write down what would trigger the Magento 2 move — a feature you cannot build, a compliance conversation that goes badly, an extension that finally breaks — so the decision has a tripwire rather than waiting for another emergency.

And if your requirements have genuinely stopped growing and the store simply needs to keep trading reliably, that is a legitimate place to land. Not every business needs a replatform; some just need the thing they have to be supportable. Our fit test for Magento is the honest version of that conversation.

Emyrix works on Magento at every version, including stores that are staying where they are. If you're weighing OpenMage against a Magento 2 migration and want the numbers for both rather than a recommendation dressed up as one, get in touch — or see how we handle ongoing Magento support.

OpenMage LTS release, license, and PHP compatibility details are drawn from the project's Packagist and GitHub metadata as of August 2026. Verify current requirements against the project directly before planning against them.