PHP 8.2 security support ends December 31, 2026

Keep your Magento 1 store running on a supported PHP version

Magento 1 lost official support in June 2020, and its last official release only goes up to PHP 7.2. If your store still works and a rebuild isn't on the table, I move it onto OpenMage LTS, the community-maintained continuation of Magento 1, and upgrade it to PHP 8.4. Then I prove it works by placing test orders on a copy of your store, before and after.

Book a $300 Upgrade Check-up See how it works

Fixed prices. Work happens on a copy of your store, never on your live site.

Where Magento 1 stands

Adobe ended support for Magento 1 on June 30, 2020, with a last round of security patches. At the time, Adobe told merchants who stayed on it that they take on increased responsibility for their site's security and PCI DSS compliance.

The last official release is Magento 1.9.4.5, from May 2020. Official PHP support went as far as PHP 7.2, added in 1.9.4.0. PHP 7.2 itself stopped getting security fixes years ago, and hosts are retiring it.

OpenMage LTS keeps the Magento 1 codebase alive. It is an unofficial, community-run project, not an Adobe product. Its current 20.x line (20.19.0, released October 26, 2026) requires PHP 8.1 or newer and runs up to PHP 8.5. Its documentation says PHP 8.4 and 8.5 are supported but may still log some warnings, and that 20.x is not 100% backward compatible with Magento 1.9.4. That's why a move to OpenMage needs a real test of your store, not just a file swap.

Sources: Help Net Security, June 29, 2020, quoting Adobe; the OpenMage magento-mirror release list; docs.openmage.org and the openmage/magento-lts package on Packagist. Checked October 31, 2026.

What breaks when a Magento 1 store moves to PHP 8

These are the problems I look for in every Magento 1 upgrade. The core of the store is the easy part, because OpenMage has already done that work. Most of the risk sits in extensions, local overrides and your theme.

What you see	Why it happens	From PHP
The store won't start at all on PHP 8	Official Magento 1 ships with Zend Framework 1, which was never updated for PHP 8, and core code written for PHP 5 and 7. OpenMage replaces Zend Framework 1 with a maintained fork and fixes the core.	8.0
Saved payment gateway and API passwords stop working	Magento 1 encrypts stored credentials with mcrypt, which left PHP core in 7.2. OpenMage uses a compatible replacement library. The Check-up confirms that your existing saved values still decrypt.	7.2
A fix doesn't stick, or an old bug comes back	Magento 1 lets a copy of a core file in `app/code/local` replace the original. Copies made years ago still hold PHP 5 code, and they quietly override OpenMage's fixed version.	Any
Fatal errors from third-party extensions	Older extensions often use `each()`, `create_function()` or string offsets like `$str{0}`, all removed in PHP 8.0. Many vendors stopped updating their Magento 1 versions.	8.0
A product page, the cart or checkout crashes with a TypeError	Built-in functions now throw a TypeError on the wrong argument type, like `count(null)` in a template. These depend on your data, so scanners usually miss them.	8.0
Logs fill with deprecation notices, and admin logins stop sticking	PHP 8.1 deprecates passing `null` to string functions, and 8.2 deprecates dynamic properties. When those warnings are displayed, they are printed before the session cookie is sent, so the session is lost.	8.1 / 8.2
New warnings on PHP 8.4	PHP 8.4 deprecates implicitly nullable parameter types, and OpenMage's own documentation says some warnings may still be logged. The Check-up looks for both.	8.4

How I upgrade a Magento 1 store

Take inventory first. Your Magento version, every extension in app/code/community and app/code/local, your theme, and every core file that was copied into app/code/local/Mage. I compare those copies with the original release so we know exactly what was changed and why.
Move the core to OpenMage 20.x. OpenMage is built on the last official Magento 1 release and keeps its structure, so your catalog, orders and customers stay where they are. Local core copies are either dropped or rebuilt on top of the OpenMage version.
Update extensions before fixing them. Where a vendor has a PHP 8 version, I install it. Where there is none, I patch the extension and document every change, or we agree on a replacement.
Fix your own code and theme. Automated rewrites (Rector) where they are safe, hand-written fixes where tools fail on older code.
Run the store and place test orders. With error reporting at maximum, I walk through the storefront, search, product pages, cart, checkout with a test payment, the customer account, and the admin order, invoice and shipment screens. Cron jobs, indexing and order emails are checked too. I record every error and fix them until the tested flows show zero PHP errors.
Hand over a deployment and rollback plan. You or your host deploy using my step-by-step plan, with a fresh backup taken first.

Stay on Magento 1, or move on?

OpenMage on PHP 8.4

My default. Your store, extensions and data stay the same, and the platform underneath gets a supported PHP version and an active community project.

Magento 2 or another platform

Magento 2 (now Adobe Commerce and Magento Open Source) is a different codebase. Moving to it, or to any other platform, means a new theme, new extensions and a data migration. It is not part of the upgrade price. If you want it, it's quoted as its own project.

Staying on PHP 7

Not something I can recommend. Neither official Magento 1 nor PHP 7 gets security fixes anymore, and your host will retire old PHP versions on its own schedule.

What a Magento 1 upgrade with me looks like

