The most common reason a TYPO3 to WordPress migration loses content is not that the content disappears. It is that nobody mapped the source correctly before starting. TYPO3 stores content differently from any other CMS: pages as a tree in the pages table, content in discrete elements in tt_content with column assignments, news articles in a separate extension table, and files in a completely separate abstraction layer. A migration that does not read each of these tables explicitly leaves structured data behind.
The Core Architecture Difference
TYPO3 uses a page-tree model where every page is a row in the pages table with a pid field pointing to its parent. Content is not stored in the page row. It is stored in tt_content as separate content element rows, each with a pid matching the page UID and a colPos field indicating which column of the backend layout it belongs to. A single TYPO3 page with three content columns has one row in pages and potentially dozens of rows in tt_content.
WordPress uses a simpler post model. A page or post is a single row in wp_posts with the content stored in the post_content column as block markup (Gutenberg). Structured custom data sits in wp_postmeta via ACF Pro fields. The mapping from TYPO3’s distributed multi-table structure to WordPress’s consolidated model requires reading each table explicitly and assembling the content in the correct order and column assignment.
The Full Content Mapping Reference
| TYPO3 Element | TYPO3 Storage | WordPress Equivalent | Notes |
|---|---|---|---|
| Pages / page tree | pages table (uid/pid hierarchy) | WordPress Pages (post_type=page) | Tree hierarchy preserved |
| Content element: text | tt_content CType=text, bodytext field | Gutenberg Paragraph block | Body text, header preserved |
| Content element: textmedia | tt_content CType=textmedia, bodytext + FAL ref | Gutenberg Image + Text blocks | Media linked via sys_file_reference |
| Content element: image | tt_content CType=image + FAL reference | Gutenberg Image block | Alt text, title from FAL |
| Content element: header | tt_content CType=header, header field | Gutenberg Heading block | Header type (h1-h6) preserved |
| Content element: bullets | tt_content CType=bullets, bodytext as list | Gutenberg List block | Unordered or ordered list |
| Content element: table | tt_content CType=table, bodytext as CSV | Gutenberg Table block | Table structure preserved |
| Custom element (Mask/DCE) | tt_content custom CType + custom flex fields | ACF Pro custom blocks or CPT fields | Per-field explicit mapping |
| tx_news records | tx_news_domain_model_news table | WordPress Posts (post_type=post) | Author, date, categories preserved |
| tx_news categories | tx_news_domain_model_category table | WordPress Post Categories | Hierarchy preserved |
| FAL files | sys_file + sys_file_reference tables | WordPress Media Library (wp_posts type=attachment) | Filenames, alt text, titles |
| Frontend users | fe_users + fe_groups tables | WordPress Users + Roles (wp_users) | Role mapping explicit |
| TYPO3 categories | sys_category + sys_category_record_mm tables | WordPress Taxonomies | Hierarchy preserved |
| Powermail form data | tx_powermail_domain_model_mail + _answer tables | Gravity Forms / WPForms + archived data | Submission history archived |
| EXT:form form data | tx_form_formdb + answer tables | Gravity Forms / WPForms + archived data | Submission history archived |
| TYPO3 Forum extension | tx_mmforum or forum extension tables | wpForo 360° AI | Topics, replies, authors preserved |
| URL slugs / segments | pages.slug field (v9+) or RealURL config | WordPress post slug + Redirection 301s | Every URL preserved or redirected |
| SEO metadata (EXT:seo) | pages.seo_title, pages.description + og fields | Yoast SEO post meta (_yoast_wpseo_*) | Title, description, OG data |
| Backend layouts / columns | TypoScript backend_layout config + colPos | Gutenberg columns / ACF Flexible Content | Layout rebuilt in WP theme |
| TypoScript configuration | TypoScript in site package extension | Custom WordPress PHP theme | Not portable, rebuilt from scratch |
| Fluid templates (.html) | Site package /Resources/Private/Templates/ | Custom WordPress PHP theme templates | Not portable, rebuilt from scratch |
Pages and the Page Tree
Every page in TYPO3 is a row in the pages table. The uid field is the page identifier. The pid field is the parent page UID. The slug field (added in TYPO3 v9) is the URL segment for that page. The tree structure of the entire site is encoded in these three fields across potentially thousands of rows.
A proper migration reads the pages table recursively and recreates the page hierarchy as WordPress pages with correct parent assignments. The slug field of each page is used to set the WordPress post slug, preserving URLs. Where the URL structure must change, a 301 redirect is created before the domain switch. Page properties including SEO title, meta description, and Open Graph fields from the pages table or EXT:seo extension are written to Yoast SEO post meta for every page.
tt_content Elements to Gutenberg Blocks
Every content element in TYPO3 is a row in the tt_content table. The CType field identifies the type of content element (text, textmedia, image, header, bullets, table, list). The bodytext field stores the main content. The colPos field indicates the backend layout column. The sorting field determines the order of elements on a page.
A proper migration reads all tt_content rows for each page, ordered by sorting, and creates corresponding Gutenberg blocks in the WordPress post content. A text element becomes a paragraph block. A textmedia element becomes a combination of image and text blocks. A header element becomes a heading block. Custom content elements built with extensions like Mask or DCE have their custom field data mapped to ACF Pro fields in the corresponding WordPress custom post type or block.
tx_news Records to WordPress Posts
The tx_news extension is one of the most widely used TYPO3 extensions. It stores news articles in the tx_news_domain_model_news table with fields for title, body text (stored as RTE content), author, publication date, and category assignments. News categories are in tx_news_domain_model_category with a hierarchy.
A proper migration reads every row in tx_news_domain_model_news and creates a WordPress post for each one. The publication date, author attribution, and category hierarchy are preserved. Body text stored as TYPO3 RTE HTML is cleaned and converted to Gutenberg block format. Attached images linked via sys_file_reference are imported to the WordPress Media Library and set as the featured image on the corresponding post.
FAL: The File Abstraction Layer
TYPO3 introduced the File Abstraction Layer (FAL) in version 6.2. FAL separates file metadata from file content. Physical files are stored on disk. Their metadata (title, alt text, description, MIME type) is stored in the sys_file table. The relationships between content elements and files are stored in sys_file_reference, linking a tt_content row to a sys_file row with per-reference overrides for alt text and title.
A proper migration reads sys_file and sys_file_reference together, imports the physical files to the WordPress Media Library, preserves the per-file alt text and title from FAL metadata, and updates all content references to point to the new WordPress media URLs. Older TYPO3 sites (pre-6.2) may use direct file references in tt_content fields which require a separate lookup strategy.
Frontend Users to WordPress Users
TYPO3 separates backend users (who administer the CMS) from frontend users (who log in to the website). Frontend users are stored in fe_users with fields for username, email, first name, last name, and a usergroup field referencing fe_groups. Custom profile fields added by extensions are stored in additional columns on fe_users or in separate extension tables.
A proper migration reads fe_users and fe_groups, creates corresponding WordPress user accounts, maps frontend user groups to WordPress roles, and imports any custom profile field values to WordPress user meta. Passwords must be reset on first login since TYPO3 and WordPress use different hashing schemes and passwords cannot be transferred as-is.
TypoScript and Fluid Templates: What Cannot Be Ported
TypoScript is a proprietary configuration language specific to TYPO3. It controls everything from page rendering to menu generation to content element output. There is no equivalent in WordPress and no migration path for TypoScript configurations. Every TypoScript configuration on a TYPO3 site must be understood by a developer who can replicate its effect in a custom WordPress PHP theme.
Fluid templates are the HTML template files that TYPO3 uses for frontend rendering. They use Fluid template syntax with ViewHelpers, variable injection, and partial includes that are specific to the TYPO3 templating engine. These files cannot be ported to WordPress. A proper migration delivers a custom WordPress PHP theme that replicates the visual output of the original TYPO3 site exactly, page type by page type, building the theme logic from the WordPress template hierarchy rather than from the TYPO3 template files.
How gConverter Handles TYPO3 Migrations
gConverter migrates TYPO3 sites by reading the source database directly. Every page in the pages table is migrated with its complete tree structure. Every content element in tt_content is mapped to the corresponding Gutenberg block. Every tx_news record is migrated to a WordPress post. Every FAL file is imported to the WordPress Media Library with alt text and title preserved. Every frontend user is imported with role mapping. Every URL slug is preserved or redirected. The TYPO3 theme is rebuilt as a custom WordPress PHP theme. SEO metadata is transferred to Yoast SEO.
Before any access to your database, we sign a Data Processing Agreement. Credentials are stored in AES-256 encrypted vaults and transferred over TLS 1.3. All client data is permanently deleted within 30 days of delivery.
Read the GDPR and data protection documentation →
For everything about why organizations are moving from TYPO3 to WordPress: Why Businesses Are Moving From TYPO3 to WordPress →
What Clients Say
Went FAR above and beyond to help us work through this project. We are thrilled with the final result and they were professional, great to work with, and responsive every step of the way. Would highly recommend.
Anna P., Wilmington NC – Customer Lobby, January 2026
Very few conversion issues on the first pass, and they cleaned it right. Very Impressive.
Stacy C., Katy TX – Customer Lobby, November 2025
The Bottom Line
A TYPO3 site is not a single-table database. It is a distributed content model spread across the pages tree, tt_content element rows, extension tables like tx_news_domain_model_news, and the FAL file reference system. A migration that does not read all of these tables explicitly does not migrate the site. It migrates a partial version of it, with structured data silently missing and URLs broken.