Upgrading an old Joomla site: how we decide between upgrade, rebuild and migrate

A lot of the Joomla sites we are asked to look at were built between 2012 and 2018. They still run the business: a member directory, a course catalogue, a booking form wired to a payment gateway. The owner usually calls us for one of three reasons. The host has dropped the PHP version the site needs, an extension developer has vanished, or an audit has pointed out that the Joomla release is no longer receiving security fixes.

This post is how we approach that conversation. It is not a sales pitch for rebuilding everything, and it is not a claim that Joomla is dead. It is a way to decide what to do with a Joomla site you already own.

Start with an inventory, not a version number

"We are on Joomla 3" tells us very little. What decides the cost of an upgrade is what sits on top of the core. In the first day we list:

• Extensions. Every component, module, plugin and template, with the vendor, the installed version and whether the vendor still ships updates. A site with 40 extensions usually has 8 that matter and 32 that someone installed for a campaign in 2016.
• Template overrides. Custom html/ overrides in the template folder are the most common reason an upgrade looks fine in staging and breaks the checkout page.
• Custom code. Anything written for the site by a freelancer: small plugins, edits inside component files, hand-made database tables. Edits inside third-party component files are the worst case, because no update path remembers them.
• PHP and database versions on the host. Joomla's supported PHP range moves with each major release, so the hosting plan and the CMS version have to be planned together.
• Content volume and shape. Ten thousand articles with custom fields behave very differently from two hundred pages.

We put this in a spreadsheet and share it with the client. It is also the document we use later to explain the quote.

Three honest options

Once the inventory exists, there are usually three paths.

1. Upgrade in place, in stages. If the extensions are mostly actively maintained and the template is modest, we move the site to a currently supported Joomla release on a staging copy, replace or patch the extensions that fail, rebuild the template overrides, and test the paths that earn money. This is the cheapest option when it works, and it keeps URLs, users and content as they are.

2. Rebuild the front end, keep Joomla for content. If editors are happy with the Joomla admin but the public pages are slow and hard to change, we can keep Joomla as the content store and replace the theme, or serve a React front end from Joomla's web services API. This only makes sense if the site has real editorial workflows worth preserving.

3. Migrate to another stack. Sometimes the site has become a simple brochure with a blog, and WordPress is easier for the team to maintain. Sometimes it is really an application with members and payments, and Laravel is the better home. We do not recommend this by default, because a migration means redirects, SEO risk and retraining. We recommend it when the inventory shows that the site is fighting the CMS.

In our experience, option one covers most of the sites we see. Options two and three are for the minority where the business has changed more than the website has.

Where upgrades actually go wrong

The core Joomla migration tooling is rarely the problem. The problems are almost always at the edges.

• Abandoned extensions. If a component has no maintained version for the target Joomla release, you either replace it, which means migrating its data, or you pay someone to port it. We ask for this early because it is the biggest swing in cost.
• Custom fields and SEF URLs. If the old site had search-friendly URLs that Google already knows, we map every one of them and test the redirects against the list from Search Console, not against our memory of how the site works.
• User accounts and permissions. Access levels and user groups are easy to get subtly wrong. A members-only page that becomes public is worse than a page that is briefly broken.
• Mail and payments. Contact forms, order emails and payment callbacks depend on server configuration as much as on Joomla. We test them with real transactions in a sandbox before the switch.
• Language packs. For Nepali, Hindi or bilingual sites, we check the right-to-left and font behaviour of the new template instead of assuming it carries over.

What we do before we touch anything

Our checklist before any work on a live Joomla site:

1. Full file and database backup, restored once onto a separate server to prove it works.
2. A staging copy with a different domain, blocked from search engines and from sending real emails.
3. A list of ten to fifteen journeys that must keep working: sign in, submit the form, pay, download the file, find the page that brings the most organic traffic.
4. Screenshots of those journeys on the old site, so that "it looks different" can be settled with evidence.
5. A rollback plan with a named person and a time limit.

None of this is clever. It is the difference between an upgrade weekend and an upgrade week.

Where AI helps on a Joomla site, and where it does not

Clients often ask whether they can add an assistant to an existing Joomla site. The answer is usually yes, without changing the CMS much. A practical pattern is to export the published articles and documents, index them in a separate small service, and add a chat or search box to the site that calls that service. Joomla stays what it is, and the assistant answers only from content the site already publishes. We would build that as a separate Python or Laravel service, with a clear fallback to the contact form when the answer is not found.

What we do not recommend is letting an assistant write directly into Joomla articles without an editor reviewing them. The admin interface has good versioning, and a human clicking Publish is the cheapest quality control the site has.

What we would ask you first

If you are weighing an upgrade, send us the following and we can give you a first opinion without a meeting:

• The Joomla version, shown in the admin footer or system information page.
• The list of installed extensions, which Joomla can export from the Extensions manager.
• Your hosting plan and current PHP version.
• Your five most important pages and your most important form.

From that we can usually say which of the three options fits, what the biggest risk is, and roughly how the work would be staged. Then we can decide whether it is worth doing at all.

Before planning, please check the current release and support dates on the official Joomla roadmap at joomla.org, because they change with each major version and we would rather you read the primary source than rely on our summary.