JoomlaForever.com! - Upgrading from Joomla 3.10 to Joomla 4 — a practical, beginner-friendly checklist

Details: Written by: Bjørn Ove Bremnes; Parent Category: Community Questions; Category: Community Questions - News; Published: 27 May 2026

Upgrading a Joomla site from 3.10 to Joomla 4 is a sensible move for long‑term security and features, but it often scares site owners because of third‑party extensions, custom templates and PHP version changes. This guide gives a practical, beginner‑friendly checklist and a safe sequence to follow. The single safety promise: never run the core upgrade on production without a tested backup and a successful staging dry run.

Quick answer: risk, time and outcomes — what to expect

Short answer: the upgrade can be low‑risk if you perform it on a staging copy, have verified backups, and confirm that third‑party extensions and your template are Joomla 4 compatible. Risk rises when many extensions are unmaintained, when templates use deep core overrides, or when you cannot create a staging environment.

Typical time and outcomes

Small sites (few extensions, standard template): 1–3 hours on staging plus ~1 hour for production.
Medium sites (several third‑party components): several hours to a full day to test and fix issues.
Complex sites (custom code, commerce systems, integrations): days or longer; likely need developer support.

When upgrades are typically smooth

Your site relies mainly on core features and well‑maintained extensions that list Joomla 4 support.
Hosting already meets Joomla 4 requirements and PHP can be switched safely on staging.

When to expect trouble or postpone

Many custom or unmaintained third‑party extensions and deep custom template overrides.
No reliable backup or inability to create a staging copy.
Complex integrations (payment gateways, external APIs) that cannot be tested easily in staging.

Practical example: Site A uses five popular extensions with active updates — likely smooth in a few hours. Site B uses ten custom plugins with no vendor support — expect replacement work and several days of effort.

Warning:

Do not attempt the core upgrade on production without a tested backup and staging dry run. Joomla core will not automatically convert incompatible third‑party extensions — extension updates are controlled by their vendors.

Pre-upgrade checklist (summary)

This one‑page checklist lets you prepare quickly before the detailed steps below. Print or save it and tick items off as you go.

One‑page quick checklist

Create a full backup (files + database) and verify you can restore it.
Make a staging copy of the site and run the upgrade there first.
Inventory all extensions, plugins and template customizations.
Confirm server meets Joomla 4 requirements and plan PHP changes.
Plan a maintenance window for the production upgrade.
Document a rollback plan and download backups offsite.

Warning:

A backup is only useful if you can restore it. Always test a restore on a separate environment before changing production.

Step 1 — Inventory: list your core, extensions, plugins and template

Before changing anything, build a complete inventory so you can identify which items may cause problems.

Why an inventory matters

An inventory highlights risk points, records who to contact for updates, and helps prioritise work. You may discover that a single unmaintained plugin is the blocker for a smooth upgrade.

Fields to include (spreadsheet template)

Extension name
Type (component, module, plugin, template)
Current version
Developer / vendor
Update available (Y/N)
Joomla 4 compatible (Y/N/Unknown)
Action required (update / replace / disable / remove)
Notes / contact information

What 'incompatible' typically looks like

Frontend errors or white screens, admin page errors, missing layout or menu items.
PHP fatal errors or deprecated function warnings in logs.
Extensions that partially work with degraded functionality.

Warning:

Do not rely only on the Extension Manager listing — check the Joomla Extensions Directory (JED) or the vendor website for official Joomla 4 compatibility statements.

Step 2 — Back up and create a staging site (don’t work on production)

Cloning your site to staging is essential. Work on the staging copy until everything is proven, then repeat the same steps in production during a maintenance window.

Backup methods: files + database vs. full‑site packages

Manual backup: export the database (phpMyAdmin, Adminer or CLI) and compress/download the site files (via FTP/SFTP or control panel). Store both copies offsite.
Backup extensions: many backup tools produce a full restore package — verify that the extension supports a full‑site restore to a staging environment before relying on it.
Test restore: import the DB and restore files on a separate environment to confirm the backup integrity.

Creating a staging environment

Options: host‑provided staging (recommended if available), a subdomain (a protected staging subdomain), a subfolder, or a local environment (DevDesktop, Docker, etc.).
Clone steps: copy files, import DB, update configuration.php with the new DB credentials and site URL, and adjust tmp/log paths if necessary.
Secure staging: protect with HTTP authentication, set Robots meta to noindex, and disable outgoing emails (or route them to a testing mailbox).

Step‑by‑step backup example:

Create a full‑site backup via your chosen method and download the archive and DB dump.
Create the staging site (subdomain) and upload files.
Import the DB dump and update configuration.php and the site's live URL settings.
Test staging: open the front‑end, log into the admin, and confirm key pages work.

Warning:

If your backup tool is unverified, also take manual DB and files backups. Be careful editing configuration.php — incorrect values can break the staging site.

Step 3 — Verify server requirements and PHP version plan

Joomla 4 requires specific PHP, database and webserver versions. Confirm the exact requirements against the official Joomla documentation before making changes to production.

How to check current PHP version

