Joomla to WordPress Migration: What Transfers, What Does Not, and the Redirects

Content migrates well. Articles, sections, categories, tags, and media move across with an importer in an afternoon. What does not migrate is everything that made your Joomla site work as a site — extensions, module positions, template overrides, and above all your URL structure. Plan for that half and the migration is routine.

The failure people describe afterwards is rarely lost content. It is a site that launched with all its articles present and every inbound link pointing at a 404, because Joomla and WordPress build URLs from entirely different rules and nobody mapped one to the other. That is a solvable problem and it is much easier solved before launch than after.

Table of contents

• Before you touch anything
• Running the import
• The redirect map is the whole job
• Replacing the extensions
• Launch sequence
• Deciding whether it is worth doing
• How this fits the rest of the stack
• FAQ

Before you touch anything

1. Back up Joomla completely — files and database. You will need the database live during the import, and you want the ability to go back.
2. Export your current URL list. Crawl the live Joomla site with any site crawler and save every indexed URL. This is the input for your redirect map and it is much harder to reconstruct after the fact.
3. Note your traffic sources. Which pages actually receive visits, from search and from referrals. Not every URL deserves equal effort; the top hundred usually carry most of the value.
4. Inventory your extensions. List everything doing real work — forms, galleries, e-commerce, memberships, multilingual — and find the WordPress equivalent for each before migrating, not after.
5. Record your Joomla database credentials. The importer asks for them.

Step two is the one people skip and regret. Once Joomla is switched off, reconstructing the old URL structure means reading a database dump and reverse-engineering the routing rules. Thirty minutes with a crawler beforehand saves a very tedious day.

Running the import

The standard route is a dedicated importer plugin that reads directly from the Joomla database. Set up the WordPress site first, then import into it.

1. Install WordPress at a staging location — a subdomain or a local environment. Do not migrate onto the live domain until the result is verified.
2. Install the Joomla importer plugin and open it under Tools, then Import.
3. Enter the Joomla database connection details: host, database name, user, password, and the table prefix. The prefix is the field people get wrong, and it is in Joomla’s configuration.php.
4. Run the connection test. It tells you how many articles, categories, and media items it can see, which is a useful sanity check before committing.
5. Choose what to import — content, media, categories — and run it. Large sites may need several passes; the importers are built to resume.
6. Import the media separately if the plugin offers it. Images referenced by absolute URL in article bodies need rewriting to the new media library paths.

What comes across reliably: articles as posts or pages, sections and categories as WordPress categories, tags, images and media, and author attribution where the users exist in both.

What does not come across: extensions and their data, module positions, template design, menu structures, custom fields from third-party extensions, and any URL structure.

The redirect map is the whole job

Joomla URLs frequently look like /index.php?option=com_content&view=article&id=42 or, with SEF enabled, /42-article-title or /section/category/42-article-title. WordPress defaults to /article-title/. Nothing bridges those automatically.

Without redirects, every inbound link, every bookmark, and every search result points at a page that no longer exists. Search engines drop the old URLs and the new ones start from nothing, which is why migrations get blamed for traffic losses that were really redirect losses.

Build the map from the crawl you took in step two:

/2-uncategorised/42-how-to-fix-it   ->  /how-to-fix-it/
/index.php?option=com_content&id=42 ->  /how-to-fix-it/
/component/content/article/42       ->  /how-to-fix-it/

Note that one article often had several valid Joomla URLs. All of them need mapping.

Implement with a redirect plugin for a manageable list, or at the server for a large one:

# nginx
rewrite ^/2-uncategorised/42-how-to-fix-it/?$ /how-to-fix-it/ permanent;

# Apache
Redirect 301 /2-uncategorised/42-how-to-fix-it /how-to-fix-it/

Use 301, not 302. A 301 is permanent and passes ranking signals; a 302 tells search engines the old URL is still the canonical one, which is precisely the opposite of what you want.

Server-level redirects are faster and do not load WordPress to serve a redirect. A plugin is easier to manage. On a site with a few hundred URLs, the plugin is fine; at several thousand, move them into the server config.

Replacing the extensions

This is where the actual work is, and it varies enormously by site.

