A Path Forward from OpenMage

Migration

OpenMage kept Magento 1 alive. Maho keeps it relevant.

If you're reading this, you're probably on Magento 1 (still) or OpenMage, and you're weighing what to do next. This is for you. The short answer: Maho is the natural continuation of the line you're already on. The long answer is below — written honestly, with an eye on where each decision hurts.

A quick timeline, because context matters

  1. Magento 1 (2008–2020) — the workhorse of mid-market ecommerce for more than a decade. Huge ecosystem, huge flaws, but it let merchants own their code and their data in a way no SaaS ever will.
  2. Adobe ends support (June 2020) — no more security patches from Adobe, no more official releases. Tens of thousands of live stores left without a maintainer.
  3. OpenMage (2020–present) — community fork. Mage-OS became OpenMage LTS. Small volunteer team, PHP 7.x initially, security patches rolled up periodically. This saved a lot of businesses from being forced to Shopify or a painful Magento 2 migration.
  4. Maho (2024–present) — fork of OpenMage that modernises the stack: PHP 8.3+ native, Symfony components, API Platform, composer-first tooling, PHP attributes replacing XML observers, proper release cadence.

Maho is not a rebellion against OpenMage — it's a continuation. Many of Maho's contributors are active in OpenMage. The split happened because OpenMage's mandate is "stability, minimal change" and Maho's mandate is "modernise aggressively, break where we must". Both are legitimate; they serve different audiences.

Why OpenMage isn't your long-term answer

This isn't a criticism of OpenMage — it's the honest read of what OpenMage is designed to be.

OpenMage is a holding pattern. Its explicit goal is to keep Magento 1 stores running safely while merchants figure out their next move. It is not trying to be a modern ecommerce platform. Headline OpenMage commits are security patches, PHP compatibility updates, dependency bumps. That's valuable — if you're on M1 today and haven't migrated, OpenMage is probably why you're not hacked.

But "holding pattern" has costs:

  • No new features. Anything you want that Magento 1 didn't have in 2020 — modern checkout, API-first architecture, Symfony-grade DI, PHP 8+ attribute-driven observer wiring — you'll have to patch in yourself.
  • Contributor base is shrinking. The people who cared most about M1 have either moved to Magento 2, Shopify, or stopped doing ecommerce work entirely. The remaining OpenMage maintainers are doing good work, but it's volunteer-hours, and PR review queues show it.
  • Commercial extension vendors have mostly left. The Magento 1 extension marketplace has collapsed. Most of the vendors who built you an extension in 2015 now sell Magento 2 or Shopify apps. Maintenance for M1 extensions has largely stopped.
  • The ecosystem is pre-modern. OpenMage still carries Zend Framework 1 baggage, XML-everything configuration, manual SQL in observers, no first-class Composer support for most modules. These aren't fatal — but they make every new hire's first month painful.

If your store is small, stable, and you don't need to change anything for 3 years, OpenMage is fine. If your store needs to keep growing, integrate with modern services, and stay secure as PHP itself changes — OpenMage is a drag you'll feel increasingly.

What Maho adds

Maho took OpenMage's codebase and modernised the parts that were holding it back. Concretely:

  • PHP 8.3+ native. Not "works on PHP 8.3" — built on PHP 8.3. Typed properties, readonly classes, strict return types, Override attributes, first-class enums. If you're a PHP dev, Maho code reads like any other modern framework.
  • Symfony components. Event Dispatcher, HttpFoundation, HttpClient, DependencyInjection — all pulled from Symfony rather than M1's bespoke equivalents. Your team's Symfony knowledge transfers directly.
  • API Platform. Maho ships a modern REST + GraphQL API out of the box via api-platform/api-platform. No more hand-rolled XML WSDL v2 APIs.
  • PHP attributes for observers. Instead of 30 lines of XML in config.xml to wire an observer, you add a #[Observer(event: 'sales_order_place_after')] attribute to your class. The mahocommerce/maho-composer-plugin scans and compiles.
  • Zend Framework 1 removed. Zend_Log, Zend_Http, Zend_Mail — gone. Maho's replacements use Monolog, Symfony HttpClient, and Symfony Mailer. Smaller attack surface, better Composer hygiene, faster load times.
  • Composer-first everything. Every module is a proper Composer package with "type": "maho-module". The composer-plugin handles module registration, attribute compilation, and file copying.
  • SQLite + PostgreSQL support. Not just MySQL. Maho's abstractions are portable. Our own staging site runs on SQLite + Litestream.
  • Active release cadence. Maho ships. Version 26.0 in November 2025. 26.3 in March 2026. Minor releases every few weeks. CVE response time measured in days.

