If you've ever stared at a TYPO3 backend and thought, "there has to be a better way," trust me, you’re far from alone. TYPO3's got its power – I won't argue there. It's been the CMS darling for countless European enterprises and government sites for over twenty years. But, let's be honest here, the developer landscape has changed a ton. Many organizations are finding that Drupal offers a more modern setup, a stronger community, and an easier path to headless/decoupled architectures.

I've been knee-deep in a few TYPO3-to-Drupal migrations over the last couple of years, and it's been quite the journey unraveling real-world content models. They're usually a tangled mess. This guide is what I wish someone had handed me before my first migration. I'll cover all the nitty-gritty technical details, the planning must-dos, and those pesky landmines that can torpedo your timeline if you're not on your toes.

Table of Contents

TYPO3 to Drupal Migration: A Practical Developer's Guide

Why Organizations Leave TYPO3

Let's be upfront: TYPO3 isn't a bad CMS. It's tremendously flexible, handles multi-site, and multi-language setups natively, boasting a die-hard fanbase especially in the DACH region. So why do folks jump ship?

I hear pretty much the same reasons every time:

Developer availability. Outside of Central Europe, finding TYPO3 developers is about as difficult as finding a needle in a haystack. Drupal, on the other hand, claims approximately 1.3 million developers globally, as per Drupal.org's 2024 community report. TYPO3? Not so much. If your senior TYPO3 devs decide to pack up and leave, filling those seats could take forever.

Ecosystem momentum. With the release of Drupal 11 at the tail end of 2024, there were huge strides in admin UI, a new recipes system, and killer API-first capabilities. Sure, TYPO3 v13 is solid, but the innovation rate in Drupal, particularly around headless setups, is noticeably swifter.

Headless/decoupled architecture. Planning to serve content to a snazzy Next.js or Astro frontend? Drupal's JSON:API and GraphQL plugins are seasoned pros. TYPO3 has its own headless extension, but it's less mature with smaller backing.

Total cost of ownership. Hosting TYPO3 typically hits the wallet harder. Its specialized infrastructure means you could end up shelling out more. Drupal's contented pretty much anywhere from Pantheon to Acquia, even a basic LAMP stack keeps it purring along.

TYPO3 vs Drupal: An Honest Comparison

Before diving headfirst into a move, ensure Drupal's genuinely going to solve your pain points. Here's the lowdown as of 2025:

Feature TYPO3 v13 Drupal 11
Content Modeling Flexible but leans on TCA Entity/Field system with field management UI
Multi-language Stellar native support Equally stellar native support
Multi-site Standard multi-site with content trees Possible, often better with Domain Access or separate installs
Headless/API Has a headless extension JSON:API core, GraphQL contrib
Templating Features Fluid templates + TypoScript Runs on Twig templates
Extension/Module Ecosystem ~1,800 extensions on TER ~50,000+ modules on Drupal.org
Admin UI Strong, but dated (getting a facelift in v13) Sleek and modern in Drupal 11
Developer Community ~500 active contributors 8,000+ active contributors
Hosting Options Self-hosted or specialist Self-hosted, Pantheon, Acquia, Platform.sh, Lagoon
PHP Requirement PHP 8.2+ PHP 8.3+
Typical Agency Rate €100-180/hr (DACH region) $80-200/hr (global)

TYPO3's page tree model is a rare gem. Editors hooked on managing elaborate page hierarchies in TYPO3 might find Drupal's style—the combination of content types and taxonomy—requires a bit of an adjustment. Schedule some editor training to ease that transition.

Pre-Migration Audit and Planning

This stage determines the fate of most migrations. It’s all in the planning, not the technical times.

Content Inventory

Start by auditing everything in your TYPO3 setup:

  • Pages: Pull out that page tree, documenting every doktype (page type) you’ve got in play.
  • Content elements: Every CType (content type) needs attention—be it text, text with image, HTML, or custom stuff via mask or content_defender.
  • Extensions: Note every extension you’ve got. Find out if there's a Drupal equivalent.
  • File references: TYPO3's FAL (File Abstraction Layer) deals with media. Map these over to Drupal’s media spots.
  • Backend users and permissions: TYPO3's intricate backend user groups with page and field-level access should be neatly translated over to Drupal roles and permissions.

