TYPO3バックエンドを見つめて「もっといいやり方があるはずだ」と思ったことがあるなら、あなただけじゃありません。TYPO3には確かに力があります—異論はありません。20年以上もの間、無数のヨーロッパの企業や政府サイトのCMS界のダーリンでした。しかし、ぶっちゃけ、開発者の風景は大きく変わりました。多くの組織がDrupalはより最新のセットアップ、強力なコミュニティ、ヘッドレス/デカップルアーキテクチャへの道を提供していることに気づいています。

過去数年間、私はいくつかのTYPO3からDrupalへの移行に深く関わってきました。実世界のコンテンツモデルを解き明かすのはなかなかの冒険でした。通常、それらは絡み合った混乱です。本ガイドは、最初の移行の前に誰かが渡してくれたらよかったと思うものです。細かい技術的な詳細、計画に必須のこと、そしてタイムラインを台無しにしかねない厄介な地雷をカバーします。

目次

TYPO3 to Drupal Migration: A Practical Developer's Guide

なぜ組織がTYPO3を離れるのか

率直に言いましょう：TYPO3は悪いCMSではありません。非常に柔軟で、マルチサイトとマルチ言語のセットアップをネイティブに処理し、特にDAACH地域で信奉者の強固なファンベースを誇ります。では、なぜ人々は船乗りを変えるのでしょうか？

毎回同じような理由を聞きます：

開発者の可用性。 中央ヨーロッパ以外では、TYPO3開発者を見つけることは干し草の中から針を見つけるのと同じくらい難しいです。一方、Drupalは、Drupal.orgの2024年コミュニティレポートによると、世界中で約130万人の開発者を主張しています。TYPO3？そんなことはありません。シニアTYPO3開発者が立ち去ることになった場合、これらのポジションを埋めるのに永遠にかかる可能性があります。

エコシステムの勢い。 2024年末のDrupal 11のリリースで、管理UIで大きな進歩、新しいレシピシステム、そしてキラーなAPIファースト機能がありました。確かにTYPO3 v13は堅実ですが、特にヘッドレスセットアップに関連するDrupalのイノベーション率は著しく迅速です。

ヘッドレス/デカップルアーキテクチャ。 素敵なNext.jsまたはAstroフロントエンドにコンテンツを提供する計画ですか？DrupalのJSON:APIとGraphQLプラグインはベテランです。TYPO3には独自のヘッドレス拡張がありますが、それはあまり成熟せず、バッキングが小さいです。

総所有コスト。 TYPO3をホストすることは通常、財布にきついです。その専門的なインフラストラクチャは、より多くをシェル化する可能性があります。Drupalのコンテンツは、PantheonからAcquiaまで、基本的なLAMPスタックでもそこそこ動作します。

TYPO3 vs Drupal: 正直な比較

移行に頭から飛び込む前に、Drupalが本当にあなたの苦しみのポイントを解決するかどうかを確認してください。2025年現在、以下がその概要です：

機能 TYPO3 v13 Drupal 11
コンテンツモデリング 柔軟だがTCAに傾いている Entity/Fieldシステムと フィールド管理UI
マルチ言語 優れたネイティブサポート 同様に優れたネイティブサポート
マルチサイト 標準的なマルチサイトとコンテンツツリー 可能、Domain AccessまたはSeparate Installsではよりよい
ヘッドレス/API ヘッドレス拡張あり JSON:APIコア、GraphQL contrib
テンプレート Fluidテンプレート + TypoScriptを搭載 Twigテンプレートで実行
拡張/モジュールエコシステム TERで~1,800の拡張 Drupal.orgで~50,000以上のモジュール
管理UI 強いが時代遅れ（v13でリフレッシュされている） Drupal 11で洗練されて現代的
開発者コミュニティ ~500の活動的な貢献者 8,000以上の活動的な貢献者
ホスティングオプション セルフホスト型またはスペシャリスト セルフホスト、Pantheon、Acquia、Platform.sh、Lagoon
PHP要件 PHP 8.2+ PHP 8.3+
典型的なエージェンシーレート €100-180/hr（DACH地域） $80-200/hr（グローバル）

TYPO3のページツリーモデルはレアジェムです。TYPO3で複雑なページ階層を管理することにこだわっているエディターは、Drupalのスタイル—コンテンツタイプとタクソノミーの組み合わせ—が調整が必要であることに気づくかもしれません。エディタートレーニングをスケジュールして、その移行を緩和します。

移行前監査と計画

このステージはほとんどの移行の運命を決定します。技術的な時代ではなく、計画にあります。

コンテンツインベントリ

