Why Magento upgrades break, and what you actually control on shared hosting

Magento 2.4.9 became the current generally available release in May 2026. It raises the floor on almost every dependency: PHP 8.4 is allowed only for the upgrade transition and PHP 8.5 is the baseline, the old TinyMCE editor is replaced by HugeRTE, and several framework components were swapped out. An upgrade of this size rarely fails because of Magento itself. It fails because a third-party extension still calls a removed API, a theme references a renamed library, or the PHP version the account runs no longer matches what the new code expects. Those failures surface as a blank storefront, a 500 on the admin, or a broken checkout after the files are already in place.

On a managed shared hosting account you do not have root, SSH administrative rights, or the ability to run the Composer-and-CLI deployment sequence that Adobe documents for self-managed servers. You cannot touch my.cnf, run SET GLOBAL, or restart services. What you do control is substantial and enough to run a disciplined, reversible upgrade: full account backups, a separate staging copy under a subdomain, the PHP version through cPanel MultiPHP Manager or the DirectAdmin PHP Selector, limits set through .user.ini and .htaccess, database work through phpMyAdmin, and the Magento admin itself.

Because you cannot roll back a server-wide change, the entire strategy rests on one principle: never modify the live store until an identical copy has been upgraded, tested, and proven on the same account. If your current branch is 2.4.6 or older, treat 2.4.8-p5 as a stepping stone first — the jump straight to 2.4.9 from an old branch combines a PHP change, a database engine expectation change, and a framework change in a single move, which is the hardest thing to reverse cleanly.

Taking a complete, verified backup before touching anything

A backup only counts if it captures both halves of a Magento install — the full document root and the MySQL database — at the same point in time, and if you have confirmed the archive is readable. Enable maintenance mode first so no orders land between the file copy and the database dump. In the admin, go to Stores > Configuration, or create the flag file directly: using File Manager, create an empty file at var/.maintenance.flag inside the Magento root. That pauses storefront writes while you work.

On cPanel Jupiter, the cleanest route is cPanel > Files > Backup > Download a Full Account Backup if your plan allows it, or a partial backup: a home-directory archive plus a database export. For the files alone, open File Manager, select the Magento root folder (for example public_html or public_html/store), and use Compress to produce a .tar.gz you can download. For the database, open phpMyAdmin, select the store database, choose Export, pick the Custom method, and enable Add DROP TABLE so a restore replaces cleanly. Magento databases are large, so compress the SQL with gzip during export.

On DirectAdmin Evolution the equivalent is System Backup > Create/Restore Backups for the account, or File Manager to compress the Magento directory and phpMyAdmin (reached via the database section) for the SQL dump. Whichever panel you use, verify the result: download the archive, confirm the file size is plausible, and open the gzipped SQL locally to check the final table is present and the dump ends cleanly. An export that was truncated by a timeout is worthless, and PHP timeouts during phpMyAdmin exports are common on big catalogs.

If exports time out, raise limits for the duration through a .user.ini file in the Magento root rather than touching any server config:

max_execution_time = 600
memory_limit = 2G
max_input_time = 600

These per-directory values are honored by LiteSpeed on CloudLinux within your account's assigned ceiling. Remove or lower them again once the upgrade is finished so a runaway process cannot consume your allocation.

Building a staging copy and upgrading it first

The safest reversible upgrade happens on a clone, not the live site. Create a subdomain such as staging.yourdomain.com from cPanel > Domains > Subdomains or DirectAdmin > Account Manager > Subdomain Management, pointing it to a fresh directory like staging_store. Copy the live files into it with File Manager (compress the live root, extract inside the staging folder) and create a new database and database user through MySQL Databases, then import your verified SQL dump into that new database via phpMyAdmin.

Point the clone at its own database and base URL by editing app/etc/env.php in the staging copy — update the db credentials and the crypt key stays identical to the original. Then adjust the base URLs. Rather than editing the serialized config by hand, run the updates through phpMyAdmin on the staging database against the core_config_data table, changing web/unsecure/base_url and web/secure/base_url to the staging subdomain. This keeps the clone fully independent so nothing you do on it can reach the live store. For deeper detail on editing those two files correctly, see our guide on editing Magento 2 env.php and config.php safely.

Before deploying any new code, set the PHP version for the staging subdomain to match 2.4.9's requirement. In cPanel use Software > MultiPHP Manager, select the staging domain, and set PHP 8.4 for the transition upgrade; in DirectAdmin use Account Manager > PHP Selector (or Select PHP Version) and enable the extensions Magento needs — bcmath, gd, intl, soap, sockets, xsl, and zip. A missing extension produces a setup error that looks like a Magento bug but is purely an environment gap.

The deployment sequence itself (fetching 2.4.9 via Composer and running setup:upgrade, setup:di:compile, and setup:static-content:deploy) requires command-line access. On a strictly unprivileged shared plan without terminal access, this is the point to involve your hosting support team or a developer with SSH scoped to your account, because those steps cannot be performed through File Manager alone. What you own in this workflow is everything around it: the clone, the PHP configuration, the database, and the testing. Once the staging store is upgraded, exercise it hard — category and product pages, search, add-to-cart, a full guest and logged-in checkout, the admin login with 2FA, and every extension-driven feature. Watch var/log/ and the account's error_log in the Magento root for fatal entries. Only a clean run across every critical flow justifies touching production.

Promoting to production and keeping a tested rollback ready

Schedule the production change for your lowest-traffic window. Re-enable maintenance mode on the live store by creating var/.maintenance.flag in the live root, then take a second fresh backup — the staging work may have taken days, and orders will have accumulated since the first archive. This second backup is your rollback point.

Promote the proven result rather than repeating the upgrade on the live files. Move the live directory aside (rename public_html to public_html_old in File Manager), place the tested staging code into the live path, then restore the live database into it after re-pointing env.php back to the production credentials and resetting core_config_data base URLs to the live domain through phpMyAdmin. Because you renamed rather than deleted the old directory, a rollback is a rename back: restore public_html_old and re-import the pre-upgrade database dump through phpMyAdmin's Import tab. Keep both the old directory and the pre-upgrade SQL untouched for at least a week after go-live before reclaiming the space.

After the files are live, confirm the PHP version on the production domain in MultiPHP Manager or the PHP Selector matches what you validated on staging. Clear the LiteSpeed and Magento caches — delete the contents of var/cache and var/page_cache in File Manager, and flush the LiteSpeed cache from the LiteSpeed Web Cache Manager in cPanel. Remove the maintenance flag only after you have loaded the storefront, placed a test order, and logged into the admin successfully. Finally, revert the temporary high values in .user.ini so the account runs on normal limits. If anything behaves incorrectly in the first hours, resist the urge to patch forward live; your clean rollback exists precisely so you can return the store to a known-good state in minutes and diagnose the problem back on staging.