Joomla → WordPress
Analyze and move supported Joomla content into a prepared WordPress site through explicit mapping, a dry run, validation, and controlled cutover. Joomla and K2 have stable app connectors, while every installed extension and destination feature still needs its own coverage decision.
Self-service migration path
Source and target connectors are available. joomla: Available. wordpress: Available. Review system status and directions. Available migration objects and capabilities depend on the selected source and target systems.
Create an account, connect a staging destination, and let the app analyze the supported scope for this direction.
No credit card required to analyze the migration and run a free sample.
Scope
The app confirms available entities after connection. Final coverage depends on source access, downloadable assets, and the destination model you prepare.
Before you connect
Use a staging destination and the least-privilege access supported by each platform. Do not send credentials through a public form.
Provide the staging-safe Joomla URL and approved API token or compatible Migranetix Bridge credentials. Required articles, users, fields, categories, tags, comments, menus, languages, and metadata must be visible.
Provide the Joomla version, enabled components, plugins and modules, database prefix where relevant, multilingual configuration, menu structure, URL settings, and a list of business-critical extension data.
Provide the staging URL, migration user, and Application Password. Prepare destination post types, taxonomies, fields, SEO storage, multilingual plugin, menus, and Bridge before production loading.
How it works
You control each stage in the app. Optional expert assistance is available for custom data or destination requirements.
Start in the app and select the real source and target.
Authorize read access to Joomla and connect a prepared staging WordPress destination.
Review detected records, available entities, media, URLs, and anything that needs a decision.
Choose where supported Joomla data belongs in the prepared WordPress model.
Move a small set of real records to staging and inspect the result before purchasing the full migration.
Review counts, records, media, links, warnings, and exceptions, then purchase and start the full migration when ready.
Technical detail
Open only the detail you need for planning, mapping, or validation.
This page is synchronized with the stable Joomla capability and WordPress destination snapshot. Both platforms are enabled in both directions, with version-specific Joomla API or Bridge access selected during discovery.
The current catalog exposes Author, Category, Comment, Content, Menu, MenuItem, Tag. Core articles, authors, taxonomy, comments, menus, and menu items are reviewed separately from extension-owned tables and behavior.
Authenticated REST and versioned Bridge adapters support a prepared WordPress content model. Wider custom-type, field, comment, menu, media, and SEO coverage depends on destination configuration.
Standard means the current connectors expose a direct structured path. Review means routing, extensions, language, or destination configuration affect the result. Custom means the Joomla concept has no safe generic WordPress equivalent.
| Joomla source | WordPress target | Status and boundary |
|---|---|---|
| Core articles | Posts, pages, or prepared custom post types | Standard with modeling: article context and destination architecture determine the final type. |
| Introtext and fulltext | Excerpt and post content | Standard with transformation: approved markup is combined without preserving template chrome or plugin output. |
| Authors and created_by values | WordPress users and post authors | Standard with identity review: profiles and authorship can map; credentials and authentication do not transfer automatically. |
| Nested categories and tags | Categories, tags, or custom taxonomies | Standard: parent terms are loaded before children and article relationships. |
| Custom fields | Post meta, ACF, blocks, or plugin fields | Review: field group, type, repeatability, value format, and destination storage must be mapped explicitly. |
| State, featured, access, and language | Status, sticky behavior, visibility, and multilingual fields | Review: Joomla values do not have one universal WordPress equivalent. |
| Aliases and menu-dependent routes | Permalinks and redirect rules | Review: SEF paths and Itemid context require a crawl-backed URL map rather than alias-only conversion. |
| Menus and menu items | WordPress menus and menu items | Standard with route review: hierarchy and labels can map after destination links and object IDs exist. |
| Images, documents, and media paths | WordPress media and rewritten references | Review: files must be discoverable, downloadable, accepted, uploaded, and relinked. |
| Comments | WordPress comments | Review: the app exposes a comments entity, but real Joomla sites commonly store discussion data in extensions that need specific extraction. |
| Multilingual associations | Configured WordPress multilingual model | Review: language tags, associations, menus, URLs, fallbacks, and destination plugin behavior must be validated together. |
| Components, modules, plugins, templates, and positions | Plugins, blocks, theme templates, or custom code | Rebuild/custom: application behavior and presentation do not transfer as article records. |
The approved rules distinguish core article data from routing and extension behavior while preserving source identity for validation and reruns.
| Joomla value | Migration rule | WordPress result |
|---|---|---|
| Article ID and alias | Preserve source identity and normalize the approved destination slug | Stable ID map, post slug, and rerun lookup |
| Title, introtext, and fulltext | Map introtext to excerpt and combine approved body markup without template output | Post title, excerpt, and content |
| Category ID, path, and parent | Create terms in hierarchy order and resolve destination IDs | Category or custom-taxonomy relationship |
| Tag IDs | Normalize, deduplicate, create, and resolve after taxonomy loading | WordPress tag relationships |
| created_by and created_by_alias | Match an approved user or apply the documented guest-author fallback | WordPress author assignment |
| State, access level, featured, and language | Translate through the approved editorial and multilingual matrix | Status, visibility, sticky behavior, and language relationship |
| Menu route, Itemid, and article alias | Crawl the resolved public URL and pair it with the final destination | Permalink plus one-to-one redirect requirement |
| metadesc, metakey, and metadata JSON | Extract supported values and map only approved SEO fields | Destination SEO metadata or documented exclusion |
A Joomla site can look article-driven while important records actually live in component-specific tables and routes. Discovery must identify ownership before estimating portability.
Count articles by category, state, access, language, author, field group, tag, media use, and menu exposure.
Treat K2 as a separate stable connector with its own mapping, then list EasyBlog, Zoo, ecommerce, directory, membership, comments, forms, contacts, and custom components with their business-critical records.
Approve post types, taxonomies, fields, author policy, multilingual storage, status translation, SEO plugin, and handling for archived or unsupported records.
Create users, terms, media, and reusable records before articles, comments, associations, and menus resolve destination IDs.
Joomla SEF URLs can depend on menu items, category paths, language prefixes, router behavior, and extensions. The live crawl is part of the migration contract.
Capture canonical URLs, menu aliases, Itemid-dependent paths, category routes, language prefixes, pagination, feeds, and priority inbound links.
Define final post-type, taxonomy, language, collision, and trailing-slash behavior before generating redirects.
Translate supported article metadata into the selected WordPress SEO storage and validate template output, canonicals, Open Graph values, and sitemap inclusion.
Verify one-to-one destinations, chains, loops, query handling, internal links, media references, menus, and high-value landing pages before and after launch.
A completed importer is only one signal. Acceptance compares the approved source baseline with loaded records, resolved relationships, rendered pages, and URL behavior.
Compare source, extracted, transformed, loaded, skipped, failed, published, archived, and multilingual totals by type, category, language, and extension.
Check long articles, custom fields, nested categories, tags, guest authors, access levels, featured content, multilingual associations, comments, and media-heavy pages.
Confirm authors, term hierarchy, menus, menu items, comment parentage, translated records, source-to-target IDs, and repeatable reruns.
Validate rendering, assets, internal links, metadata, canonicals, redirects, sitemap coverage, analytics, and documented exceptions through stabilization.
Before purchase
The free sample migration creates a limited set of records in staging. Check fields, relationships, media, URLs, rendering, and reported exceptions before paying for the full run.
Pricing
Package fit depends on supported record volume and complexity. Analyze the source first, then review the fixed package or dynamic estimate shown for the migration.
Compare migration packagesPlan the move
Compare content modeling, multilingual architecture, extensions, ownership, costs, and migration tradeoffs.
Open guide →Plan core articles, users, taxonomy, fields, media, menus, metadata, URLs, dry runs, and validation.
Open guide →Map K2 items, categories, extra fields, media, authors, comments, and routes through the separate connector.
Open guide →Build crawl-backed URL mapping, redirects, metadata checks, and launch monitoring into scope.
Open guide →Clear answers
Yes. Each article group is routed to an approved post, page, or custom post type based on destination architecture rather than its menu placement alone.
K2 has a separate stable app connector, but it still needs field and relationship mapping into WordPress. EasyBlog, Zoo, and other components require source discovery, transformation rules, validation, and separate scope.
Menu hierarchy can be mapped, but Joomla URLs may depend on Itemid, category paths, language, and router behavior. Final WordPress links and redirects come from a crawl-backed URL map.
Yes when their types, groups, repeatability, values, and destination fields are inventoried and mapped. Complex or plugin-rendered fields can require transformation.
Authors and approved profiles can map. Password hashes, access levels, roles, SSO, and authentication behavior require compatibility review and are not assumed.
Yes when language tags and associations are accessible, but the WordPress multilingual plugin, translated slugs, menus, fallbacks, and publishing rules must be prepared and tested.
No. Their content dependencies are reviewed, but layouts, positions, forms, integrations, and application behavior require WordPress-native implementation.
Reconcile records by category, state, language, and source owner; inspect complex samples; verify relationships; crawl routes; test redirects and metadata; and document exceptions.
Next step
Create an account, select Joomla and WordPress, and use the app to analyze supported scope, mapping, and validation requirements.