TYPO3セットアップのすべてを監査することから始めます：

  • ページ: ページツリーを引き出し、プレイ中のすべてのdoktype（ページタイプ）を文書化します。
  • コンテンツ要素: すべてのCType（コンテンツタイプ）に注意が必要です—テキスト、画像付きテキスト、HTML、またはmaskやcontent_defender経由のカスタムものであれ。
  • 拡張: あなたが持っているすべての拡張をメモします。Drupal相当するものがあるか確認します。
  • ファイル参照: TYPO3のFAL（ファイル抽象レイヤー）はメディアを扱います。これらをDrupalのメディアスポットにマップします。
  • バックエンドユーザーと権限: TYPO3の複雑なバックエンドユーザーグループ（ページとフィールドレベルのアクセス付き）は、Drupalのロールと権限に工夫されるべきです。

TYPO3データベースからのコンテンツ要素の概要用のハンディなSQLクエリを次に示します：

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

これにより、関わっているコンテンツタイプを素早くスナップショットできます。1つの場合、40以上のカスタムコンテンツ要素タイプを誇るTYPO3インスタンスを発見しましたが、実際には1ダースしか使用されていませんでした。デッドウェイトを引きずらないでください。

何を保つ、何を殺すか

ここはあなたの家を掃除するチャンスです。Screaming FrogやSitebulbのようなコンテンツ監査ツールを使って、以下を探します：

  • 過去1年間トラフィックを見たことのないページ
  • 重複またはほぼ同一のコンテンツ
  • 壊れた内部リンク
  • 孤立したメディアファイル

通常、大きなTYPO3移行では30～50%のコンテンツカットがあります。ページが少ないほど、移行は速くなります。

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

コンテンツモデリング: TYPO3をDrupalにマッピング

袖をまくり上げてください。これは重い知的な努力です。TYPO3とDrupalはコンテンツを非常に異なる方法で処理します。

TYPO3のモデル

TYPO3はページを中心に回ります。すべてはページツリーに隠されています。コンテンツ要素（tt_contentのレコード）はページの列（colPos）にスロットインします。TCAまたはExtbaseモデルを通じて定義されたカスタムレコードは別のテーブルに属していますが、通常はページからリンクされています。

Drupalのモデル

Drupalはエンティティについてです。コンテンツタイプ（ノードバンドル）を作成し、それぞれに専用フィールドを持たせます。ページは他の多くのコンテンツタイプの中の1つにすぎません。タクソノミー、段落（段落モジュールを使用）、およびLayout Builderは、構造化されたコンテンツ構成をマスターします。

マッピング

以下は、私がコンパスとして使用する典型的なマッピングテーブルです：

TYPO3概念 Drupal相当
ページ（doktype: standard） Node（コンテンツタイプ: Page）
ページ（doktype: shortcut） URLリダイレクト
ページ（doktype: link） リンクフィールド付きノードまたはリダイレクト
コンテンツ要素（CType: text） 段落タイプまたはBodyフィールド
コンテンツ要素（CType: image） メディアエンティティリファレンス
コンテンツ要素（CType: textpic） テキスト+メディア付き段落タイプ
コンテンツ要素（CType: gridelements） Layout Builderセクション
FALファイルリファレンス メディアエンティティ
sys_category タクソノミーターム
fe_users Drupalユーザーエンティティ
be_users 管理者ロール付きDrupalユーザーエンティティ
TypoScriptテンプレート Twigテンプレート
Extbaseプラグイン カスタムDrupalモジュール
Mask/DCEコンテンツ要素 段落タイプ

最大の変化？コンテンツ要素を段落に移すこと。TYPO3はコンテンツ要素をページ列にスタックしますが、これはDrupalの段落モジュールにうまくマップされます。エディターは再利用可能な段落タイプからページをスタックします—これは驚くほどシームレスです。

移行ツールと技術的アプローチ

DrupalのMigrate APIはロックです。しかし注意してください、ネイティブなTYPO3ソースプラグインがありません。TYPO3のデータベースから引き出すためにいくつかのカスタムソースプラグインを作成する必要があります。

アプローチ1: 直接データベース移行

DrupalのMigrate APIを直接TYPO3 MySQL/MariaDBデータベースに接続します：

// TYPO3ページ用の移行ソースプラグインの例
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) {
    // 関連するコンテンツ要素をロード
    $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);
  }
}

私はこのアプローチが好きです。完全な制御を持つことについてであり、TYPO3の癖（ソフト削除とワークスペースオーバーレイなど）をコードベースで処理できます。

アプローチ2: JSONまたはXMLを使用したエクスポート/インポート

いくつかのチームは、TYPO3コンテンツを構造化フォーマット（たとえば、カスタムTYPO3拡張またはCLIコマンドを使用）にエクスポートし、その後Drupalにインポートすることを選択しています。確かに別のレイヤーを追加しますが、移行中に直接データベース接続を保つことに不安がある場合に便利です。

アプローチ3: ハイブリッド（手動レビュー付き）

