TYPO3 Migration Checklist: Your Step-by-Step Pre-Flight Plan

Key takeaways

• Audit your TYPO3 version, extensions, and TypoScript complexity before choosing a migration strategy.
• Map every content type and language setup to the target system. The list CType and multi-language setups need the most care.
• Build a full URL-to-URL redirect map. Preserve SEO metadata before DNS cutover.
• Test at production content scale, not with sample pages. Monitor Search Console and Core Web Vitals for 30 days after launch.
• Choose between staying on TYPO3, going headless, or switching CMS based on content complexity, not just cost.

Updated 15 August 2026: sources added, experience claims checked against our project record, summary added.

A TYPO3 migration checklist has to cover version and extension audits, content and data mapping, redirect and SEO preservation, staging setup, and post-launch monitoring. This guide walks through each phase in order, starting with an assessment of your current installation and ending with the 30-day monitoring window after cutover. Skip a step here and you'll pay for it after you touch production.

Assess Your Current TYPO3 Installation

Before you touch anything, know what you're working with. Sounds obvious, but plenty of teams kick off a TYPO3 migration without knowing which version is actually running in production.

Version and Environment Audit

Start here:

## Check your TYPO3 version
php typo3/sysext/core/bin/typo3 --version

## Or check via the backend: Help > About TYPO3

Document the following:

• TYPO3 version (major and minor -- e.g., TYPO3 v11.5.38 LTS)
• PHP version running on the server
• Database type and version (MySQL, MariaDB, PostgreSQL)
• Web server (Apache, Nginx)
• Composer-based or classic installation -- this matters a lot
• Number of sites/domains in the installation (multi-site setups add complexity)
• Total number of pages and content elements in the page tree

User and Permission Mapping

TYPO3's backend user and group permission system runs deep. Export your be_users and be_groups tables and document:

• How many backend users exist
• What custom permissions are configured
• Which users have admin access
• Any custom TSconfig overrides

If you're migrating to a different CMS, map these roles onto the new system's permission model. If you're upgrading TYPO3 versions instead, some permission settings will need updating along the way.

TypoScript and Configuration Complexity

Run a quick audit of your TypoScript setup:

## Count your TypoScript files
find . -name '*.typoscript' -o -name '*.ts' | wc -l

## Check for setup.txt and constants.txt (legacy format)
find . -name 'setup.txt' -o -name 'constants.txt' | wc -l

Hundreds of TypoScript files with deeply nested settings mean a longer migration, full stop. Installations with 10,000+ lines of TypoScript built up over a decade are not a weekend project.

Define Your Migration Strategy

There are three main types of TYPO3 migrations, and you need to decide which one you're doing before anything else.

Migration Type	When to Choose	Complexity	Typical Timeline
TYPO3 version upgrade (e.g., v10 → v12)	You want to stay on TYPO3	Medium-High	4-12 weeks
TYPO3 to headless CMS (e.g., Contentful, Strapi, Sanity)	You want modern frontend flexibility	High	8-20 weeks
TYPO3 to another traditional CMS (e.g., WordPress, Drupal)	You want a different monolithic CMS	Medium	6-16 weeks
TYPO3 to headless TYPO3 (using EXT:headless)	You want TYPO3 backend with modern frontend	Medium	6-14 weeks

Upgrading Within TYPO3

If you're staying on TYPO3, the official upgrade path means stepping through each LTS version in order. You can't jump from v8 to v12 directly. Well, you can try. Don't.

The recommended path as of 2026:

• v8 LTS → v9 LTS → v10 LTS → v11 LTS → v12 LTS → v13 LTS

TYPO3 v13 LTS was released in late 2024 and is the current long-term support version. TYPO3 v12 LTS will receive security updates until April 2026 through the Extended Long Term Support (ELTS) program.

Migrating Away From TYPO3

If you're moving to a headless setup, look at your frontend framework options first. Our SleepDr migration paired Next.js 15 with Payload CMS and lifted Lighthouse scores from 35 to 94. Our bdManagedIT case study paired Astro with Sanity for a 95+ PageSpeed static build. Both patterns hold up well as TYPO3 replacements when the content model allows for it.

The key question is this: does your content model actually justify TYPO3's complexity? A 200-page marketing site probably doesn't need it. A multi-language enterprise portal with complex workflows is a different story, and the content modeling work during migration will be substantial no matter where you land.

Content Audit and Data Mapping

This is where migrations live or die: content.

