Choosing a system
Moving from WordPress to TYPO3
Switching systems is not an end in itself. When it comes up, there is usually a concrete reason: several languages, several brands, editorial permissions WordPress only covers with plugins. Here is how such a move runs and what it hangs on.
First, the honest question
Switching systems costs money and attention. It is worth it when WordPress fails at a concrete requirement, not because TYPO3 is regarded as more professional.
The typical reasons are always the same. Multilingual content that has become unmanageable on plugins. Several sites that should share their upkeep. Permission structures that need to be finer than roles. Or data structures of your own that no longer fit into posts.
Without a reason like that, our recommendation is usually to stay. We say so even when it argues against our own order book.
What happens first: taking stock
The work starts with a list, not with design. Which pages and posts exist? Which ones are actually opened? Which ones rank? Which plugins are in use, and which of their features genuinely has to come along?
That list delivers three things at once: the scope of the content migration, the basis for the redirect plan, and the opportunity to weed. On most sites that have grown over years, a substantial part falls away: content nobody has opened in years that still has to be maintained.
Transferring content
What goes well: pages and posts with clear fields, media files with their metadata, categories and tags, author assignment.
What means manual work: content from a page builder. It often sits as a nested structure in a single field and has to be translated into real content elements. That is exactly where the effort of a migration is decided, and exactly what cannot be estimated without looking at the data.
What does not come along: plugins. A form plugin, a slider, a booking system: each of those features is solved afresh in TYPO3 rather than transferred. That is not a drawback but the chance to check whether the feature is still needed at all.
The redirect plan
The point where rankings get lost. WordPress and TYPO3 build addresses differently; without a mapping, every existing address runs into nothing.
Four rules we keep to. Every old address gets a target of its own, never a blanket redirect to the home page. Permanent redirects, not temporary ones. No chains: if A points at B and B at C, then A points at C directly. And testing happens before the switch, against the complete list from the inventory.
We carry over the titles, descriptions and structured data of the strong pages rather than inventing them again. There is more on that under TYPO3 relaunch.
What is different afterwards
For editors, daily work changes noticeably. TYPO3 separates pages and content elements more clearly, the backend is larger, and permissions bite more finely. That is a matter of getting used to rather than a hurdle, but it calls for training and not just a handover.
For operations, the rhythm changes. Instead of many small plugin updates there are fewer, plannable updates and a known lifecycle. What that means in terms of maintenance is set out under TYPO3 maintenance.
A realistic order of work
Take stock and weed. Settle the structure and the content elements. Build the new installation. Migrate the content and check it. Create the redirects and test them against the old list. Switch over. Then watch Search Console and the error logs.
The step most often underestimated is the fourth. Touch the content only after the building is done and the project grows by exactly the time that step needs.