• Contact forms — straightforward. Any WordPress form plugin covers it. Existing submissions do not migrate.
• Galleries — straightforward. The images migrate; the gallery configuration does not.
• E-commerce — the hardest. Products, orders, and customers need a purpose-built migration, and order history in particular is rarely worth the effort of moving. Consider keeping the old system read-only for records.
• Membership and user accounts — passwords are hashed differently between platforms, so users will need to reset. Plan the communication rather than letting people discover it.
• Multilingual — Joomla has this in core; WordPress needs a plugin. This changes the URL structure again, so factor it into the redirect map.
• Custom fields — third-party field extensions store data in their own tables. Migrating those is bespoke work.

Decide honestly which extensions genuinely need replacing. Migrations are a natural moment to drop things nobody has used in three years, and every one you drop is work you do not do and a plugin you do not maintain.

Launch sequence

1. Verify the staging site fully: content present, images loading, internal links working, forms submitting, search functioning.
2. Load the redirect map on staging and test a sample of old URLs against it.
3. Take a final content export from Joomla if it has changed since the first import, and re-import the delta.
4. Switch the DNS or move WordPress onto the live domain. Lower the DNS TTL a day or two beforehand so the cutover is quick.
5. Verify HTTPS on the new site immediately — a certificate that does not cover the domain is the fastest way to make a good migration look like a disaster.
6. Submit a new sitemap to search engines and keep the old URL list for monitoring.
7. Watch 404 logs for a fortnight. Every 404 with real traffic is a redirect you missed.

That last step is the one that catches what the crawl did not: URLs nobody linked internally but that still receive external traffic. Two weeks of watching the 404 log finds them for free.

Keep the Joomla database backup for months. Not the running site — the backup. Something will turn out to be missing, and having the source available makes it a lookup rather than a loss.

Deciding whether it is worth doing

Migration is real work and worth being honest about the reasons.

Good reasons: your Joomla version is out of support and upgrading is as much work as migrating; the extensions you depend on are abandoned; you cannot find anyone to maintain it; your team already knows WordPress; you need a specific WordPress-only capability.

Weaker reasons: WordPress is more popular; the site feels dated. A redesign is a redesign, and you can do one on either platform. Combining a redesign with a platform migration doubles the variables and makes any post-launch problem twice as hard to attribute.

If you do both, do them in sequence. Migrate first with the content and structure intact, confirm the redirects hold and traffic is stable, then redesign. Slower, and far easier to diagnose when something moves in the wrong direction.

How this fits the rest of the stack

The awkward stretch of a migration is the middle: two databases, a pile of media files, and a redirect map to load, usually through an SFTP client and a separate SQL tool. Managed WordPress on RunxBuild puts both in the dashboard — a file manager that browses, uploads, unzips, and downloads, and a database browser for tables, rows, SQL, export, and import — which makes moving a media archive or checking an imported table a browser action. Plans start at $3 a month. WordPress files on RunxBuild and WordPress database on RunxBuild cover both tools, and the RunxBuild hosting calculator prices the site, storage, and bandwidth separately so a staging copy alongside production is a visible number.

Useful related references:

• Squarespace vs WordPress: The Question Behind the Question
• WordPress Maintenance Services: What You Are Actually Paying For
• WP-CLI: The Commands That Make WordPress Administration Bearable
• Redirects on RunxBuild

FAQ

What transfers from Joomla to WordPress?

Articles become posts or pages, sections and categories become WordPress categories, plus tags, media, and author attribution where users exist in both. Extensions and their data, module positions, template design, menu structures, and the URL structure do not transfer.

How do I migrate Joomla content to WordPress?

Install WordPress at a staging location, add a Joomla importer plugin, and run it from Tools then Import. It reads directly from your Joomla database, so you need the host, database name, user, password, and table prefix from Joomla’s configuration.php.

Will I lose search traffic migrating from Joomla?

Only if you skip the redirects. Joomla and WordPress build URLs from completely different rules, so every old URL needs a 301 to its new location. Crawl the live Joomla site before migrating to capture the URL list — reconstructing it afterwards is far harder.

What happens to my Joomla user accounts?

The accounts can migrate but the passwords cannot, because the two platforms hash them differently. Users will need to reset their passwords on first login. Plan that communication in advance rather than letting people discover it at the login screen.

Should I redesign at the same time as migrating?

Better not to. Doing both at once doubles the variables, so any post-launch traffic change is hard to attribute. Migrate first with content and structure intact, confirm the redirects hold and traffic is stable, then redesign as a separate project.