TYPO3 to WordPress

WordPress hosting for sites migrating from TYPO3.

There is no importer for this one. TYPO3 stores a page as a tree node with a list of content elements attached, and nothing in WordPress corresponds to that until somebody decides what it should become.

Page tree mapped by handRouted URLs preservedFree migration
Migration-tunedRedis object cacheNVMe storageDaily backupsFree SSL24/7 support
What actually moves

A content model that has to be translated.

TYPO3 and WordPress disagree about what a page is. Every decision below has to be made before the first record is transferred, not after.

Pages are trees of elements, not documents

A TYPO3 page is a node with content elements attached to columns. WordPress expects a single body. Each element type needs a destination — a block, a field or a component — chosen up front.

Element types mappedColumns resolved

Routed URLs kept exactly

TYPO3's routing produces paths built from the page tree and its slug configuration. WordPress would generate something different for the same content, changing every address that currently ranks.

RewritesRedirects

Media held by reference, not by path

The File Abstraction Layer stores files once and points at them through reference records. Copying the files alone produces a media library that no page is actually using.

Languages are columns, not sites

TYPO3 keeps translations as language overlays of the same record. WordPress needs a plugin and a structural decision — separate posts, or connected translations — before anything is imported.

Extbase extensions have no counterpart

Custom extensions are application code with their own tables. Nothing imports them; each is a functional gap to be filled by a plugin, a custom post type or a rebuild.

The migration

Map the model, then move the content.

TYPO3 migrations go wrong in the planning, not the transfer. Once the element types and the URL structure are agreed, moving the records is the straightforward part.

  • Page tree and element types mapped to blocks
  • Routing configuration reproduced as redirects
  • FAL references resolved to real files
  • Translation strategy chosen before import
Page tree
Depth reviewed and mapped
310 nodes
Content elements
Types matched to blocks
18 types
FAL references
Resolved to the library
verified
Routing redirects
Paths preserved
in progress
Performance

An enterprise site, without the enterprise stack.

Most TYPO3 installations being moved carry years of extensions and a caching framework nobody still has the documentation for. Leaving that behind is much of the speed gain.

Mapped
page tree and elements
Preserved
routed URLs
NVMe
storage on every plan
MagicWP180 ms
TYPO3 with a cold cache1700 ms
Imported without resolving FAL800 ms

Illustrative comparison of a content page after migration. Your numbers depend on page count and how many element types were mapped.

Configuration

What we change moving from TYPO3

These differ from a standard WordPress site on the same plan, and each follows from a content model that is genuinely more structured than the one it is moving into.

SettingWhat we doWhy
Page tree mappingTree depth and content element types agreed before any record is transferredA TYPO3 page is a node carrying content elements in named columns rather than a document with a body, so without an agreed destination for each element type there is nothing sensible to import into.
URL preservationRouting configuration reproduced with rewrites and redirectsPaths are assembled from the position of a node in the tree and its slug configuration, so letting WordPress generate its own permalinks silently changes every address the site has accumulated authority on.
FAL media referencesReference records resolved to files, then rewritten into the media libraryThe File Abstraction Layer deliberately separates a file from the records that point at it, so moving the files alone produces a full library that no page on the new site actually references.
Translation handlingLanguage overlays converted to a chosen plugin structure before importTYPO3 stores a translation as an overlay row against the original record, and WordPress has no native equivalent, so the choice between separate posts and linked translations determines the shape of the import itself.
Extension replacementsEach Extbase extension matched to a plugin, a custom post type or a rebuild, before launchCustom extensions are application code with their own database tables rather than content, so nothing about them can be imported and each one is missing functionality on day one unless it was planned for.
Plans

Simple, transparent pricing.

Every plan includes free migration, daily backups, SSL and 24/7 support.

MonthlyYearly
Starter
For personal sites, blogs, and portfolios.
$20/mo
Billed $240 yearly · save $60
  • 1 WordPress site
  • 10 GB NVMe disk
  • Free SSL
  • Daily backups
  • One-click deployment
  • Support tickets
Start free trial
Pro★ Most popular
For growing businesses and busy stores.
$80/mo
Billed $960 yearly · save $240
  • 5 WordPress sites
  • 50 GB NVMe disk
  • Free SSL
  • Daily backups
  • One-click deployment
  • Priority support tickets
Start free trial
Enterprise
For agencies and high-traffic platforms.
$250/mo
Billed $3000 yearly · save $600
  • 20 WordPress sites
  • 200 GB NVMe disk
  • Free SSL
  • Daily backups
  • One-click deployment
  • Dedicated support
Start free trial
FAQ

Questions, answered.

Is there a TYPO3 to WordPress importer?
Nothing general enough to rely on. TYPO3 stores pages as tree nodes with attached content elements, and until you decide what each element type becomes in WordPress there is no defined target for an importer to write to.
What happens to my content elements?
Each type is mapped to a destination before the migration starts — usually a block pattern, sometimes a custom post type with fields. That mapping is the migration; transferring the records afterwards is mechanical.
Do TYPO3's routed paths survive the move?
Not if we plan for it. TYPO3 builds paths from the page tree and its slug configuration, so we reproduce those addresses with rewrites rather than accepting whatever WordPress would generate instead.
My images came across but pages show nothing. Why?
That is the File Abstraction Layer. It keeps files separate from the reference records that point at them, so the files can arrive intact while every reference to them is left behind.
How do multilingual TYPO3 sites transfer?
The overlay structure has to be converted to whichever WordPress translation plugin you choose, and that decision comes first because it changes how the records are imported rather than how they are displayed.

Move from TYPO3 with the tree and the URLs intact.

Free migration, a content model mapped by a person, and every routed address preserved.