Starting constraint
TYPO3 had been the corporate CMS for over a decade. Editors knew the keyboard. The site was plugged into legal review, into translations, and into a brand book that pre-dated most current employees.
The migration was not a redesign. It had to keep visual identity, keep every URL, keep the multilingual matrix, and keep the editorial calendar moving while the platform changed underneath.
Content model audit
The first month was spent reading the TYPO3 page tree, not writing code. Each TYPO3 content element had to be classified: native equivalent in WordPress core, candidate for ACF or block pattern, candidate for archival as static content, or candidate for retirement.
The audit produced a one-to-one map. Without that map, a migration becomes a guess.
URL and schema continuity
Every URL was preserved. Where TYPO3 had RealURL or path segments that no longer fit, a 301 redirect map was generated and validated before launch. Multilingual variants stayed at the same paths.
Article and Organization schema migrated with the content. Hreflang continuity was checked per locale before DNS cutover.
Editor onboarding
Editors had a Friday training, a Monday parallel publishing day, and a Wednesday cutover. The block editor was localised, the patterns were named in the language editors actually used, and a small custom plugin replaced the three TYPO3 macros that mattered most.
Nobody had to relearn the brand book. The brand book replaced the platform, not the other way around.
Outcome bands
Exact numbers are confidential. The publishable result: editorial throughput improved within the first month, page weight on the corporate template family dropped meaningfully, and search visibility for the German-language head terms held through cutover with no recovery dip.
The reusable lesson: TYPO3 to WordPress is less a code migration and more a content model migration. The team that wins is the team that audits before it builds.