Joomla admin: System → System Information shows PHP version.
Create a phpinfo.php with <?php phpinfo(); ?> and open it (remove after use).
Check your hosting control panel (cPanel, Plesk or host custom panel) for a PHP version selector.

When to update PHP: staging vs production

Always switch PHP on staging first and test thoroughly. If problems appear, fix them on staging before repeating the process on production in a maintenance window. Some hosts allow per‑directory PHP versions or multiple PHP runtimes — these are useful for testing.

Recommended sequence (example): switch PHP on staging → run tests → perform Joomla core upgrade on staging → when everything is green, schedule and perform equivalent steps on production.

Warning:

Do not upgrade PHP on production before a successful staging run. Higher PHP versions may expose incompatibilities in older extensions.

Verify the exact minimum and recommended PHP versions for the Joomla 4 release against the official Joomla system requirements before changing PHP in production.

Step 4 — Handle incompatible extensions and templates

This is the core risk area. Decide whether to update, replace, disable or remove each incompatible item.

Options for incompatible extensions

Update: if a Joomla 4 compatible version exists, test it on staging first.
Contact vendor: ask about timelines or paid upgrade paths.
Replace: search the JED for maintained alternatives and test replacements on staging.
Disable/remove: for non‑essential items, disable temporarily to reduce upgrade complexity, but back up DB first because some uninstalls alter tables.

Templates and custom overrides

Templates often need work. Check the vendor for a Joomla 4 update. If your site relies on many template overrides, test by switching to a default Joomla 4 compatible template on staging to isolate template causes from core ones.

Using the Extension Manager

Check Extensions → Manage → Update for available updates.
Temporarily disable suspected extensions and re‑test to see if issues resolve; disabling is safer than immediate uninstall when diagnosing.

Decision flow example: Extension flagged incompatible → check vendor for Joomla 4 release → if none, search JED for alternatives → test replacement on staging → remove or disable original when replacement is verified.

Warning:

Removing or disabling an extension can change database state or content. Back up the database before removing an extension, and test changes on staging first.

Step 5 — Perform the Joomla core upgrade (safe sequence)

Follow a disciplined sequence: prepare staging, update PHP if required, update compatible extensions, then run the core upgrade. Repeat the same steps on production once staging is verified.

Recommended sequence on staging

Ensure PHP and server requirements meet Joomla 4 (verify exact values against official docs).
Update third‑party extensions that explicitly support Joomla 4.
Put staging in maintenance mode and take a fresh backup.
Run the Joomla core upgrade.
Clear caches, test key pages and admin tasks.

Admin GUI vs CLI (pros and cons)

Joomla Update component (GUI): easier for beginners and visible in the admin interface; may be blocked by some hosting setups or large files.
CLI (SSH/composer): more control and often faster for large sites; requires SSH access and command‑line familiarity.

Production checklist: schedule low‑traffic window → final backup → switch PHP if required → put site in maintenance mode → run upgrade → clear caches and monitor logs.

Warning:

If a core upgrade fails and leaves the site partially updated, avoid ad‑hoc fixes on production. Restore from backup and diagnose on staging.

Verify whether your current Joomla 3.10 minor version can be upgraded directly via the Joomla Update component for the specific Joomla 4 release—check the official Joomla documentation before performing the upgrade.

Step 6 — Post-upgrade checks and testing

After upgrading, run a set of functional and monitoring checks to confirm the site is healthy.

Testing checklist: front‑end, admin, forms and integrations

Visit the homepage and the top 20 pages; verify layout and content render correctly.
Test forms and contact pages; confirm emails are sent (use staging sandboxed addresses before production).
Log in as admin and perform key tasks in major components (e.g., create/edit an article, run a batch process).
Test integration endpoints: payment gateway sandbox, API connections, CRMs; verify scheduled tasks or cron jobs run.
Check server and Joomla logs (PHP error log and logs in administrator) for new warnings or errors.

Checklist before going live

Remove maintenance mode when confident.
Take a fresh backup and download it offsite.
Inform stakeholders of the change and expected monitoring period (24–72 hours).
Monitor performance and error logs closely in the immediate post‑upgrade period.

Warning:

Some issues only appear under real user load. Keep monitoring and have a rollback plan ready. Also, clear server caches and restart PHP‑FPM or clear OPCache if available to avoid stale code running.

Troubleshooting common problems and rollback options

Understand the common failure modes and prepare clear rollback steps.

Common post‑upgrade problems

Blank pages (white screen) or PHP fatal errors.
Broken templates or missing styles.
Forms or modules not functioning.
500 server errors or permission issues.

Rollback approaches

Full restore: restore files + DB from the pre‑upgrade backup — most reliable but requires downtime.
DB restore only: faster but may not correct file‑level changes introduced by partial updates.
Component/template revert: switch to a default Joomla 4 template if frontend rendering is broken to buy time for debugging.

Diagnostic steps

Put site into maintenance mode to prevent further errors affecting visitors.
Check PHP and webserver error logs for the exact messages.
On staging, enable Joomla debug mode and reproduce the error to find the faulty extension or template.
If a single extension is the cause, try disabling it and check whether the site recovers.

Warning:

