When to consider moving from WordPress to TYPO3
TYPO3 is worth considering when several brand and country sites need shared management, local editors need access to specific areas, and changes require approval before publication. Its page tree, language management, permissions and configurable workspaces can support that combination.
We try those workflows with the editorial team using their own content. A slow frontend or a long plugin list is not, by itself, a reason to move. If the problem lies in the theme, hosting or a particular plugin, fixing WordPress may cost less. Training, maintenance and future upgrades also belong in the comparison.
Inventory the content, plugins and integrations
We start with what the website does: pages, articles, downloads, forms, accounts, language versions and integrations. Then we examine how it works. Which information lives in custom post types, plugin tables or custom fields? What runs on a schedule?
For sites using Gutenberg, Elementor, WPBakery or ACF, we inspect the stored blocks, layouts and fields. A dynamic Gutenberg block may store just a block marker and its settings; WordPress generates the output when the page is requested. Those features, along with shortcodes, need an implementation in TYPO3. We also inventory SEO plugin metadata and the relationships between translated pages.
Map WordPress content to the new data model
We start with a small trial import: a long article, a nested landing page and a record with downloads and translations. These help us define the TYPO3 content elements and editing fields. Editors can then check whether they can actually maintain their pages in the new backend.
- Articles and categories
- We map titles, authors, publication dates and body copy, along with categories, related articles and search metadata. Drafts and private posts must not become public during import.
- Custom post types and fields
- Locations, products or people become appropriate records in the new system. Field types, required information and relationships determine how editors will maintain and reuse them.
- Blocks and page-builder layouts
- Recurring components are mapped to new content elements. We do not simply copy layout data as HTML. Editors and designers decide which unusual layouts to preserve and which to rebuild.
- Images and downloads
- Files are brought into TYPO3’s media library and linked to the content that uses them. We check alt text, captions and credits, including cases where the same image has different descriptions in different contexts.
- Languages
- Translations are linked to their source pages. Editors decide what visitors should see when a translation is missing and which content deliberately differs between markets.
What a WordPress export can and cannot do
WordPress exports posts, pages, comments, fields and taxonomies in an XML format called WXR. The contents depend on the export filters and whether custom post types allow export. Media entries contain references, not the image or PDF files themselves. Themes, plugin code and data in custom plugin tables need a separate transfer process.
TYPO3’s built-in importer is not a WXR converter: it imports exports from other TYPO3 installations. WordPress data needs mapping to TYPO3’s structures. We inspect the source data before choosing between WXR, an API or a targeted database export.
The import keeps a record of which source item became which TYPO3 record. Subsequent runs update existing content rather than creating duplicates. Missing files, broken relationships and unsupported components go into an error report for resolution before launch.
User accounts, forms and connected systems
An article byline is not a user account with permissions. The author details in WXR do not include login passwords. We plan accounts and roles separately for editors and signed-in visitors, including how they will first access the new site: through existing single sign-on, for example, or a password reset.
For forms, we check validation, recipients, confirmation emails and delivery to the CRM. Shops, bookings and membership features need their own migration scope; a content import does not recreate checkout or payment integrations. Tests use test services or intercepted emails to avoid triggering real bookings or messages.
Make a plan for existing URLs
Before the move, we collect URLs from a site crawl, the sitemap, Search Console and server logs, including images and PDFs. We record search traffic and relevant queries for important landing pages to establish a baseline. Where possible, we schedule a domain change or redesign separately.
Keep unchanged URLs. For changed addresses, use direct server-side 301 or 308 redirects to the equivalent content. Removed pages without a replacement return 404 or 410, rather than sending everyone to the homepage. Update internal links, canonicals, hreflang references and the sitemap. Google generally recommends keeping redirects for at least a year.
Review the replacement site with its editors
After the full test import, we compare records, media and translation links. Automated checks cover links and recurring functions. Editors create and translate content, work through approvals, and test previewing and publishing. We also check mobile layouts, keyboard access and loading times for the main page types.
The test environment has access controls, and we limit or anonymise personal data used for testing. At launch, we explicitly check the public site for any inherited noindex instructions or crawl restrictions that could prevent indexing. The test environment stays protected.
Transfer the final changes and support the launch
The WordPress site stays in use between the test import and launch. We agree either a short editorial freeze or a final sync covering all changes, including new files and deleted content. The launch plan names the people responsible and sets out the criteria for going live.
A complete backup covers the database and files. We rehearse the rollback procedure and plan how to preserve any enquiries received after launch if the old site has to be restored. We then monitor error logs, forms, integrations and search visibility. Rankings may fluctuate temporarily; we investigate unexpected losses page by page against the pre-migration baseline.
Alternatives: Drupal, Neos, Craft and headless CMSs
Drupal, Neos, Craft, Storyblok and Payload can also be candidates for replacing WordPress. A magazine with tailored editing forms has different needs from an international platform or a portal with its own business rules. Our CMS comparison explains those differences.
Our estimate separates data migration, content elements, feature development, SEO changes and training, with maintenance and running costs shown separately. That gives you a basis for comparing migration with further investment in WordPress before commissioning the full project.
Page count alone tells you little about the work involved. Importing 500 articles with the same structure can be simpler than rebuilding 20 bespoke pages with forms and integrations.