I haven't published a Magento 1 upgrade. What I have published are three practice upgrades of real open-source PHP projects: a CodeIgniter 3 booking app, a custom membership system and a WooCommerce plugin, each with before-and-after error counts. Every Magento project follows the same method: a recorded click-through before the upgrade, the same click-through after it, and a list of what was tested and what wasn't.

See the practice upgrades

Pricing for Magento 1 stores

Magento 1 stores vary too much in extensions and local changes for one fixed price, so every store upgrade gets a fixed quote after the Check-up.

Upgrade Check-up

$300

One-time · 5-day delivery

Inventory of extensions, theme and copied core files
Static scan of your extensions, custom code and theme
Dynamic property check (PHP 8.2+)
One runtime smoke test of your key flows on OpenMage and PHP 8.4
Written issue list and fixed-price upgrade quote
Full $300 credited if you order the upgrade within 30 days

Requires a working copy you provide. No working copy? Add environment setup for $150 (adds 3 days).

Book the Check-up

Store upgrade

Fixed quote

Price and delivery set in the Check-up

Core moved to OpenMage 20.x
Extensions updated, patched or replaced as agreed
Upgrade to PHP 8.4
Before-and-after smoke test report, with test orders
Deployment and rollback plan
14 days of free fixes on tested flows

No surprise invoices. Anything outside the agreed scope is quoted before I touch it.

Start with a Check-up

Maintenance

$200

Per month · cancel any time

Monthly security update check for PHP and your dependencies
Smoke test re-run after your host changes PHP versions
Up to 2 hours of small fixes per month (unused hours don't roll over)

Ask about it

Quoted separately

These often come up during a Magento 1 upgrade but are separate jobs, so they never hide inside a fixed price:

Moving to Magento 2, Adobe Commerce or another platform
Rebuilding an abandoned extension's features from scratch
Payment or shipping integrations whose provider has retired the API they use
Writing new automated tests
Hands-on deployment and go-live support

Delivery times count from the day I receive your working copy and answers to the intake questions. Full details on the main pricing page.

Want a first look yourself?

Refit is my free, open-source command-line scanner. It runs a compile check, PHPCompatibility and a dynamic property check on PHP code and tells you, in plain language, what will fail on PHP 8.4. It doesn't send your code anywhere.

On a Magento 1 store, point it at the folders that hold extensions and custom code rather than the whole store. It is static analysis, so it can't see the runtime failures described above, and it doesn't replace testing on OpenMage. If the report looks bigger than you want to handle, the Check-up takes it from there.

Run it on a copy of your store. Refit itself needs PHP 8.1 or newer to run, even when the code it checks is older. PHPCompatibility 10 is still tagged alpha, so it has to be named once in the command:

composer require --dev qiyuanlabs/refit "phpcompatibility/php-compatibility:^10.0@alpha"
vendor/bin/refit scan app/code/local --php=8.4
vendor/bin/refit scan app/code/community --php=8.4

Get Refit on GitHub

Questions

Is OpenMage the same as Magento 1?

It is built on the Magento 1 code and keeps its structure, so stores, themes and most extensions carry over. It is an unofficial community project, not an Adobe product, and its 20.x line has changes that aren't 100% backward compatible. The Check-up finds out what that means for your store.

Do I have to move to Magento 2?

No. The upgrade keeps your store on the Magento 1 codebase through OpenMage. Moving to Magento 2 or another platform is a rebuild, and it's quoted separately if you want it.

Will my extensions still work?

That is the main question the Check-up answers. For each extension you get one of three answers: a PHP 8 version exists, it needs patching, or it should be replaced. Payment and shipping extensions get extra attention because their providers may have changed their APIs too.

Which PHP version will my store run on?

PHP 8.4 by default, which gets security fixes until December 31, 2028. OpenMage 20.x supports PHP 8.1 to 8.5. If your host already offers 8.5, the Check-up tells you whether that's realistic for your extensions.

Does this make my store PCI compliant?

No upgrade can promise that, and I don't do PCI assessments. A supported PHP version and a maintained platform remove two obvious problems. If you take card payments on the site, talk to your payment provider about what else they require.

What do you need from me for the Check-up?

A working copy: a staging store, or your code plus a database export that runs. It helps to tell me your Magento version (shown in the footer of the admin panel), your current PHP version, and the flows your business depends on, such as checkout, a B2B price list or an ERP sync.

Do you need access to my live store?

No. All work happens on a copy, and by default I don't deploy, so I never need production access. You get the upgraded code and a step-by-step deployment and rollback plan.

My database has customer and order data. How do you handle it?

Where possible, send a copy with personal data removed or replaced. Any copy I receive stays private and is deleted when the project ends. If your database holds payment card data, tell me before sending anything so we can agree on a safe approach.

Will the upgrade catch every bug?

No one can promise that. The smoke test covers the flows we agree on in the Check-up. I list what was tested and what wasn't, so you know exactly where the coverage stops.

Who are you?

I'm Bo Zeng, a PHP developer with 18 years of experience. I run QiYuan Labs LLC, a US company registered in Wyoming, and work remotely. Email hello@qiyuanlabs.ai with any question before you book.

Find out what your Magento 1 store needs before your host decides for you

The Check-up costs $300 and tells you exactly what an upgrade involves and what it will cost.

Book a $300 Upgrade Check-up