Planning a Joomla upgrade

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 migration 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 compatibility policy has defined limits, and its policy does not promise unchanged 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 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.