TYPO3のキャッシュ再構築がステージングサーバーで完了します。コンテンツ変更に2秒かかるべき処理が43秒かかります。フロントエンド開発者がブラウザを更新すると、更新内容は表示されますが、TypeScriptについて何かぼやきます。これはスタンドアップで繰り返すべきでない言葉です。このシーンはヨーロッパ全体のエンタープライズで毎日繰り返されます。ここではTYPO3が20年間政府ポータルと企業サイトを支えてきました。CMSはまだ技術的には動作します。しかしDrupalのコンポーネント優先アーキテクチャ、ヘッドレスツールキット、10倍大きい貢献者ベースは、移行の会話を避けられなくします。問題は移行するかどうかではなく、8000ページを移行し、20年間のURL資産を保持し、移行中にコンテンツ編集者を正気に保つ方法です。過去18ヶ月間に6回このプロセスを実行しましたが、クリーンな移行と災害の差は最初の1週間で行う4つの決定に左右されます。

過去数年、TYPO3からDrupalへの移行に深く関わってきました。それは実世界のコンテンツモデルを解きほぐすかなりの旅でした。通常はごちゃごちゃです。このガイドは最初の移行の前に誰かから受け取りたかったものです。すべての面倒な技術詳細、計画の必須事項、タイムラインを台無しにする厄介な地雷をカバーします。

目次

TYPO3からDrupalへの移行: 実践的な開発者向けガイド

組織が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が本当にあなたの痛点を解決するかどうかを確認してください。2026年現在の状況は次のとおりです:

機能 TYPO3 v13 Drupal 11
コンテンツモデリング 柔軟だが、TCAに傾いている Entity/Fieldシステムとフィールド管理UI
多言語 優れたネイティブサポート 同様に優れたネイティブサポート
マルチサイト 標準的なマルチサイトとコンテンツツリー 可能、Domain AccessやSeparateインストールで通常はより良い
ヘッドレス/API ヘッドレス拡張機能あり コアJSON:API、GraphQL contrib
テンプレート作成 Fluidテンプレート + TypeScript 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/時間(DACH地域) $80-200/時間(グローバル)

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インスタンスを発見しましたが、アクティブに使用されているのはわずか12個でした。死んだ重量を移動しないでください。

保つもの、排除するもの

ここであなたが家を掃除するチャンスです。ScreamingFrogやSitebulbなどのコンテンツ監査ツールを使用してこれを見つけます:

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

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

TYPO3からDrupalへの移行: 実践的な開発者向けガイド - アーキテクチャ

コンテンツモデリング: TYPO3からDrupalへのマッピング

袖をまくり上げます。これは重い知的リフティングです。TYPO3とDrupalはコンテンツを非常に異なる方法で処理します。

TYPO3のモデル

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

Drupalのモデル

Drupalはすべてエンティティについてです。コンテンツタイプ(ノードバンドル)をそれぞれ専用フィールドで作成します。ページは多くのコンテンツタイプの1つにすぎません。タクソノミー、パラグラフ(パラグラフモジュールを使用)、レイアウトビルダーマスター構造化コンテンツ合成。

マッピング

ナビゲーション用の羅針盤として使用する典型的なマッピングテーブルです:

TYPO3概念 Drupal同等
ページ(doktype: standard) ノード(コンテンツタイプ: Page)
ページ(doktype: shortcut) URLリダイレクト
ページ(doktype: link) リンクフィールドまたはリダイレクト付きノード
コンテンツ要素(CType: text) パラグラフタイプまたはBodyフィールド
コンテンツ要素(CType: image) メディアエンティティ参照
コンテンツ要素(CType: textpic) テキスト+メディア付きパラグラフタイプ
コンテンツ要素(CType: gridelements) レイアウトビルダーセクション
FALファイル参照 メディアエンティティ
sys_category タクソノミー用語
fe_users Drupalユーザーエンティティ
be_users 管理者ロール付きDrupalユーザーエンティティ
TypeScriptテンプレート Twigテンプレート
Extbaseプラグイン カスタムDrupalモジュール
Mask/DCEコンテンツ要素 パラグラフタイプ

