OpenMage LTS: the community continuation of Magento 1

An unofficial fork with a compatibility promise

OpenMage describes itself as an unofficial community-driven project whose goal is to be a dependable alternative to the Magento CE official releases. The approach is stated in one line: it integrates improvements directly from the community while maintaining a high level of backwards compatibility to the official releases.

That is a different proposition from forking to redesign. Every change has to keep the shape of Magento 1 intact, which is what makes migration feasible. A store with years of custom extensions, a custom theme and a database full of real orders can be pointed at OpenMage without rewriting the parts nobody wants to touch.

The repository description makes the migration pitch explicitly, offering a way to migrate easily from Magento Community Edition in minutes, and lists the output as security vulnerability patches, bug fixes and performance improvements. The project says as much in the README: pull requests with bug fixes and security patches from the community are encouraged and welcome.

What you are adopting is therefore a maintenance and security channel, not a new application. If the reason you left Magento 1 was the platform itself, OpenMage does not address that, and the README does not claim it does.

What the repository tree reveals about the tooling

The top level entries show a mature PHP project with a full static analysis and quality toolchain. Beyond the usual application directories such as app/, lib/, js/, skin/, media/, pub/ and shell/, the tree contains .php-cs-fixer.dist.php, .phpcs.dist.xml, .phpmd.dist.xml, .phpmd.dist.baseline.xml, .phpstan.dist.neon with a .phpstan.dist.baselines/ directory, .phpunit.dist.xml, .rector.php and .cypress.config.js with a cypress/ directory.

That set of tools defines what a contribution is expected to survive. PHPStan and PHP Mess Detector run statically over the code, PHP_CodeSniffer and PHP-CS-Fixer enforce style, PHPUnit covers PHP, and Cypress covers the browser layer. Rector is present for automated refactoring, which is how a codebase this old gets modernised without a manual sweep.

The baseline files are the interesting part. A baseline is a recorded list of accepted violations, which is how a legacy codebase introduces strict rules without a rewrite: the rule is switched on, the known problems are frozen in a file, and new code is held to the standard. That is a visible commitment to keeping debt from growing.

The dependency layer is Composer, with composer.json and composer.lock committed, and patches.json plus patches.lock.json alongside a .vendor-patches/ directory, which is the mechanism used to adjust vendor packages in place. vendor-bin/ suggests tooling dependencies are isolated from the runtime dependency set.

Composer, Makefile targets and the developer entry points

Because composer.json and composer.lock are part of the tree, a checkout is installed the usual way, with the lock file pinning the exact dependency versions. The Makefile provides a small set of developer entry points for serving reports and documentation:

mkdocs-serve
phpunit-serve
phpmd-serve

Each target is a convenience wrapper rather than the real command. The phpunit-serve target opens build/phpunit/coverage/index.html and, if it is missing, prints a message telling you to run composer run phpunit:coverage-local before exiting. The phpmd-serve target does the same with build/phpmd/report.html and points at composer run phpmd:test. The mkdocs-serve target checks whether mkdocs is on the path and, if not, points at the documentation site for the mkdocs setup.

That pattern is worth reading carefully as a team convention: the repository expects coverage and mess reports to be generated locally before they can be viewed, and it expects the generation to happen through Composer scripts rather than through a Makefile recipe.

The web entry points of the application itself are the standard Magento set, with index.php for the front end, api.php for the SOAP and XML-RPC interface, cron.php and cron.sh for scheduled tasks, and install.php for the installer. There is also a get.php, a .htaccess file, and error handling under errors/.

Documentation built from the same tree

The docs/ and docs_includes/ directories sit next to a mkdocs.yml, and the mkdocs-serve Makefile target serves them locally. The README points readers at docs.openmage.org as the documentation site.

Keeping the documentation in the repository rather than only on a website is a deliberate structural choice with a practical consequence: the version of the docs you read matches the version of the code you have checked out, and a change to behaviour can be reviewed in the same pull request as the change itself. For a fork whose entire value proposition is predictable upgrade behaviour, that matters more than it would for a new project.

The docs_includes/ directory alongside docs/ suggests shared fragments included in multiple pages, which is how a large manual avoids duplicating a setup procedure across a dozen guides.

What the README does not contain is any detail on the upgrade path itself. There is no changelog summary in the text available here, no list of breaking changes, and no statement about the migration procedure beyond the general claim that migration happens in minutes. The repository has a CHANGELOG-style release history in its tags, but the README does not point at a per-release upgrade note. For a platform upgrade, that absence is the practical gap an evaluator has to close by reading the release notes on the tags.

OSL 3.0 alongside AFL 3.0, and what a store owner inherits

The licence field on the repository says OSL-3.0, and the README lists two licences, OSL v3.0 and AFL v3.0, linking both to the Open Software License and the Academic Free License. The tree carries the corresponding files: LICENSE.txt, LICENSE_AFL.txt, COPYING.txt and also LICENSE_TINYMCE.txt for the bundled TinyMCE editor.

The dual licence is the standard Magento arrangement rather than a complication invented here. Magento 1 shipped under a pair of similar licences precisely so that the code could be used commercially by stores while remaining open for the wider ecosystem, and OpenMage inherits that arrangement with the files it inherited.

For a store owner the practical point is that OSL is not permissive like MIT. It is a copyleft licence with an attribution clause, and it carries the requirement that modified versions remain available under the same terms. For an internal store, this is not usually the binding constraint. For an agency that wants to keep its own changes to the platform confidential, it can be, which is why the licence needs reading by whoever owns the code rather than assumed from the badge.

The third licence file is the one that surprises people: TinyMCE ships under its own terms, so the bundled editor is not covered by the OpenMage licence at all.

The 20.x line and the gap between releases

The recent releases are v20.18.0 on 2026-05-04, v20.17.0 on 2026-04-18 and v20.16.0 on 2025-11-01. The repository is not archived and the last push was on 2026-10-19.

Those two facts sit in mild tension, and an adopter should read them carefully. Commits are landing on main as of October 2026, but the newest tagged release is from May 2026, five months earlier, and the gap between v20.16.0 and v20.17.0 was six months. The project is clearly alive, and the release tagging is what lags.

There is a plausible explanation in the workflow itself. With a security-fix and compatibility-first policy, releases are cut when a batch of fixes is ready rather than on a fixed calendar, and the version increments with each patch set. That is a reasonable approach for a maintenance branch, but it means you cannot infer the age of a release from its number, and you should check the tag date rather than assume the newest version number is the newest build.

The version numbering also tells you something about the platform. A 20.x line is a continuation number, not a Magento 2 style reset, which is consistent with the compatibility promise: the numbering continues from the Magento 1 lineage it inherits.

For planning, the upgrade cost of OpenMage is the diff against your current Magento 1 installation plus your own extensions, and that diff is kept small precisely because the project refuses to break compatibility. The realistic risk is not the platform version but an extension you depend on that has not been made compatible.

Editorial conclusion

OpenMage LTS suits a store owner or agency that already runs Magento 1 and needs a maintained, patched fork to migrate onto without a replatform, particularly where the existing catalogue, extensions and templates have to keep working. It does not suit a new build, because it inherits Magento 1's architecture rather than modernising it, and it does not suit anyone unwilling to read a compatibility note before upgrading. Before adopting, take a full backup of the database and app directory, check your installed extensions against the OpenMage 20.x release notes, and confirm the PHP version your host supports before moving a live store onto a fork.

Frequently asked questions

Official sources

1. License: OSL-3.0
2. OpenMage/magento-lts on GitHub
3. Project website
4. README
5. Releases