Planning a Joomla upgrade: paths from Joomla 3, 4 and 5 to Joomla 6

A site keeps running after its security date. What changes is that newly found vulnerabilities in that version are no longer fixed by the Joomla project.

Joomla’s official upgrade guides each cover one step: from 3.10 to 4, from 4.4 to 5 and from 5.4 to 6. An in-place upgrade follows that sequence, with every step rehearsed on a copy of the site.

An upgrade in place runs Joomla’s own update process, step by step, on the existing database and extensions. A migration builds a fresh installation, either a new Joomla 6 site or a different platform, and moves content, users and URLs into it. Use these rules as a starting point; your inventory makes the final call.

Record the installed Joomla, PHP and database versions, then list components, plugins, modules, languages and the active template. For each extension, identify its purpose, vendor, version, update access and business owner. Include disabled extensions and custom changes; something unused today may still contain old data or influence an update. Keep the inventory tied to the actual production installation rather than an old handover document. Unknown ownership is a task to resolve before scheduling the change.

Check the upgrade guidance for the exact starting and target versions, plus each extension vendor’s compatibility information. Core readiness does not establish that the complete site is ready. Joomla’s backward compatibility policy has defined limits, and it does not cover rendered markup. A template override therefore deserves a visual and functional check even when the update completes. Treat uncertain vendor support as an unresolved dependency, with a choice to replace, revise or retire the affected feature.

Create a protected copy with the required files and database, then reproduce the intended hosting configuration closely enough to test the upgrade. Keep private records protected and disable real outbound actions before running journeys. A test form must not email customers; a commerce check must not use live charging credentials. Run the selected upgrade sequence and record warnings, repairs and duration. Keep those instructions reproducible so the final release does not depend on remembering which manual fix worked during rehearsal.

Consider a site whose core has a supported upgrade route but whose request form depends on an extension with no confirmed target compatibility. Simply removing the extension could lose stored submissions and break a business process. First identify the fields, recipients, stored records and downstream actions. Then assess a supported replacement and migrate only what is required. Test field validation, delivery and staff access independently. This makes the replacement an explicit part of the release scope rather than an unpleasant discovery after updating core.

Review more than the homepage. Check article editing, navigation, search, account access, forms and any commercial integration. Compare important old URLs with their intended destinations and inspect the template at narrow and wide widths. Check who can see restricted content and whether a logged-out visitor receives the correct view. Have the content owner perform ordinary administration tasks; a technically successful upgrade can still leave the team unable to publish.

Joomla’s policy does not support downgrading after an upgrade; it advises restoring a backup made immediately before the change. Verify that the backup contains the matching database and files and that someone can restore them in the target environment. Agree the editing freeze or final synchronization, public verification steps and rollback decision owner. Decide how to preserve records created after cutover if rollback becomes necessary. Close the upgrade only when the site’s users and operators can complete the agreed journeys and the final dependency inventory is recorded.

If you want a second opinion on your route, or someone to run the upgrade, these services cover the next step.