How to Migrate Joomla to WordPress : 9 Steps and What Breaks [2026]
Sometimes leaving is the right call. The content migrates; the functionality usually does not.
You have a Joomla site and you are considering moving it to WordPress, and most of what you will read on the subject is written by people selling one platform or the other. This publication is about Joomla, and it is still going to tell you plainly: sometimes leaving is the correct decision, and pretending otherwise helps nobody.
What follows is an honest account of what a Joomla to WordPress migration involves in 2026 — what transfers cleanly, what does not transfer at all, and the one step that determines whether you keep your search traffic. The short version, which the rest of the article expands: your content will migrate, and your functionality will not.
First, decide whether to migrate at all
Migration carries real cost and real risk, and a meaningful proportion of the ones we see were not necessary. Work through this table honestly before reading further.
| Your reason for migrating | Verdict | Why |
|---|---|---|
| Site is on Joomla 3 and unsupported | Migrate — but consider Joomla 5 first | Joomla 3 to 5 is a smaller job than Joomla to WordPress, and keeps your extensions’ equivalents |
| Cannot find a Joomla developer | Legitimate reason to migrate | Maintainability by available people is a real engineering constraint |
| Need a specific plugin only WordPress has | Check for a Joomla equivalent first | Migrating an entire site for one feature is rarely proportionate |
| Content editors find Joomla confusing | Investigate before migrating | Often solved by a properly configured editor and sensible ACL, at a fraction of the cost |
| Building a large e-commerce operation | Reasonable, but evaluate honestly | Both platforms have capable options; the tooling ecosystem is genuinely larger on WordPress |
| Someone told you WordPress is better for SEO | Not a reason | Both platforms produce clean, indexable markup. Content and site structure decide rankings |
| Agency you hired only builds WordPress | Honest reason, name it as such | It is a supplier constraint, not a technical finding — decide with that clear |
| Site is complex, with heavy ACL and custom extensions | Think very hard | This is the profile where migrations run over budget by multiples |
If your motivation is that you are stranded on Joomla 3, price both routes before deciding. Joomla 3 to Joomla 5 is a genuine project — the API changed substantially at Joomla 4 and some extensions have no successor — but you keep your content structure, your URLs and your team’s knowledge. A cross-platform migration throws all three away. Get both quoted.
Inventory what you actually have
You cannot scope this without a written inventory, and building one takes an afternoon. Every migration that overran did so because of something on this list that nobody wrote down.
Count the content
In the Joomla administrator, record the number of articles (including archived and trashed), categories and their nesting depth, contacts, and any content held in third-party components. Note how many articles use custom fields, and how many have images in the intro versus the full text.
Also count your media: Content → Media, and check the actual directory size on disk. A site with 8,000 images has a different migration profile from one with 80.
List every extension and what it does
Go to System → Manage → Extensions and export or write down every non-core component, module and plugin. For each one, note what the site would lose if it vanished. This list is your functionality gap, and it is the part of the project nobody budgets accurately.
Capture the URL structure before you touch anything
Export a full list of live URLs. The most reliable source is your Google Search Console coverage report combined with your existing XML sitemap and, if you can get it, twelve months of server access logs. You want every URL that receives traffic or has inbound links.
Do this first. Once you have changed the CMS, reconstructing the old URL structure accurately is difficult and the mistakes are invisible until traffic drops.
Record the traffic baseline
Take a screenshot or export of the last twelve months of organic traffic and your top 100 landing pages by impressions. After migration this is the only way to distinguish “the migration cost us traffic” from “search demand changed seasonally”. Without a baseline every post-launch conversation is guesswork.
What migrates cleanly
The good news, and it is genuinely good: the core of a content site transfers well, because both platforms model content similarly enough.
| Joomla | WordPress equivalent | Migration quality |
|---|---|---|
| Articles | Posts or Pages | Clean — title, body, dates, state |
| Categories | Categories | Clean, including nesting in most tools |
| Tags | Tags | Clean |
| Users | Users | Accounts transfer; passwords usually do not — plan a reset |
Images in /images |
Media library | Files copy; references need rewriting |
| Article metadata (meta description, keywords) | SEO plugin fields | Usually needs mapping, occasionally manual |
| Publish and unpublish dates | Post status and dates | Clean |
| Authors | Post authors | Clean if users migrated first |
What does not migrate
This is the list that decides your budget. None of these transfer, and each is a rebuild.
| Joomla feature | Migrates? | What it actually means |
|---|---|---|
| Extensions (components, modules, plugins) | No | Find WordPress equivalents, reconfigure each, re-enter their data |
| ACL configuration | No | Joomla’s viewing-access-level model has no WordPress equivalent; rebuild with a membership plugin |
| Custom fields | Partially at best | Values may migrate as post meta; field definitions and their display do not |
| Module positions and assignments | No | WordPress widgets and blocks are a different model entirely |
| Menu structure | Partially | Labels and hierarchy can transfer; menu item types and their parameters cannot |
| Template overrides | No | Joomla’s html/ overrides have no counterpart; rebuild in the theme |
| Language associations (multilingual) | No | Joomla’s core multilingual model differs fundamentally from WordPress plugin approaches |
| URL structure | No | This is the redirect map, and it is the most important step in the project |
| Form submissions and their history | Rarely | Export to CSV before migrating; you will not get them back afterwards |
| Third-party component content | Case by case | Directory, events, catalogue data usually needs a bespoke script |
If your Joomla site uses core multilingual with content associations, treat this as a substantially larger project than a monolingual one — closer to several separate migrations plus a relinking exercise. Joomla handles multilingual in core; WordPress handles it through plugins with different data models. Every association between a page and its translations has to be rebuilt, and the automated tools handle this poorly or not at all.
Choosing a migration method
Three approaches, and the right one depends almost entirely on how many articles you have.
| Method | Suits | Effort | Risk |
|---|---|---|---|
| Manual copy and paste | Under about 50 articles | Hours to days | Very low — you see every page |
| Plugin-assisted import | 50 to several thousand articles | Setup plus verification | Moderate — silent partial failures |
| Custom script against the database | Unusual structures, third-party component data | Developer days | Depends entirely on the developer |
Manual migration is underrated. For a 30-page brochure site it is often faster end to end than configuring and verifying an import tool, and it gives you a free content audit — you will delete perhaps a third of the pages once you actually read them.
For larger sites, importer plugins exist that connect to your Joomla database and pull content across. They work reasonably for the clean-migration column above. Budget as much time for verification as for the import itself, because their failure mode is partial success that looks like complete success.
The redirect map: the step that decides everything
If you take one thing from this article, take this. Joomla and WordPress generate different URLs, and every URL that changes without a redirect is a page that loses its accumulated search value, its inbound links and its bookmarks.
Typical URL patterns you are moving between:
# Joomla, SEF with IDs
/12-category-alias/45-article-alias
# Joomla, SEF without IDs
/category-alias/article-alias
# Joomla, non-SEF
/index.php?option=com_content&view=article&id=45
# WordPress, common permalink structures
/article-alias/
/2026/03/article-alias/
/category-alias/article-alias/Build the map as a spreadsheet, before launch
Two columns: old URL, new URL. Every old URL that received a visit or has an inbound link must appear. Source them from Search Console, your sitemap and your access logs — not from a crawl of the new site, which by definition cannot know what used to exist.
Sort by traffic descending and work down. If the site is large, accept that the tail will be handled by pattern rules rather than one by one, but the top few hundred URLs should be mapped explicitly and checked individually.
Choose your permalink structure to minimise the map
Before importing, set WordPress permalinks to whatever structure most closely resembles your existing Joomla URLs. If your Joomla URLs were /category/article-alias, use the /%category%/%postname%/ structure and a large portion of your URLs will match with no redirect at all.
Do not use the date-based default. It guarantees that every single URL changes, which converts a small redirect map into a large one for no benefit.
Implement as 301s and test before you switch
Use permanent redirects, not 302s — a temporary redirect tells search engines the change is not permanent and value does not consolidate. Implement in server configuration where you can, because it is faster than a plugin and does not depend on WordPress booting.
# Apache: a pattern rule for Joomla ID-prefixed URLs
RedirectMatch 301 ^/[0-9]+-([a-z0-9-]+)/[0-9]+-([a-z0-9-]+)$ /$2/
# Nginx: an explicit high-value redirect
location = /12-services/45-consulting {
return 301 /consulting/;
}Test every redirect on staging before the DNS change. A redirect chain — old URL to intermediate to final — loses value and slows the crawl; each rule should reach its destination in one hop.
Do not delete the redirect map after six months because “the traffic has moved over”. Inbound links from other sites point at the old URLs indefinitely, and some of them are the most valuable links you have. These rules stay in place for the life of the domain. Keep the spreadsheet in version control alongside the site.
Rebuilding functionality: how to scope it honestly
Step seven of the nine is where migrations overrun, because “rebuild the functionality” is written as one line on a plan and is in reality most of the project. Scope it by going through your extension inventory and putting each item in one of four buckets.
| Bucket | Description | Typical effort |
|---|---|---|
| Direct replacement | An obvious WordPress equivalent exists; configuration only | An hour or two each |
| Replacement plus data | Equivalent exists but its content must be moved across | Half a day to days, depending on volume |
| No equivalent | Nothing on WordPress does this; needs custom development or a changed requirement | Open-ended — get this scoped before committing |
| Delete it | Nobody has used it in years and nobody will notice | None, and it is often a third of the list |
Sort before you commit to a budget, and be aggressive about the fourth bucket. Long-lived Joomla sites accumulate extensions installed for a campaign years ago and never removed, and a migration is the one moment when deleting them is free.
The bucket that hurts is the third. If anything lands there — a bespoke component, an unusual ACL arrangement, a workflow built out of several extensions interacting — stop and cost it properly before the project starts, because that single item may exceed the cost of everything else combined. It is also the point at which staying on Joomla and upgrading in place may become the cheaper option, and it is entirely reasonable to reverse the decision at this stage.
The nine steps in order
| # | Step | Do not skip because |
|---|---|---|
| 1 | Full Joomla backup, files and database, restore-tested | An untested backup is a hope, not a backup |
| 2 | Inventory content, extensions, URLs, traffic baseline | Everything later depends on this |
| 3 | Build WordPress on a staging URL, blocked from indexing | An indexed staging copy competes with your live site |
| 4 | Set permalinks before importing anything | Changing them after import rewrites every URL again |
| 5 | Import content, then verify a sample against the original | Partial imports look identical to complete ones |
| 6 | Migrate and re-link media, fix in-content image paths | Images referencing /images/ break silently |
| 7 | Rebuild functionality: forms, menus, modules, access control | This is the majority of the work, not an afterthought |
| 8 | Build and test the full redirect map on staging | Post-launch is too late to discover it is wrong |
| 9 | Cut over, then verify for a fortnight | Most migration damage is found in week two |
Media and in-content image paths
Media quietly breaks more pages than any other step, because the files copy successfully while the references to them do not.
Joomla stores uploads in /images/ with whatever structure you created; WordPress stores them in /wp-content/uploads/ by year and month and generates resized variants. An importer typically copies the files and registers them in the media library, but article bodies still point at the old path.
<!-- What is in your Joomla article body -->
<img src="/images/services/consulting-team.jpg" alt="Our team">
<!-- What the new site needs -->
<img src="/wp-content/uploads/2026/03/consulting-team.jpg" alt="Our team">Two workable approaches. The tidier one is to run a search-and-replace across post content after import, mapping old paths to new. The pragmatic one, particularly on large sites, is to leave /images/ in place on the server so the original paths keep resolving, and only migrate references gradually. The second is inelegant and it works, but document it — a future developer will find an unexplained /images/ directory and be tempted to delete it.
Whichever you choose, check three categories specifically: article intro images stored in Joomla’s own image fields rather than the body, images referenced with absolute URLs including the domain, and images inside custom field values.
Post-migration verification
Launch day starts the verification period; it does not end the project. Work through this within 48 hours.
- Crawl the new site with any site crawler and check for 404s, redirect chains, missing titles and missing meta descriptions.
- Crawl your old URL list as a separate exercise, feeding the spreadsheet’s old-URL column into the crawler. Every one should return a single 301 to a live 200 page. This catches what a crawl of the new site cannot.
- Submit the new XML sitemap in Search Console and keep the old one accessible for a while — search engines use it to discover the URLs that now redirect.
- Check internal links in article bodies. Hardcoded absolute links to old URLs are extremely common and only some importers rewrite them.
- Verify images render on a sample of pages, particularly older articles where the path convention may have differed.
- Test every form end to end, including that the notification email arrives and is not in spam.
- Confirm the site is no longer blocked from indexing. A staging
noindexcarried into production is the single most common catastrophic migration error, and it is silent.
Keep the Joomla installation and its database archived for at least twelve months, offline and off the public web. You will need it — for content someone notices is missing, for a form submission history, for a configuration detail nobody documented. Take it off the server so it is not an unpatched Joomla sitting on the internet, but do not throw it away.
What always gets missed
The same handful of items are forgotten on nearly every migration, in roughly this order of frequency.
- The
noindexfrom staging. Weeks of traffic loss before anyone notices, and it recovers slowly. - Email configuration. The new site sends from a different address or a different mailer, forms stop delivering, and nobody finds out until a customer complains.
- Analytics and tag manager. Migrated templates rarely carry the tracking code, and the gap in the data is permanent.
- Trailing slash consistency. WordPress adds trailing slashes; Joomla often did not. Serving both is a duplicate content problem — pick one and redirect the other.
- Case sensitivity. Joomla aliases and WordPress slugs handle case differently, and a mixed-case old URL may 404 on the new site.
- PDFs and downloadable files. They live outside the CMS content, are missed by content importers, and are frequently linked from elsewhere.
- The
robots.txtand any custom rules in it. - Structured data. Whatever your Joomla template emitted, the new theme emits something different or nothing.
- Feed URLs. Anyone subscribed to a Joomla feed URL disappears silently unless it redirects.
What to expect from search traffic
Be realistic with whoever is paying for this. Even a technically clean migration usually produces a dip, because search engines have to recrawl, follow redirects and reassess the site. Recovery is typically measured in weeks rather than days, and it depends heavily on site size and crawl frequency.
What separates a temporary dip from a permanent loss is almost entirely the redirect map. A migration with complete, correct, single-hop 301s and unchanged content generally recovers. A migration where a third of the URLs 404 does not recover, because there is nothing to recover to — the value was attached to pages that no longer exist.
Content changes made during migration confound this badly. Rewrite pages, consolidate sections and change the CMS at once and you will never know which change caused what. Migrate the content as-is, verify recovery, then make editorial changes as a separate exercise.
Frequently asked questions
Will migrating from Joomla to WordPress improve my SEO?
No, and expecting it to is the most common false premise behind these projects. Both platforms output clean, crawlable HTML and both can be configured well or badly. What determines rankings is content quality, site structure and links — all of which you carry with you, provided the redirects are right.
How long does a Joomla to WordPress migration take?
For a small brochure site with clean content, a few days including verification. For a mid-sized site with several extensions, forms and a real URL history, several weeks. For a complex site with ACL, multilingual content and custom components, months — and that profile is where you should seriously reconsider whether migrating is the right decision.
Can I migrate my Joomla extensions to WordPress?
No. Extensions are platform-specific code and none of them transfer. You need to find a WordPress equivalent for each one, configure it, and re-enter or import any data it held — which for something like a directory or events component is usually a bespoke scripting job.
What happens to my URLs?
They change unless you deliberately configure WordPress permalinks to match. Choosing a permalink structure that mirrors your existing Joomla URLs before importing anything is the single cheapest thing you can do to protect your search traffic, because URLs that do not change need no redirect at all.
Should I keep the Joomla site running during the transition?
Yes — build WordPress on a staging URL with indexing blocked, and keep Joomla live and serving until you cut over. Never run both publicly on the same content, because you create duplicate content competing with itself. After the cutover, archive Joomla offline rather than deleting it.
Do user passwords migrate?
Usually not, because the two platforms hash passwords differently. Plan a password reset for all users as part of launch, communicate it in advance, and check that your reset emails are actually being delivered before you send several hundred of them.
Is it worth migrating from Joomla 3 rather than upgrading to Joomla 5?
Price both before deciding, because people frequently assume the cross-platform move is simpler and it is usually the opposite. Joomla 3 to 5 keeps your URLs, your content structure and your team’s knowledge, and the extension replacement problem exists either way. The cross-platform migration is the right answer when the reason is maintainability or supplier availability, not when it is version fatigue.