Here's a handy SQL query for a content element rundown from your TYPO3 database:

SELECT CType, COUNT(*) as count 
FROM tt_content 
WHERE deleted = 0 AND hidden = 0 
GROUP BY CType 
ORDER BY count DESC;

With this, you get a quick glimpse of the content types you're tangled with. In one case, I uncovered a TYPO3 instance boasting 40+ custom content element types, where only a dozen were actively used. Don't drag dead weight over.

What to Keep, What to Kill

Here's your chance to clean house. Use a content audit tool like Screaming Frog or Sitebulb to ferret out:

  • Pages seeing no traffic in the past year
  • Duplicate or almost-identical content
  • Broken internal links
  • Orphaned media files

Typically, there’s a 30-50% content cut in big TYPO3 migrations. Fewer pages mean quicker migrations.

TYPO3 to Drupal Migration: A Practical Developer's Guide - architecture

Content Modeling: Mapping TYPO3 to Drupal

Roll up your sleeves. This is the heavy intellectual lifting. TYPO3 and Drupal handle content very differently.

TYPO3's Model

TYPO3 revolves around pages. Everything’s tucked away in a page tree. Content elements (records in tt_content) slot onto pages in columns (colPos). Custom records defined through Extbase models or TCA sit in separate tables but are usually linked from pages.

Drupal's Model

Drupal's all about entities. You craft content types (node bundles), each with dedicated fields. Pages are just one among many content types. Taxonomy, paragraphs (using the Paragraphs module), and Layout Builder master the structured content composition.

The Mapping

Here’s a typical mapping table I use as my compass:

TYPO3 Concept Drupal Equivalent
Page (doktype: standard) Node (content type: Page)
Page (doktype: shortcut) URL redirect
Page (doktype: link) Node with link field or redirect
Content element (CType: text) Paragraph type or Body field
Content element (CType: image) Media entity reference
Content element (CType: textpic) Paragraph type with text + media
Content element (CType: gridelements) Layout Builder section
FAL file reference Media entity
sys_category Taxonomy term
fe_users Drupal user entity
be_users Drupal user entity with admin role
TypoScript template Twig template
Extbase plugin Custom Drupal module
Mask/DCE content elements Paragraph types

The biggest shift? Moving content elements to Paragraphs. TYPO3 stacks content elements in page columns, which maps well to Drupal's Paragraphs module. Editors stack pages from reusable paragraph types—it’s surprisingly seamless.

Migration Tooling and Technical Approach

Drupal's Migrate API rocks. But heads up, it lacks a native TYPO3 source plugin. You'll have to whip up some custom source plugins to pull from TYPO3's database.

Approach 1: Direct Database Migration

Plug Drupal’s Migrate API straight into your TYPO3 MySQL/MariaDB database:

// Example migrate source plugin for TYPO3 pages
namespace Drupal\typo3_migrate\Plugin\migrate\source;

use Drupal\migrate\Plugin\migrate\source\SqlBase;
use Drupal\migrate\Row;

/**
 * @MigrateSource(id = "typo3_pages")
 */
class Typo3Pages extends SqlBase {

  public function query() {
    return $this->select('pages', 'p')
      ->fields('p', ['uid', 'title', 'slug', 'abstract', 'doktype', 'crdate', 'tstamp'])
      ->condition('p.deleted', 0)
      ->condition('p.hidden', 0)
      ->condition('p.doktype', [1, 4], 'IN');
  }

  public function fields() {
    return [
      'uid' => $this->t('Page ID'),
      'title' => $this->t('Page title'),
      'slug' => $this->t('URL slug'),
      'abstract' => $this->t('Abstract/summary'),
    ];
  }

  public function getIds() {
    return ['uid' => ['type' => 'integer']];
  }