最大の変化ですか? コンテンツ要素をパラグラフに移動します。TYPO3はコンテンツ要素をページ列にスタックします。これはDrupalのパラグラフモジュールにうまくマップされます。編集者は再利用可能なパラグラフタイプからページをスタックします。それは驚くほどシームレスです。

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

DrupalのMigrate APIは素晴らしいです。しかし、注意点があります。TYPO3ソースプラグインのネイティブサポートはありません。TYPO3のデータベースから引き出すためにカスタムソースプラグインを作成する必要があります。

アプローチ1: ダイレクトデータベース移行

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

// TYPO3ページ用の例migrate sourceプラグイン
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 TypeScriptと拡張機能の処理

TypeScript

ずばり言いましょう。TypeScriptは移行されません。これはTYPO3固有の設定言語で、他の場所に実際の対応物がありません。あなたの仕事は、各TypeScriptテンプレートが何をするのか、素人の言葉で文書化してから、Twigテンプレートとドルパル設定として再構築することです。それは大変ですが必要です。

拡張機能

一般的なTYPO3拡張機能とDrupal相当物の便利な比較です:

TYPO3拡張機能 Drupal同等
news コアコンテンツタイプ + ビュー
powermail Webformモジュール
solr(ext:solr) Search API + Solr
realurl / routing Pathauto + コアルーティング
gridelements レイアウトビルダーまたはパラグラフ
mask パラグラフ
tt_address カスタムコンテンツタイプまたはCiviCRM
ke_search Search API
femanager ユーザーモジュール + カスタム
cal/events カスタムコンテンツタイプ + ビュー

カスタムExtbaseエクステンションをDrupalモジュールとして書き直す必要があります。これをやる道はありません。予算を立てることを忘れずに。

URL構造とSEO保護

これを台無しにすると、オーガニックトラフィックを失います。移行後の不正な処理されたリダイレクトによるオーガニック検索トラフィックの最大40%の損失を目撃した組織があります。

ステップ

  1. TYPO3からすべてのURLをエクスポートします。 インデックスされたすべてのURLについてCLIツールまたはクローラーを使用します。
  2. これらをDrupal URLにマップします。 Drupalの自動パスを使用して、既存のURLに近い位置にとどまります。
  3. 変更されるすべてのものへのリダイレクトを作成します。 Drupalにリダイレクトモジュールをデプロイします。大量のリダイレクトについては、CSVでインポートします。
  4. 言語プレフィックスを処理します。 TYPO3は/de/、/en/、/fr/を使用します。Drupalの言語設定がこれを反映していることを確認します。
  5. 更新されたサイトマップをすぐにGoogle Search Consoleに送信します。
# Drupalのリダイレクトモジュール用のリダイレクトインポート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エコシステムは繁栄しています。

ヘッドレスアプローチをお考えですか? 2026年ではほとんどのコンテンツ駆動型サイトにとって、それは検討する価値があります。前のブログで詳細に説明しました。

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

  • Next.js — 最前線。Chapter Threeによるnext-drupalがプロセスを簡素化します。
  • Astro — コンテンツが多く、クライアント側があまり重くないサイトに最適です。
  • Nuxt — Vueが遊び場の場合。

最初にDrupalに移行した後の美しさは、Drupalのデフォルトのtwigフロントエンドで起動することです。後で、分離されたものに切り替えることができます。両方の動きを一度に試みないでください。プロジェクトの混乱を求めています。

タイムライン、コスト、スタッフの見積もり

私が関わっているプロジェクト、または最近の正確なデータを持っているプロジェクトからの実際の数字:

サイトサイズ ページ タイムライン 予算範囲 チーム
小さい <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開発者