The migration path

If you're on Magento 1 classic, the path is: M1 → OpenMage (as stepping stone) → Maho. If you're already on OpenMage, you skip step 1.

Step 0: Audit

Inventory what you're actually running. For each custom module, answer: do we still use this? Is the vendor still around? Does the code even understand PHP 8.3?

For each commercial extension on your current store, check the vendor's current offering. If they're Magento-2-only now, you either need to find an equivalent that works on Maho (check our marketplace) or rewrite it in-house.

Step 1: Get onto current OpenMage first

If you're still on stock Magento 1.9.x, updating straight to Maho is doable but painful. Easier path: update to current OpenMage LTS first. OpenMage's own migration docs cover this well. You'll hit the same PHP-version and dependency issues either way, but OpenMage's community has battle-tested the M1-to-OpenMage jump for years.

Step 2: Swap the core dependency

Replace openmage/magento-lts with mahocommerce/maho in your composer.json. Pin to the current Maho major (>=26.0 at time of writing). Run composer update mahocommerce/maho.

Expect breakage. The removal of Zend_Log and similar libraries means any module calling them directly will fatal. Fix as they come up — the compiler errors will be clear.

Step 3: Fix modules one by one

For each custom or commercial module that breaks, the usual suspects are:

  • Zend_Log::INFO constants → Mage::LOG_INFO
  • Zend_Db direct usage → use Varien_Db_Expr or the PDO abstraction
  • Zend_Validate → Symfony Validator or plain PHP
  • PHP 7 syntax that PHP 8.3 rejects (dynamic properties, etc.)
  • Module declarations missing <depends> against the old Mage_* modules that Maho removed

For commercial modules, contact the vendor. Many have started shipping Maho-compatible versions in the last six months. If they haven't — and you rely on the module — you may need to fork it or find a replacement on our marketplace.

Step 4: Test, deploy, breathe

Full UAT cycle. Checkout, payments, shipping, admin CRUD, custom workflows. Staging first, prod second. Budget 2–4 weeks end-to-end for a medium-complexity store.

Where Mageaustralia fits

We're one of the early commercial-extension vendors for Maho. That's a deliberate bet — we think the OpenMage / Maho line has another decade of life in it for merchants who care about owning their code. The Magento 2 and Shopify worlds are well-served; the post-M1 community wasn't, until now.

Concretely: all our modules are composer require-installable, tested against the current Maho release, priced 50-65% below the equivalent M2 incumbent, and come with year-1 updates included and year-2+ maintenance at 30% of the license per year. Many of them ship a free OSS tier on GitHub alongside the commercial Pro tier. Browse what's available.

When NOT to migrate to Maho

Honest answer: if your store is stable, low-volume, has no custom logic, and you genuinely don't expect to change anything for 3+ years, you could stay on OpenMage and be fine. Or if your next step is actually to Shopify (because your team is tired of managing infrastructure and Shopify's model fits), that's a legitimate choice too — different tradeoffs.

Maho is the right answer if: you want to stay on a self-hosted, own-your-code ecommerce platform; you have or can hire a PHP developer; you want to be on a modern stack that's actively evolving; and you don't want to pay Adobe's license fees or Shopify's platform fees. That's a specific niche, but it's a large one.

Mageaustralia builds commercial Maho extensions, maintained by us. Browse the marketplace or read about the Cloudflare Storefront architecture this site runs on.