  public function prepareRow(Row $row) {
    // Load associated content elements
    $pid = $row->getSourceProperty('uid');
    $content = $this->select('tt_content', 'tt')
      ->fields('tt')
      ->condition('tt.pid', $pid)
      ->condition('tt.deleted', 0)
      ->orderBy('tt.sorting')
      ->execute()
      ->fetchAll();
    $row->setSourceProperty('content_elements', $content);
    return parent::prepareRow($row);
  }
}

I like this approach. It’s about having full control and lets you handle TYPO3's peculiarities (like soft-deletes and workspace overlays) in your codebase.

Approach 2: Export/Import via JSON or XML

Some teams choose to export TYPO3 content into structured formats (say, through custom TYPO3 extensions or CLI commands) and then import them into Drupal. Sure, it adds another layer but comes in handy if you’re wary of maintaining direct database connections during migration.

Approach 3: Hybrid with Manual Review

Got a smaller site (under 500 pages)? Doing a structured data migration automatically while handcrafting key landing pages can work like a charm. It might seem rudimentary, but when content's intertwined with TYPO3-specific rendering logic, automated migration often results in nonsense.

Handling TYPO3 TypoScript and Extensions

TypoScript

Let's cut to the chase: TypoScript doesn’t migrate over. It's a TYPO3-specific config language, with no real counterpart elsewhere. Your job is to document what each TypoScript template does in layman's terms and then rebuild it as Twig templates and Drupal config. It’s painstaking but necessary.

Extensions

Here's a handy comparison of common TYPO3 extensions and their Drupal counterparts:

TYPO3 Extension Drupal Equivalent
news Core Content Type + Views
powermail Webform module
solr (ext:solr) Search API + Solr
realurl / routing Pathauto + core routing
gridelements Layout Builder or Paragraphs
mask Paragraphs
tt_address Custom content type or CiviCRM
ke_search Search API
femanager User module + custom
cal/events Custom content type + Views

Custom Extbase extensions need rewriting as Drupal modules. No shortcuts there—be sure to budget for it.

URL Structure and SEO Preservation

Mess this up, and you lose organic traffic. I've witnessed organizations lose up to 40% of their search traffic post-migration due to mishandled redirects.

Steps

  1. Export all URLs from TYPO3. Use a CLI tool or a crawler for every indexed URL.
  2. Map these to Drupal URLs. Use Drupal's Pathauto for URL alias generation, sticking close to existing URLs.
  3. Create redirects for everything that changes. Deploy the Redirect module in Drupal. For mountains of redirects, import via CSV.
  4. Handle language prefixes. TYPO3 uses /de/, /en/, /fr/ - make sure Drupal's language settings mirror this.
  5. Submit updated sitemaps to Google Search Console right away.
# Example redirect import CSV format for Drupal's Redirect module
source,redirect,status_code,language
/alte-seite,/new-page,301,de
/old-page/subpage,/new-page/subpage,301,en
/kontakt,/contact,301,de

Pro tip: Keep the old TYPO3 instance live, albeit read-only, for a minimum of three months post-migration. You'll unearth missed URLs.

Going Headless After Migration

Drupal shines with its path to a decoupled frontend. With Drupal 11, the JSON:API module is solid as a rock, and the headless Drupal ecosystem is thriving.

If you're mulling over a headless approach—and in 2025, for most content-driven sites, it's worth considering—we've delved into this thoroughly at /solutions/headless-cms-development.

Pairing popular frontends with Drupal:

The beauty of first migrating to Drupal is launching with Drupal's default Twig frontend. Later on, you can switch to a decoupled one. Don’t attempt both moves at once—that's asking for project chaos.

Timeline, Cost, and Staffing Estimates

Real numbers from projects I've been a part of, or have accurate data from (2024-2025):

Site Size Pages Timeline Budget Range Team
Small <500 pages 2-3 months $30,000-60,000 2-3 developers
Medium 500-5,000 pages 4-6 months $60,000-150,000 3-5 developers
Large 5,000-50,000 pages 6-12 months $150,000-400,000 5-8 developers
Enterprise 50,000+ pages 12-18 months $400,000-1,000,000+ 8-15 developers