Database Export and Analysis

TYPO3 stores content mainly in these tables:

• pages -- the page tree structure
• tt_content -- content elements
• sys_file and sys_file_reference -- media assets (FAL)
• sys_category -- categories
• tx_news_domain_model_news -- if you use the news extension

Export your content and get real numbers:

-- Count pages by type
SELECT doktype, COUNT(*) as count 
FROM pages 
WHERE deleted = 0 
GROUP BY doktype;

-- Count content elements by type
SELECT CType, COUNT(*) as count 
FROM tt_content 
WHERE deleted = 0 AND hidden = 0 
GROUP BY CType 
ORDER BY count DESC;

-- Count file references
SELECT COUNT(*) FROM sys_file WHERE missing = 0;

Content Type Mapping

Build a spreadsheet mapping every TYPO3 content type (CType) to its counterpart in the target system. Common TYPO3 content types you'll run into:

• text, textmedia, textpic -- standard text content
• image -- image galleries
• table -- data tables
• bullets -- lists
• uploads -- file lists
• html -- raw HTML (these are always fun during migration)
• list -- plugin content (this is where it gets complicated)
• Custom content types from extensions

The list CType is the one that causes trouble. It represents plugin content, things like news listings, forms, and custom functionality, and each instance needs individual attention.

Multi-Language Content

TYPO3 handles translations through connected mode (translations linked to a default language record) or free mode. Check which one your site is actually using:

-- Check translation setup
SELECT sys_language_uid, COUNT(*) 
FROM pages 
WHERE deleted = 0 
GROUP BY sys_language_uid;

Eight languages with connected mode translations means your data mapping just got eight times more complex. Plan for it accordingly.

Technical Infrastructure Preparation

Server Requirements

TYPO3 publishes exact version requirements for each release. As of 2026, the minimum requirements for TYPO3 v13 include:

• PHP 8.2 or higher (8.3 recommended)
• MySQL 8.0+ or MariaDB 10.4+ or PostgreSQL 12+
• 256MB PHP memory limit minimum (512MB recommended)
• Composer 2.7+

Staging Environment

Never run a migration directly on production. Set up:

1. A staging environment that mirrors production
2. A separate database copy
3. Identical PHP and server configurations
4. File storage access (or a copy of fileadmin)

## Clone your database to staging
mysqldump -u root -p production_db | mysql -u root -p staging_db

## Rsync fileadmin
rsync -avz production:/var/www/html/fileadmin/ staging:/var/www/html/fileadmin/

Backup Strategy

Before any migration work begins:

• Full database dump with timestamps
• Complete file system backup, including fileadmin, typo3conf, and any custom extension folders
• Document your LocalConfiguration.php and AdditionalConfiguration.php settings
• Export your TypoScript templates

Store these backups somewhere fully separate from the migration environment, and keep at least three copies.

Extension and Integration Inventory

TYPO3 extensions are probably the single biggest source of migration headaches. Here's how to get ahead of them.

List All Installed Extensions

## Composer-based installation
composer show | grep typo3

## Or check the PackageStates.php
cat typo3conf/PackageStates.php

Categorize Each Extension

For every extension, check:

Category	Action Required	Example
Core system extension	Usually handled by upgrade wizard	fluid_styled_content, form
Maintained TER extension	Check compatibility with target version	news, powermail, solr
Abandoned TER extension	Find replacement or custom solution	Various
Custom site extension	Needs manual migration/rewrite	Your site_package
Commercial extension	Contact vendor for migration path	in2publish, various

Common Extension Migration Paths

Some extensions show up in almost every TYPO3 migration:

• EXT:news (Georg Ringer) -- Check version compatibility; v11+ works with TYPO3 v12/v13
• EXT:powermail -- Popular form extension; alternatives include EXT:form (core)
• EXT:realurl -- Deprecated since TYPO3 v9; replaced by core routing
• EXT:tt_address -- Usually a straightforward upgrade
• EXT:gridelements or EXT:flux -- These layout extensions cause the most pain during upgrades. If you're migrating away from TYPO3, expect real work extracting content from grid structures.

SEO Preservation Plan

Skip this section and you risk real organic traffic. Don't be that team.

URL Mapping

1. Crawl your entire current site with Screaming Frog, Sitebulb, or Ahrefs
2. Export all URLs (expect thousands for large TYPO3 sites)
3. Create a full 1:1 URL mapping document
4. Identify your top 100 pages by organic traffic (check Google Search Console)
5. Prioritize redirect accuracy for high-traffic pages

