MODX → WordPress
Translate MODX Resources and Template Variables into a prepared WordPress model with version-aware Bridge extraction while separating portable values from Chunks, Snippets, Templates, parser tags, Extras, contexts, and application behavior.
Self-service migration path
Source and target connectors are available. modx: 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 a safe clone or staging instance, database access for the compatible Bridge, MODX version, table prefix, contexts, media sources, and temporary credentials.
List Resource templates, Template Variables, MIGX, Chunks, Snippets, plugins, comment systems, friendly URL rules, contexts, frontend users, and custom xPDO packages.
Prepare post types, taxonomies, fields/blocks, users, comments, media, menus, multilingual and SEO plugins, permalinks, and authenticated access.
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 MODX and connect a prepared staging WordPress destination.
Review detected records, available entities, media, URLs, and anything that needs a decision.
Choose where supported MODX 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.
MODX is stable and enabled in both directions in the site snapshot. The current app has version-aware Evolution, Revolution 2, and Revolution 3 Bridge paths plus a dedicated MODX-to-WordPress E2E scenario.
Configured entities include users, Resource Groups, Resources/Documents, comments, media files, menus, and menu items. Resource Template Variables are extracted with content where supported.
Approved resources load into prepared post types, fields, taxonomy, media, comments, and menus after parser and URL dependencies are classified.
Standard covers configured Bridge entities. Template Variables and parser-driven output need explicit transformation rather than rendered-page copying.
| MODX source | WordPress target | Status and boundary |
|---|---|---|
| Resources/Documents | Pages, posts, or custom post types | Standard with modeling: template, content type, and context determine destination routing. |
| Parent hierarchy and containers | Page parents or taxonomy hierarchy | Standard: parents load before children and menu references. |
| Template Variables | Core fields, post meta, ACF, taxonomy, or blocks | Review: map type, value format, defaults, media source, and repeatability. |
| Users used as authors | WordPress authors | Standard with identity review: preserve attribution without Manager passwords. |
| Resource Groups | Taxonomy, access rules, or archive labels | Review: groups can represent organization or permissions and need semantic mapping. |
| Comments | WordPress comments | Review: actual records often belong to an Extra and require schema confirmation. |
| Media files and media-source TVs | WordPress media | Review: resolve paths, sources, metadata, and every usage before rewriting. |
| Menus, Wayfinder/pdoMenu inputs, and menu titles | WordPress menus and items | Review: rebuild from Resource hierarchy and approved destination IDs. |
| Aliases, contexts, and friendly URLs | Permalinks and redirects | Review: crawl rendered routes and account for context-specific bases. |
| Symlinks, weblinks, and static resources | Links, redirects, pages, or files | Custom/review: each Resource class requires a destination rule. |
| Templates, Chunks, Snippets, plugins, and parser tags | Theme, blocks, plugins, or code | Rebuild: MODX rendering and PHP behavior do not transfer as Resource content. |
The mapping contract distinguishes Resource fields, Template Variables, relationships, and parser behavior.
| MODX value | Migration rule | WordPress result |
|---|---|---|
| Resource id and parent | Preserve ID and resolve hierarchy | Stable destination ID and parent |
| pagetitle, longtitle, introtext, content | Map approved editorial fields and sanitize parser remnants | Title, excerpt, body, or block fields |
| alias and context | Build final path through approved routing rules | Slug and redirect-map entry |
| template ID | Route through the content-model matrix | Post type and field schema |
| Template Variable name/type/value | Transform according to approved field rule | Post meta, ACF, taxonomy, block, or relation |
| createdby | Match an approved author identity | WordPress authorship |
| menuindex, menutitle, hidemenu | Rebuild after destination objects exist | Menu-item label, order, and visibility |
| media-source path | Resolve, download, validate, upload, and rewrite | WordPress media reference |
A MODX Resource combines core fields with arbitrary TVs and can behave as a page, container, link, file, or application entry.
Count Resources, types, parents, templates, contexts, states, languages, and URL patterns.
Capture input/output type, defaults, bindings, media source, values, MIGX structures, and template assignments.
Approve post types, taxonomy, fields, blocks, authors, relationships, and fallbacks before loading.
Route symlinks, weblinks, static Resources, containers, protected content, and application records individually.
Resource content can contain tags that invoke Templates, Chunks, Snippets, settings, placeholders, links, and output filters.
Find Resource tags, TV tags, Chunks, Snippets, placeholders, link tags, settings, uncached calls, and nested expressions.
Convert approved links, media, and static values while rejecting or documenting executable behavior.
Replace listings, forms, search, personalization, menus, integrations, and custom Extras in WordPress.
Compare representative MODX pages with destination output to detect missing snippet or template dependencies.
MODX URL behavior can depend on aliases, parent Resources, contexts, routing Extras, and server configuration.
Compare source, extracted, transformed, loaded, skipped, failed, published, and hidden totals.
Check TVs, MIGX, links, media, authors, comments, menu order, symlinks, and multi-context content.
Test context bases, friendly URLs, aliases, redirects, canonicals, sitemap entries, and internal links.
Validate source IDs, relationships, reruns, delta behavior, corrected exceptions, and launch monitoring.
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
Review destination content types, users, taxonomy, media, SEO, and access.
Open guide →Understand the self-service migration scope and delivery boundaries.
Open guide →See package limits, exclusions, and fixed-scope factors.
Open guide →Connect access, mapping, dry runs, cutover, and stabilization to delivery time.
Open guide →Clear answers
The current app has Bridge paths for MODX Evolution, Revolution 2, and Revolution 3. The exact database schema is verified before scope.
Yes when their definitions and values are accessible and each TV is mapped to a compatible WordPress field, taxonomy, block, or relationship.
It requires custom review because nested MIGX structures are not generic scalar Template Variables.
No. Stored content is cleaned or transformed, while executable templates, snippets, plugins, and parser behavior require redevelopment.
Supported records can migrate after their source tables, relationships, and destination model are confirmed.
Author identities can map; Manager credentials and permissions do not transfer automatically.
Crawl every context, approve final permalinks, generate redirects, rewrite internal links, and validate canonical behavior.
Next step
Create an account, connect the systems, and analyze the supported scope before purchasing the full migration.