より小さなサイト（500ページ未満）を持っていますか？自動的に構造化されたデータ移行を行いながら、主要なランディングページを手作業で作成することができます。原始的に見えるかもしれませんが、コンテンツがTYPO3固有のレンダリングロジックに絡み合っている場合、自動化された移行はしばしば無意味な結果をもたらします。

TYPO3 TypoScriptと拡張機能の処理

TypoScript

単刀直入に言いましょう：TypoScriptは移行されません。これはTYPO3固有の設定言語であり、他の場所に実際の相当物がありません。あなたの仕事は、各TypoScriptテンプレートが何をするかを素人の言葉で文書化し、その後、Twigテンプレートとドルパル設定として再構築することです。それは退屈ですが必要です。

拡張

一般的なTYPO3拡張とそのDrupal相当物のハンディな比較：

TYPO3拡張 Drupal相当
news コアコンテンツタイプ + Views
powermail Webformモジュール
solr（ext:solr） Search API + Solr
realurl / routing Pathauto + core routing
gridelements Layout Builderまたは段落
mask 段落
tt_address カスタムコンテンツタイプまたはCiviCRM
ke_search Search API
femanager ユーザーモジュール + カスタム
cal/events カスタムコンテンツタイプ + Views

カスタムExtbase拡張は、Drupalモジュールとして書き直す必要があります。近道はありません—これに予算を配分してください。

URLストラクチャとSEO保全

これをめちゃくちゃにすると、オーガニックトラフィックを失います。移行後に不正処理されたリダイレクトのため、有機トラフィックの最大40%を失った組織を目撃しました。

ステップ

  1. TYPO3からすべてのURLをエクスポートします。 インデックス付きすべてのURLについてCLIツールまたはクローラーを使用します。
  2. これらをDrupal URLにマップします。 DrupalのPathautoを使用してURL別名生成を使用し、既存のURLにしっかり固執してください。
  3. 変更されるすべてのものにリダイレクトを作成します。 Drupalにリダイレクトモジュールをデプロイします。マウンテンのリダイレクトについては、CSVでインポートしてください。
  4. 言語プリフィックスを処理します。 TYPO3は/de/、/en/、/fr/を使用します—DrupalのLanguage設定がこれをミラーリングしていることを確認してください。
  5. 更新されたサイトマップをGoogle Search Consoleに送信します。
# DrupalのRedirectモジュールのリダイレクトインポートCSV形式の例
source,redirect,status_code,language
/alte-seite,/new-page,301,de
/old-page/subpage,/new-page/subpage,301,en
/kontakt,/contact,301,de

プロのヒント：古いTYPO3インスタンスを移行後最低3ヶ月間、読み取り専用であっても、生きたままにしてください。あなたは見逃されたURLを発掘するでしょう。

移行後のヘッドレス化

Drupalはデカップルフロントエンドへの道で輝きます。Drupal 11では、JSON:APIモジュールは堅固であり、ヘッドレスDrupalエコシステムは繁栄しています。

デカップルアプローチを検討している場合—そして2025年では、ほとんどのコンテンツ駆動型サイトについて、それは考えるに値します—/solutions/headless-cms-developmentで詳しく掘り下げました。

人気のあるフロントエンドをDrupalと組み合わせる：

  • Next.js — 最前線。Chapter Threeによるnext-drupalは物事を緩和します。/capabilities/nextjs-developmentで詳しく説明しています。
  • Astro — コンテンツが豊富だが、クライアント側があまり重くないサイトに最適です。/capabilities/astro-developmentを参照してください。
  • Nuxt — Vueがあなたの遊び場の場合。

まずDrupalに移行してからデカップルされたものに切り替える可能性は後から可能です。両方の動きを同時に試みないでください—それはプロジェクトの混乱を求めています。

タイムライン、コスト、スタッフ推定

私が関わってきたプロジェクト、または正確なデータを持つプロジェクトからの実数（2024-2025）：

サイトサイズ ページ タイムライン 予算範囲 チーム
小規模 <500ページ 2-3ヶ月 $30,000-60,000 2-3開発者
中規模 500-5,000ページ 4-6ヶ月 $60,000-150,000 3-5開発者
大規模 5,000-50,000ページ 6-12ヶ月 $150,000-400,000 5-8開発者
エンタープライズ 50,000+ページ 12-18ヶ月 $400,000-1,000,000+ 8-15開発者

これらには、発見、コンテンツモデリング、移行、フロントエンドテーマ処理、品質保証、およびエディタートレーニングのすべてが含まれています。継続的なメンテナンスはここではカバーされていません。

あなたの場合について特定事項を検討していますか？/pricingをチェックするか、直接連絡してください。

移行後チェックリスト