Redirect Implementation

## Example .htaccess redirects
RedirectPermanent /old-typo3-path/page.html /new-path/page
RedirectPermanent /index.php?id=123 /about-us

For large-scale redirects, use a proper redirect management tool instead of cramming thousands of rules into .htaccess. If you're moving to a modern stack, most frameworks and hosting platforms (Vercel, Netlify) ship their own redirect configuration files.

Meta Data Migration

TYPO3 stores SEO metadata in the pages table (since EXT:seo became a core extension in v9):

• seo_title
• og_title, og_description, og_image
• twitter_title, twitter_description, twitter_image
• canonical_link
• no_index, no_follow

Export and map all of it. Losing meta descriptions across 500 pages is a preventable disaster.

The Migration Execution Phase

For TYPO3 Version Upgrades

Follow this sequence for each version step:

1. Update Composer dependencies to the next LTS version
2. Run the Upgrade Wizard in the Install Tool (Admin Tools > Upgrade)
3. Execute database analyzer to update schema
4. Check deprecation log for issues
5. Update extensions to compatible versions
6. Fix TypoScript deprecations and breaking changes
7. Test thoroughly before moving to the next version step

## Update TYPO3 core via Composer
composer require typo3/cms-core:^13.4 typo3/cms-backend:^13.4 \
  typo3/cms-frontend:^13.4 --with-all-dependencies

## Run upgrade wizards via CLI
php typo3/sysext/core/bin/typo3 upgrade:run

## Database schema update
php typo3/sysext/core/bin/typo3 database:updateschema

For Platform Migrations

If you're migrating to a headless CMS architecture, the execution phase looks different:

1. Set up the new CMS and configure content models
2. Build migration scripts to transform TYPO3 data
3. Migrate content in batches -- start with the simplest content types
4. Handle media assets -- download from fileadmin and upload to new asset storage
5. Build the frontend with your chosen framework
6. Implement redirects before go-live
7. DNS cutover and monitoring

Data transformation scripts are usually written in Python or Node.js. They read straight from the TYPO3 database and push content to the new CMS via API:

import mysql.connector
import requests

## Connect to TYPO3 database
db = mysql.connector.connect(
    host="localhost",
    user="typo3",
    password="password",
    database="typo3_db"
)

cursor = db.cursor(dictionary=True)
cursor.execute("""
    SELECT uid, title, description, slug, 
           seo_title, og_description 
    FROM pages 
    WHERE deleted = 0 AND hidden = 0 
    AND sys_language_uid = 0
    ORDER BY sorting
""")

for page in cursor.fetchall():
    # Transform and push to new CMS
    payload = {
        "title": page["title"],
        "slug": page["slug"],
        "seoTitle": page["seo_title"] or page["title"],
        "description": page["og_description"] or page["description"]
    }
    # POST to your new CMS API
    response = requests.post(
        "https://api.new-cms.com/content",
        json=payload,
        headers={"Authorization": "Bearer YOUR_TOKEN"}
    )
    print(f"Migrated page {page['uid']}: {response.status_code}")

Testing and Quality Assurance

Automated Testing Checklist

• All pages return 200 status codes
• No broken internal links
• All images load correctly
• Forms submit successfully
• Search functionality works
• Multi-language switching works
• Redirects from old URLs work correctly
• Canonical URLs are correct
• XML sitemaps are valid and accessible
• robots.txt is properly configured
• SSL certificates are valid
• Page load times are acceptable (under 3 seconds)

Visual Regression Testing

Use tools like Percy, BackstopJS, or Playwright for visual comparison:

## BackstopJS example
npx backstop init
## Configure scenarios in backstop.json
npx backstop reference  # Capture current site
npx backstop test       # Compare after migration

Performance Benchmarks

Measure before and after. A migration should improve performance, not hurt it. These targets line up with Google's Core Web Vitals thresholds for LCP, CLS, and INP.

Metric	Pre-Migration Target	Post-Migration Target
TTFB	< 800ms	< 200ms
LCP	< 2.5s	< 1.5s
CLS	< 0.1	< 0.05
FID/INP	< 200ms	< 100ms
PageSpeed Score	50-70	90+

Moving from server-rendered TYPO3 to a static or edge-rendered frontend usually means big gains across these numbers.

Post-Migration Monitoring

The migration isn't done when you flip the DNS. Monitor these for at least 30 days:

