Typo3 → WordPress
Translate TYPO3 page-tree and content-element records into a prepared WordPress model with version-aware Bridge extraction, explicit element transformations, file-reference handling, multilingual rules, and URL validation.
Self-service migration path
Source and target connectors are available. typo3: 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 non-production TYPO3 instance or approved clone, database access for the compatible Bridge, version details, and credentials limited to the migration window.
Provide page tree, site configuration, languages, workspaces, tt_content types, backend layouts, FAL storages, extensions, redirects, and custom-table ownership.
Prepare post types, blocks/fields, taxonomies, users, media, multilingual and SEO plugins, permalinks, and Bridge/Application Password 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 Typo3 and connect a prepared staging WordPress destination.
Review detected records, available entities, media, URLs, and anything that needs a decision.
Choose where supported Typo3 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.
TYPO3 is stable and source-only in the current platform registry, with Bridge paths covering legacy and modern version families. The app repository includes integration coverage and a dedicated TYPO3-to-WordPress E2E scenario across multiple source versions..
The current app configures content, users, categories, and file references through version-aware Bridge adapters, including TYPO3 4.5, 6.x, 7, 8–11, and 12+ paths.
Records load into an approved WordPress content model after page-tree, element-type, language, media, and URL rules are defined.
Standard refers to configured Bridge entities. TYPO3 element types, extensions, localization, and page rendering still require version-specific rules.
| TYPO3 source | WordPress target | Status and boundary |
|---|---|---|
| Page-tree/content hierarchy | WordPress pages, parents, or custom routing | Standard with modeling: pid and page context become approved destination hierarchy. |
| tt_content records | Blocks, post content, fields, or child records | Review: each CType needs a transformation and rendering decision. |
| Backend users used as authors | WordPress authors | Standard with identity review: preserve attribution without backend credentials. |
| Categories and relations | Categories or custom taxonomies | Standard: hierarchy and relationships load before dependent content. |
| FAL files and references | WordPress media and attachment references | Review: pre-FAL and FAL versions have different storage and relation models. |
| Hidden, deleted, start/end time, and workspace state | WordPress status and scheduling | Review: visibility and version rules require an approved state matrix. |
| Localization overlays and site languages | Configured multilingual model | Review: language identity, overlays, fallbacks, slugs, and relationships must be rebuilt. |
| Aliases, slugs, speaking URLs, and redirects | Permalinks and redirect rules | Review: the live crawl and route configuration form the URL contract. |
| News and extension-owned records | Posts, custom types, or plugin records | Custom: table schemas and relations need extension-specific extraction. |
| FlexForms, IRRE, containers, and custom elements | Blocks, repeaters, fields, or child records | Custom: nested configuration and rendering cannot be flattened generically. |
| TypoScript, Fluid, plugins, forms, search, and permissions | Theme, templates, plugins, and integrations | Rebuild: behavior and presentation do not migrate as content rows. |
Mapping is version-aware and preserves page context, content-element order, file references, and language identity.
| TYPO3 value | Migration rule | WordPress result |
|---|---|---|
| uid and pid | Preserve source ID and resolve parent context | Stable ID map and hierarchy |
| CType and colPos | Route through the approved element transformation matrix | Block, field, body fragment, or documented exclusion |
| header and bodytext | Normalize RTE markup and combine according to page order | Title, content, excerpt, or block fields |
| cruser_id | Match an approved author identity | WordPress authorship |
| sys_category relation | Load terms first and resolve IDs | Taxonomy relationship |
| sys_file_reference | Resolve storage, metadata, usage, and destination media ID | Media attachment and rewritten reference |
| language/overlay fields | Resolve translation group and fallback | Multilingual destination relationship |
| slug/route/public URL | Select final permalink and URL-map entry | Destination URL plus redirect requirement |
TYPO3 pages are containers for ordered content elements, not direct equivalents of one WordPress body field.
Count standard, custom, extension, plugin, container, FlexForm, and nested content elements by page and language.
Decide whether elements become Gutenberg blocks, ACF fields, reusable components, child records, or sanitized body fragments.
Retain page parentage, column, sorting, language, visibility, and stable source IDs during transformation.
Assign news, search, forms, listings, frontend users, permissions, and integrations to dedicated migration or rebuild work.
File storage changed materially across TYPO3 versions, so filename-only extraction is unsafe.
Identify pre-FAL paths, FAL storage records, file references, metadata overlays, processed files, and external storages.
Connect each file reference to its page/content owner, title, description, alt text, crop, link, and language context.
Download the approved original, validate it, upload to WordPress, and replace body, field, and featured references.
Record inaccessible storage, broken references, derivatives without originals, duplicates, and rejected formats.
Database reconciliation must be paired with route and rendering checks across languages.
Compare source, extracted, transformed, loaded, skipped, failed, visible, and hidden totals by CType and locale.
Review mixed columns, custom elements, nested content, files, links, categories, translations, scheduled visibility, and extension data.
Test legacy speaking URLs, language prefixes, aliases, redirects, canonicals, hreflang, sitemap entries, and internal links.
Validate source-to-target IDs, corrected exceptions, delta behavior, cutover checks, and production 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 version-aware Bridge access, page assembly, FAL, languages, and extensions.
Open guide →Estimate version, element, FAL, language, extension, route, and destination complexity.
Open guide →Plan discovery, mapping, rehearsals, delta cutover, launch, and stabilization.
Open guide →Review WordPress destination modeling, users, taxonomies, media, SEO, and custom fields.
Open guide →Clear answers
The current app has version-aware Bridge paths from TYPO3 4.5 through modern 12+ families. The exact connector is confirmed against the source instance.
They can, but only after each CType is mapped. Other elements may become fields, child records, body fragments, custom blocks, or exclusions.
Yes when storage and file-reference records are accessible. Pre-FAL and FAL sources require different resolution rules.
Yes, with explicit overlay, language, fallback, translated URL, and destination plugin rules.
Extension-owned content can be scoped after schema review; extension code and behavior require WordPress-native implementation.
No. Templates, configuration, plugins, forms, search, and sitepackage behavior require redevelopment.
Crawl rendered routes, map destination permalinks, prepare redirects, rewrite links, and validate language-specific SEO signals.
Next step
Create an account, connect the systems, and analyze the supported scope before purchasing the full migration.