These include everything from discovery, content modeling, migration, frontend theming, QA, and editor training. Ongoing maintenance isn’t covered here.

The big cost factor isn’t just page count—it’s complexity. A 2,000-page site with 30 custom content types and 4 languages will cost more than a simple 10,000-page site.

Considering specifics for your case? Check out /pricing or reach out directly.

Post-Migration Checklist

Don't skip this checklist. Trust me.

  • Verify all redirects. Make sure they're 301s.
  • Update Google Search Console with your new sitemap.
  • Test all forms: contact, newsletter, login.
  • Ensure multi-language content accuracy for each language.
  • Migrate media files accurately with alt text and metadata.
  • Check editor permissions for each role.
  • Capture performance metrics (Core Web Vitals).
  • Verify analytics tracking (GA4 events, goals).
  • Configure and test CDN/caching.
  • Enable security headers (CSP, HSTS).
  • Test backup and disaster recovery systems.
  • Complete editor training and deliver documentation.
  • Keep the old TYPO3 instance available in read-only mode.

FAQ

How long does a TYPO3 to Drupal migration typically take?
For mid-sized sites (500-5,000 pages), it’s about 4-6 months from start to launch. The first month? Purely discovery and content modeling. Migration scripting usually means 6-8 weeks of work. QA and editor training? Count on another month. If it's a complex multi-language, multi-site setup with custom extensions, you’re looking at 9-12 months.

Can I migrate TYPO3 content automatically, or is it manual?
Structured content like pages, news records, or categories? Absolutely an automated job with Drupal's Migrate API. But TYPO3's complex rendering logic content might need some manual TLC. Most migrations? About 70-80% automatic, 20-30% manual.

Will I lose my Google rankings during the migration?
Not if you're diligent with your redirects. Set those 301s for any URL changes, cling to your URL structure as best as you can, submit those updated sitemaps stat. You’ll probably see a dip, say 2-6 weeks. But a rebound is typical—sites usually bounce back to pre-migration levels in 4-8 weeks and often see improvements in three months due to better performance.

Is Drupal harder to learn than TYPO3 for content editors?
Different, not harder. Those accustomed to TYPO3’s page tree model may need time with Drupal's entity-centric approach. The Paragraphs module does offer a somewhat similar content-building experience. Remember to budget for about 2-3 days of training for editors and furnish them with content type and workflow-specific documentation.

What happens to my TYPO3 extensions during migration?
Every extension deserves individual assessment. Many have direct Drupal equivalents (e.g., powermail → Webform, ext:news → custom content type + Views, ext:solr → Search API + Solr). Custom Extbase extensions? They’ll need a full rewrite as Drupal modules. There's no converter—you'll need to customize.

Should I go headless when migrating from TYPO3 to Drupal?
It depends on your objectives and timeline. If your move's motivated by developer or maintainability concerns, start simple with Drupal's Twig theming, aim for headless later. But if your frontend team loves React or a similar setup, and you crave modern delivery architecture, consider planning for headless from day one. Just remember: doing both migrations and frontend changes at once? That’s high-risk territory.

How do I handle multi-language content in the migration?
TYPO3's language setup (sys_language_uid, l10n_parent) aligns well with Drupal's Content Translation module. The trick? Nailing language-to-language mapping in your scripts and ensuring fallback matches your expectations. Be cautious with partially translated content—TYPO3’s language overlay modes (free, connected, strict) don’t have precise Drupal parallels. Editorial calls on incomplete translations might be necessary.

What's the ROI of migrating from TYPO3 to Drupal?
Where's the ROI? Mainly from slashing developer expenses and speeding up feature rollout. Historically, the teams I’ve guided see about a 20-40% cut in development costs in year one, thanks mainly to easier talent recruitment and having a bigger module pool that curbs the need for custom development. Initial migration costs can be hefty, but most should break even within 18-24 months.