このチェックリストをスキップしないでください。信じてください。

  • すべてのリダイレクトを確認します。301であることを確認します。
  • 新しいサイトマップでGoogle Search Consoleを更新します。
  • すべてのフォームをテストします：お問い合わせ、ニュースレター、ログイン。
  • 各言語のマルチ言語コンテンツの精度を確認します。
  • メディアファイルをalt textとメタデータで正確に移行します。
  • 各ロールのエディター権限を確認します。
  • パフォーマンスメトリクスをキャプチャします（Core Web Vitals）。
  • 分析トラッキングを確認します（GA4イベント、目標）。
  • CDN/キャッシングを設定およびテストします。
  • セキュリティヘッダーを有効にします（CSP、HSTS）。
  • バックアップとディザスターリカバリーシステムをテストします。
  • エディタートレーニングを完了し、ドキュメントを配信します。
  • 古いTYPO3インスタンスを読み取り専用モードで利用可能な状態に保ちます。

FAQ

TYPO3からDrupalへの移行は通常どのくらい時間がかかりますか？
中規模サイト（500～5,000ページ）の場合、開始から開始まで約4～6ヶ月です。最初の1ヶ月？純粋に発見とコンテンツモデリング。移行スクリプティングは通常6～8週間の作業を意味します。QAとエディタートレーニング？別の月に数えます。それがマルチ言語、マルチサイトセットアップでカスタム拡張を持つ複雑な場合、あなたは9～12ヶ月を見ています。

TYPO3コンテンツを自動的に移行することはできますか、それとも手動ですか？
ページ、ニュースレコード、またはカテゴリーのような構造化コンテンツですか？DrupalのMigrate APIで絶対自動化されたジョブです。しかし、TYPO3の複雑なレンダリングロジックコンテンツは手作業で対応が必要かもしれません。ほとんどの移行ですか？約70-80%自動化、20-30%手作業。

移行中にGoogleのランキングを失いますか？
URLの変更について勤勉にリダイレクトを行っている場合、そうではありません。301をURLの変更のために設定し、可能な限りURLストラクチャに固執し、更新されたサイトマップをすぐに送信します。おそらく2～6週間のディップが見られるでしょう。しかし跳ね返りは典型的です—サイトは通常、4～8週間で移行前のレベルに跳ね返り、より良いパフォーマンスのため3ヶ月で改善を見ることがよくあります。

Drupalはコンテンツエディタにとってユーザーフレンドリーでしょうか？
違う、難しくありません。TYPO3のページツリーモデルに慣れたユーザーは、Drupalのエンティティ中心のアプローチで時間が必要かもしれません。段落モジュールはいくぶん同様のコンテンツ構築エクスペリエンスを提供します。エディターおよび文書のためのコンテンツタイプと固有のワークフロー説明では、約2～3日のトレーニングを予算化することを覚えておいてください。

移行中にTYPO3拡張はどうなりますか？
すべての拡張には個別の評価が必要です。多くは直接Drupal相当物を持っています（例：powermail → Webform、ext:news → カスタムコンテンツタイプ + Views、ext:solr → Search API + Solr）。カスタムExtbase拡張ですか？それらはDrupalモジュールとして完全に書き直される必要があります。コンバーターはありません—カスタマイズに予算を配分する必要があります。

TYPO3からDrupalに移行する際にヘッドレスに切り替えるべきですか？
それはあなたの目的とタイムラインに依存します。あなたの動きが開発者またはメンテナンス性の懸念によって動かされている場合、Drupalのtwigテーマ処理で開始し、後でヘッドレスを目指します。しかし、フロントエンドチームがReactや同様のセットアップを愛しており、モダンデリバリーアーキテクチャを切望している場合、初日からヘッドレスの計画を検討してください。覚えておいてください：両方の移行とフロントエンドの変更を同時に行うことですか？それは高リスク領域です。

移行でマルチ言語コンテンツをどのように処理しますか？
TYPO3の言語セットアップ（sys_language_uid、l10n_parent）はDrupalのコンテンツ翻訳モジュールとうまく一致します。トリックは、スクリプトの言語間マッピングを釘付けにし、フォールバックがあなたの期待と一致することを確認することです。部分的に翻訳されたコンテンツに注意してください—TYPO3の言語オーバーレイモード（無料、接続済み、厳密）には正確なDrupal相当物がありません。不完全な翻訳に関する編集的な呼び出しが必要になる可能性があります。

TYPO3からDrupalへの移行のROIは何ですか？
ROIはどこにあります？主に開発者費用を削減し、機能ロールアウトを加速させることです。歴史的に、私が導いたチームは年1での開発コストの約20-40%削減を見ます。主に容易なタレント採用とより大きなモジュールプールのおかげで、カスタム開発の必要性をカットしています。初期移行コストは高額かもしれませんが、ほとんどは18～24ヶ月以内に損益分岐点に達すべきです。