1. Google Search Console -- Watch for crawl errors, coverage issues, and indexing problems. Expect some ups and downs in the first two weeks.
2. Analytics -- Compare traffic patterns week-over-week with pre-migration baselines.
3. 404 errors -- Log 404s and add redirects for any URLs you missed.
4. Core Web Vitals -- Track real-user data via CrUX or your analytics platform.
5. Server logs -- Watch for unusual error patterns.

Set up alerts for traffic drops over 20% on any page that was previously in your top 50.

Common TYPO3 Migration Pitfalls

These same mistakes show up across TYPO3 migrations again and again:

1. Ignoring soft-deleted records. TYPO3 uses deleted=1 flags instead of actually removing records. Your migration scripts need to filter these out, or you'll end up importing thousands of records that were deleted years ago.

2. Forgetting about workspaces. If the site uses TYPO3 workspaces for editorial workflows, draft content can end up mixed into your export. Always filter for t3ver_wsid = 0 to get only live content.

3. Underestimating RTE content. TYPO3's rich text editor output can carry custom tags, <link> tags with TYPO3-specific syntax, and t3:// URIs. All of these need parsing and converting.

4. Breaking file references. TYPO3's File Abstraction Layer (FAL) uses sys_file_reference to connect files to content. It isn't a simple image field on the content record, it's a relation table. Your scripts need to follow these references.

5. Not testing with real content volumes. A migration script that works fine with 10 test pages can fail badly at 15,000 pages and 50,000 content elements. Always test at scale.

If you're planning a migration and want a second pair of eyes on the plan, reach out and we can walk through your specific situation.

FAQ

How long does a TYPO3 migration typically take?

It depends heavily on how complex your installation is. A simple version upgrade for a single-language site with standard extensions usually runs several weeks. A full platform migration for a multi-language enterprise site with custom extensions can stretch into several months, including a long content audit on large sites.

Can I skip TYPO3 LTS versions during an upgrade?

No. TYPO3's official guidance is to upgrade through each LTS version in order. Every step runs upgrade wizards that migrate data for that release, and skipping versions skips those migrations too, which risks corrupted or orphaned data down the line. Teams that try skip-version jumps to save time often end up with subtle issues months after launch.

Should I migrate from TYPO3 to WordPress?

Depends on your needs. WordPress works fine for simple marketing sites. But if TYPO3 was chosen for complex multi-language needs, granular permissions, or enterprise workflows, WordPress can feel like a step backward. A headless CMS paired with a modern frontend framework tends to fit better for teams leaving enterprise CMS platforms.

What happens to my SEO rankings during a TYPO3 migration?

Expect some ranking swings during and after the migration, even with correct redirects in place, because Google still needs time to recrawl and reindex everything. To limit the damage, add 301 redirects for every URL, keep the content structure close to the original, and submit updated sitemaps right away. If you're changing domains, use the Change of Address tool.

How do I handle TYPO3 extensions that don't exist on the target platform?

Figure out what each extension actually does before deciding how to replace it. Plenty of TYPO3 extensions cover features already built into modern platforms, form builders, SEO tools, redirect management, and so on. For genuinely custom functionality, find a matching plugin or service, or build a replacement from scratch. Track every decision in a spreadsheet: extension, purpose, replacement plan.

Is it worth moving to headless TYPO3 instead of migrating away entirely?

The TYPO3 headless extension (EXT:headless) is a solid option if the team likes TYPO3's backend but wants a modern frontend. It exposes TYPO3 content as JSON APIs, which lets you build the frontend with Next.js, Nuxt, or Astro while keeping the existing content structure and editorial workflows intact.

What's the cost of a TYPO3 migration in 2026?

Costs vary a lot with scope. Version upgrades for a mid-sized site cost far less than full platform migrations to a headless setup. Total spend scales with content volume, number of languages, custom functionality, and integration complexity. Weigh any quote against the ongoing cost of running an outdated, insecure CMS. Check our pricing page to see how we scope these projects.

Do I need to rebuild my templates from scratch?

For version upgrades, usually not entirely, though you'll need to update Fluid templates to handle deprecated ViewHelpers and new APIs. For platform migrations, yes, you're building a new frontend from the ground up. Modern frameworks like Next.js and Astro get you to a fast frontend quicker than the old Fluid and TypoScript era allowed. The design can often stay the same while only the build underneath changes.

Key takeaway:

Audit your TYPO3 version and extension stack before touching production.