Never overwrite production files until you have a verified restore plan and downloads of backups. Some control‑panel restores omit custom cron jobs or non‑standard folders — verify what will be restored before relying on a single restore method.

When to hire professional help and how to find it

Know when the upgrade is beyond your skillset and how to vet Joomla specialists.

Red flags that indicate a professional is needed

Extensive custom template overrides or many unmaintained extensions.
Business‑critical integrations (payments, membership, ERP) that cannot tolerate downtime.
No reliable backups or inability to create staging.

What to ask prospective developers

Show examples of previous Joomla 3→4 upgrades and references.
Will they perform the upgrade on staging, test, and perform a documented rollback test?
Request an itemised plan, timeline and firm milestones, and ask about post‑upgrade monitoring.

Budget guidance: simple upgrades may cost a few hundred dollars; complex migrations with custom work can be significantly more. Prefer developers who provide a clear plan rather than open‑ended promises.

Resources and further reading

Bookmark official sources and the Joomla Extensions Directory while preparing your upgrade. Verify all external documentation against the current Joomla release at publication.

Suggested pages to bookmark

Official Joomla upgrade documentation (verify URL at publication).
Joomla 4 system requirements (verify exact PHP and database versions).
Joomla Extensions Directory (JED) to check extension compatibility or find alternatives.

Warning:

External links and system requirements should be verified at the time you upgrade — documentation and recommended versions change over time.

FAQ

Will my site "blow up" if I try the automatic Joomla core upgrade?

Not if you follow the checklist: run the upgrade on a staging copy first, ensure tested backups, and check extension compatibility. Most upgrade failures are caused by incompatible third‑party extensions or incorrect PHP versions.

How do I find which extensions and templates are incompatible with Joomla 4?

Build an inventory from Extensions → Manage, then confirm each extension’s Joomla 4 status on the vendor site or JED. On staging, disable suspicious extensions one by one to isolate problems. Automated compatibility tools exist — verify their accuracy before relying on them.

Do I need to change PHP before or after upgrading Joomla?

Update PHP on staging first and test. After a successful staging core upgrade and tests, perform the PHP change in production during the scheduled maintenance window. Verify exact PHP requirements against official Joomla docs before changing PHP in production.

How do I create a safe staging copy of my site?

Create a clone on a subdomain or use a host‑provided staging environment, import the DB, update configuration.php and block search engines and email sending. Test login and key functionality on staging before attempting upgrades.

What are my rollback options if the upgrade causes problems?

Primary options: restore a full backup (files + DB), restore DB only, or switch to a default template and disable problematic extensions while diagnosing. Confirm your backup method supports full restores before relying on it.

What to do if the original developer is unavailable?

Inventory the site, document extension and template versions, look for maintained alternatives in JED, consider hiring a Joomla specialist with migration experience, or temporarily disable non‑essential extensions while you plan replacements.

Conclusion

Upgrading from Joomla 3.10 to Joomla 4 is a manageable project when approached methodically: inventory everything, back up and clone to staging, verify server and PHP requirements, address incompatible extensions and templates, perform the core upgrade on staging first, then repeat on production during a maintenance window. If you have custom code, business‑critical integrations or many unmaintained extensions, plan for professional help.

When in doubt, verify upgrade steps and system requirements against the official Joomla documentation before making production changes, and always test your restore process ahead of time.

Add comment

Three ways optimize the use of CSS in content with Joomla

CSS has from the age of the Internet been a part of doing websites. It is an easy but useful way to design an article. There are several ways to write CSS in Joomla, you can use an external file to store all CSS codes in, you can use an extension to include the code, or you can write CSS directly in the content. In this article, I will give some look into how I do it.

In this article, I will show you three different ways to use CSS in an article. The easiest thing is to use an extension to add CSS to the article. There are several extensions in the JED (Joomla Extensions Directory) that gives this opportunity. One of the popular is Sourcerer from Regular Labs. But its also possible to do in-line CSS coding in every article, but this can be very ineffective in large articles, the third and maybe most used is to put the CSS codes into the template as eighter an external file or in the CSS capabilities of the template itself. In modern template-Framework is this common, the disadvantage of this is that you always need access to the backend to add extra CSS in your site.

W3C CSS verified: W3c.org is setting the standards for CSS

1 Code directly as you go (Hard coding the articles)

If you prefer to do the CSS coding inline as you write an article, you must bear in mind that you will NOT be able to reuse the CSS on any other articles and you must repeat the same thing for every content with the same code. This could look like this:

<a href="/home" style="background-color:#ff0000;color:#ffffff;">Home</a>

This will output: Home

2. Use an external file

If you use an external file as a CSS source, it is normally located under the css folder in your template directory. And its usually called custom.css or user.css, the downside with this is that you need access to either FTP or bee logged in to the backend as a Super Administrator.

3 Use an extension to add CSS code in the article

If you want to use an extension to insert CSS in an article, you can not reuse the CSS codes without having it in every article that contains the same style.

What do I recommend?

A combination of the option 2 and 3, will give the easiest result and you can standardize some of the CSS styles in a file and add styles in that applies to certain articles at one addon at the end of the written article.

Comments wanted