これには、発見、コンテンツモデリング、移行、フロントエンドテーマ作成、QA、編集者トレーニングがすべて含まれています。継続的なメンテナンスはここでは含まれていません。

大きなコスト要因はページ数だけではなく、複雑さです。30のカスタムコンテンツタイプと4言語を備えた2000ページのサイトは、シンプルな10000ページのサイトよりもコストがかかります。

あなたのケースの詳細を検討していますか? チェックアウトするか、直接連絡してください。

移行後チェックリスト

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

  • すべてのリダイレクトを確認します。それらが301であることを確認します。
  • Google Search Consoleを新しいサイトマップで更新します。
  • すべてのフォームをテストします。連絡先、ニュースレター、ログイン。
  • 各言語のマルチ言語コンテンツの正確性を確認します。
  • メディアファイルを正確に移行し、altテキストとメタデータが含まれていることを確認します。
  • 各ロールの編集者権限を確認します。
  • パフォーマンスメトリックを取得します(Core Web Vitals)。
  • 分析追跡を確認します(GA4イベント、目標)。
  • CDN/キャッシングを設定およびテストします。
  • セキュリティヘッダーを有効にします(CSP、HSTS)。
  • バックアップとディザスタリカバリーシステムをテストします。
  • エディターのトレーニングを完了し、ドキュメントを配信します。
  • 古いTYPO3インスタンスを読み取り専用モードで利用可能に保ちます。

FAQ

TYPO3からDrupalへの移行は通常どのくらいかかりますか?

ページが中程度のサイト(500-5000ページ)の場合、開始から起動まで約4-6ヶ月です。最初の月? 純粋に発見とコンテンツモデリング。移行スクリプティングは通常6-8週間の作業を意味します。QAと編集者トレーニング? もう1ヶ月数えます。複雑なマルチ言語、マルチサイト設定でカスタム拡張機能がある場合は、9-12ヶ月を見ています。

TYPO3コンテンツを自動的に移行できますか、それとも手動ですか?

ページ、ニュースレコード、またはカテゴリーなどの構造化コンテンツですか? 絶対にDrupalのMigrate APIを使用した自動化ジョブ。しかし、TYPO3の複雑なレンダリングロジックコンテンツは手動でのいくつかのしごが必要かもしれません。ほとんどの移行ですか? 約70-80%自動、20-30%手動。

移行中にGoogleランキングを失いますか?

リダイレクトに注意を払う場合はできません。URLの変更に対して301を設定し、可能な限りURL構造に固執し、更新されたサイトマップを直ちに送信します。おそらく2-6週間の下落が見られます。しかし、リバウンドは典型的です。サイトは通常、移行前のレベルに戻る4-8週間で、多くの場合、3ヶ月以内の改善を見てはるかに改善されたパフォーマンスのため。

Drupalはコンテンツ編集者にとってTYPO3より学習が難しいですか?

より難しくはなく、異なります。TYPO3のページツリーモデルに慣れている人は、Drupalのエンティティ中心のアプローチで時間を必要とするかもしれません。パラグラフモジュールはやや似たコンテンツ構築経験を提供します。編集者とコンテンツタイプおよびワークフロー固有のドキュメントに約2-3日のトレーニングを提供することを忘れずに予算を立てます。

移行中のTYPO3拡張はどうなりますか?

すべての拡張には個別の評価が必要です。多くはDrupalの直接相当物があります(例えば、powermail → Webform、ext:news → カスタムコンテンツタイプ + ビュー、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はどこにありますか? 主に開発者の費用を削減し、機能展開を高速化することから。歴史的に、私が導いたチームは、主に簡単な才能採用とカスタム開発の必要性を削減するより大きなモジュールプールのため、初年度で開発コストの約20-40%の削減を見ます。初期移行コストは重いですが、ほとんどは18-24ヶ月以内に損益分岐点に達すべきです。