これを読んでいるのなら、おそらくあなたはTYPO3で行き詰まっているでしょう。ひょっとして、あなたの代理店がTYPO3 v8からv12へのアップグレードは完全なリビルドと同じくらいの費用がかかると言ったかもしれません。あるいは、実際に一緒に働きたいと思うTYPO3開発者が見つからなくなってしまったのかもしれません。または、競合他社が先月3つの新機能を立ち上げた一方で、あなたはまだTYPO3拡張機能の更新を待っていたことに気付いたばかりなのかもしれません。

あなただけではありません。TYPO3は20年以上にわたってヨーロッパのエンタープライズ市場に良いサービスを提供してきましたが、ウェブは先に進んでいます。そして、適切なマイグレーション代理店を見つけること――あなたがどこから来ているのか、そしてどこに行く必要があるのかを実際に理解している代理店――スムーズな移行と6ヶ月間の悪夢の違いです。

私はTYPO3マイグレーションに十分に関わってきて、何が悪くなり、何がうまくいくのかを知っています。すべてをあなたに説明させてください。

目次

TYPO3マイグレーション代理店:TYPO3から正常に移行する方法

組織がTYPO3から離れる理由

率直に言わせてください:TYPO3は死んでいません。バージョン13 LTSは2024年後半にドロップされ、本物の改善が行われました。しかし、組織がますます離れていく本当で実際的な理由があります。

開発者不足は現実です

TYPO3の市場シェアは何年も前から減少しています。2025年の時点で、W3Techsはすべての既知のCMSを使用しているウェブサイトの約0.4%にTYPO3を配置していますが、これは約1.2%のピークから下がっています。これは直接、エコシステムに参入する開発者の数が減っていることに変わります。LinkedInでTYPO3開発者の職を投稿してみてください――WordPress、Next.js、さらにはDrupalの職と比較して、応募者の割合はずっと小さくなります。

TYPO3を知っている開発者は年を重ねるか、他のスタックに移行しています。DACH地域でのTYPO3経験者の時間給は2025年に€120-180/時間で、同等のNext.jsまたはヘッドレスCMS開発者の€80-120と比較しています。

TypoScriptとFluidテンプレートの疲労

TypoScriptをReactを使うことに慣れた、あるいは単なるHTMLを使う、フロントエンド開発者に説明しようとしたことがあれば、苦しみを知ってます。それは設定言語として機能するが、どちらでもない言語です。Fluidテンプレートはより賢明ですが、全体的な開発者体験は2010年に立ち往生しているように感じています。

パフォーマンスと最新アーキテクチャ

TYPO3のページレンダリングモデルはサーバーサイドです。適切に設定されていればよくキャッシュされますが、Next.jsやAstroなどのフレームワークで使用される静的サイト生成やISR(増分静的再生成)のアプローチと競争することはできません。Core Web Vitalsは2025年のSEOに重要であり、TYPO3サイトを一貫して緑色のスコアにするには、重大な最適化作業が必要です。

総保有コスト

これは通常、マイグレーション会話をトリガーするものです。ホスティング(TYPO3にはPHP + MySQL/MariaDB +適切なサーバーリソースが必要)、開発者コスト、拡張機能ライセンス、メンテナンスオーバーヘッドを計算すると、中規模組織のTYPO3のTCOは、多くの場合、最新の代替製品を年間30~60%を超えています。

TYPO3マイグレーション代理店が実際に行うこと

実際のマイグレーション代理店は単にあなたのウェブサイトを別のプラットフォームで再構築するだけではありません。それが簡単な部分です。実際の作業がどのように見えるかを説明します:

コンテンツ監査とマッピング

TYPO3は関係型データベースに独自のコンテンツ要素モデルでコンテンツを保存します。ページ、コンテンツ要素、カテゴリ、ファイル参照、インライン関係――すべてが深く相互接続されています。マイグレーション代理店はすべてのコンテンツタイプを監査し、新しいプラットフォームのコンテンツモデルにマップし、再構築が必要なもの を特定します。

これだけで500ページ以上のサイトでは2~4週間かかる可能性があります。

データ抽出と変換

TYPO3のデータベーススキーマはまったく直感的ではありません。tt_contentpagessys_file_referencesys_categoryなどのテーブルはすべて、理解、結合、エクスポートが必要です。ほとんどの代理店はカスタム抽出スクリプト(通常はPHPまたはPython)を構築し、コンテンツを抜き出し、対象プラットフォームが取り込むことができる形式に変換します。

URLマッピングとリダイレクト戦略

TYPO3はv9以降、RealURLまたは組み込みルーティングを使用してきれいなURLを使用します。すべてのURLを新しい同等のURLにマップする必要があり、301リダイレクトを配置する必要があります。この手順をスキップすると、検索ランキングが一晩で消えます。

テンプレートとコンポーネントの再構築

あなたのTYPO3 Fluidテンプレートとタイプスクリプト設定は、対象プラットフォームが使用するものに翻訳される必要があります――Reactコンポーネント、Astroコンポーネント、Twigテンプレート、何でも。ここが実際のフロントエンドリビルドが起こるところです。

統合マイグレーション

フォーム、検索、eコマース、ニュースレター、DAM(デジタル資産管理)、認証用のTYPO3拡張機能はすべて、新しいプラットフォームでの同等のソリューションが必要です。何人かの直接代替品があります。他の人はカスタム開発が必要です。

TYPO3からの一般的なマイグレーションパス

ここは、TYPO3を離れるときに組織が通常到達する場所です:

マイグレーション対象 最適な用途 通常のタイムライン 相対コスト
WordPress シンプルなコンテンツサイト、ブログ、スモールビジネス 6~12週間 €€
ヘッドレスCMS + Next.js パフォーマンスが重要、マルチチャネル 12~20週間 €€€
ヘッドレスCMS + Astro コンテンツが多い、静的ファースト戦略 10~16週間 €€-€€€
Drupal 複雑なエンタープライズ、編集ワークフロー 14~24週間 €€€-€€€€
Contentful/Sanity/Storyblok APIファースト、最新の編集体験 12~18週間 €€€

ヘッドレスルート

これが最も推奨することが多く、Social Animalで専門としているものです。TYPO3からヘッドレスCMS(Contentful、Sanity、Storyblokなど)に移動し、最新のフロントエンドフレームワークと組み合わせることで、両方の長所を得られます:優れた編集体験AND最高級のパフォーマンス。

私たちはNext.jsAstroで広範に構築してきた、そして両方ともTYPO3マイグレーションの優れたターゲットです。Next.jsは、動的機能、認証、またはeコマースが必要な場合に正しい呼び出しです。Astroはコンテンツが王様で、可能な限り最速のページロードを望む場合に輝きます。

WordPressルート

I know, I know。ある伝統的なCMSから別のCMSへの移行は横方向の移動に感じます。しかし私の言うことを聞いてください――WordPressは巨大なエコシステム、容易に利用可能な開発者、そして(WPGraphQLを使用したヘッドレスCMSとして使用される場合)実際に最新のフロントエンドを動かすことができます。シンプルなコンテンツニーズを持つ小さなサイトの場合、それはしばしば最もコスト効果的なパスです。

Drupalルート

あなたのTYPO3サイトが複雑なコンテンツモデリング、マルチサイトセットアップ、粒度の細かいアクセス許可、重いな編集ワークフローを持っている場合、Drupalは最も自然なフィットです。コンテンツモデリングのパラダイムは十分に似ており、マイグレーションは比較的予測可能です。しかし、あなたはまだPHP圏にいて、同じ長期的な課題の多くを継承しています。

TYPO3マイグレーション代理店:TYPO3から正常に移行する方法 - アーキテクチャ

誰も警告しない技術的課題

ここが私の戦い傷が見えるところです。これらはTYPO3マイグレーション中にチームを驚かす事柄です。

多言語コンテンツはメッセージです

TYPO3はオーバーレイレコードを通じて翻訳を処理します。デフォルト言語コンテンツは1つの行に存在し、翻訳は同じテーブルの接続されたレコードです。この「接続モード」対「フリーモード」の翻訳アプローチは、ロケールベースのバリアント또는別のコンテンツエントリを使う傾向がある、ほとんどの最新のCMSにきれいにマップされていません。

あなたのサイトに5言語以上がある場合(ヨーロッパエンタープライズで一般的)、コンテンツマイグレーションが単一言語サイトより2~3倍長くかかると予想してください。

TYPO3のワークスペースとバージョニング

コンテンツステージングと承認ワークフローにTYPO3 Workspacesを使用する場合は、対象プラットフォームで同等のものを見つける必要があります。ほとんどのヘッドレスCMSにはドラフト/公開ワークフローの何らかの形がありますが、粒度の細かいワークスペースベースのアプローチを複製するには慎重な計画が必要です。

拡張機能固有のコンテンツ

newscalpowermailgridelementsなどのTYPO3拡張機能は、独自のデータベーステーブルとスキーマを持つ独自の拡張機能に格納します。標準的なコンテンツ抽出はこれをカバーしません――拡張機能固有のマイグレーションスクリプトが必要です。

ここはTYPO3のtx_news_domain_model_newsテーブルからニュースレコードを抽出する簡潔な例です:

import mysql.connector
import json

def extract_typo3_news(db_config):
    conn = mysql.connector.connect(**db_config)
    cursor = conn.cursor(dictionary=True)
    
    query = """
    SELECT 
        n.uid,
        n.title,
        n.teaser,
        n.bodytext,
        n.datetime,
        n.path_segment,
        n.sys_language_uid,
        GROUP_CONCAT(c.title) as categories
    FROM tx_news_domain_model_news n
    LEFT JOIN sys_category_record_mm mm 
        ON mm.uid_foreign = n.uid 
        AND mm.tablenames = 'tx_news_domain_model_news'
    LEFT JOIN sys_category c 
        ON c.uid = mm.uid_local
    WHERE n.deleted = 0 
        AND n.hidden = 0
    GROUP BY n.uid
    ORDER BY n.datetime DESC
    """
    
    cursor.execute(query)
    records = cursor.fetchall()
    
    # Transform to target CMS format
    transformed = []
    for record in records:
        transformed.append({
            'title': record['title'],
            'slug': record['path_segment'],
            'excerpt': record['teaser'],
            'body': record['bodytext'],  # Will need RTE cleanup
            'publishedAt': record['datetime'].isoformat(),
            'locale': 'de' if record['sys_language_uid'] == 0 else 'en',
            'categories': record['categories'].split(',') if record['categories'] else []
        })
    
    return transformed

これは簡潔です――実際の抽出スクリプトはファイル参照、関連レコード、RTE コンテンツクリーンアップ(<link t3://page?uid=42>のようなTYPO3固有のリンク構文を削除)、ワークスペースを意識したクエリを処理する必要があります。

RTE コンテンツクリーンアップ

TYPO3のリッチテキストエディタはt3://page?uid=123のような内部リンク参照とt3://file?uid=456のようなファイル参照でコンテンツを保存します。マイグレーション中にこれらのすべてを実際のURLまたはアセットパスに解決する必要があります。大規模サイトでは、これらの何千もあることができます。

// 例:移行されたコンテンツ内のTYPO3内部リンクを解決する
function resolveTypo3Links(html, urlMap, fileMap) {
  // Replace page links
  let resolved = html.replace(
    /t3:\/\/page\?uid=(\d+)/g,
    (match, uid) => urlMap[uid] || '/404'
  );
  
  // Replace file links
  resolved = resolved.replace(
    /t3:\/\/file\?uid=(\d+)/g,
    (match, uid) => fileMap[uid] || ''
  );
  
  return resolved;
}

TYPO3マイグレーション代理店を評価する方法

すべての代理店が等しく作成されるわけではありません。ここで何を探すかです:

TYPO3内部を知るべき

明白に聞こえるかもしれませんが、多くの代理店はあなたのサイトをフロントエンドを見て、それを再作成することによってマイグレーションしようとしますが、実際にはバックエンドデータモデルを理解していません。彼らに尋ねてください:

  • pagestt_contentの違いを説明できますか?
  • sys_file_referenceの仕組みを知っていますか?
  • TYPO3 Workspacesを扱ったことはありますか?
  • TypeScriptを書くことができますか?(彼らがそれを嫌っていても、彼らはそれを理解する必要があります。)

対象プラットフォームの専門家であるべき

同様に重要――彼らは行っている場所での深い専門知識が必要です。「Reactを学んでいる」TYPO3ショップはあなたのフロントエンドを再構築する人ではありません。

Social Animalでは、当社の中核専門知識はヘッドレスCMS開発にあります。対象プラットフォームを完全に知っています、なぜなら私たちは毎日それで構築しているからです。

文書化されたマイグレーションプロセスがあるべき

マイグレーション方法論を尋ねてください。次のようなことをカバーする必要があります:

  1. 発見と監査
  2. 対象プラットフォーム用のコンテンツモデリング
  3. データ抽出と変換スクリプト
  4. URLマッピングとリダイレクト戦略
  5. フロントエンド開発
  6. コンテンツの検証とQA
  7. SEO検証
  8. ゴーライブと監視

彼らが詳細でこれらのフェーズをあなたに歩むことができない場合、彼らは即席でやっています。

赤旗

  • 「コンテンツをエクスポートしてインポートするだけです」――それは決してそれほど単純ではありません
  • SEO保存についてのメンションはありません
  • 発見フェーズなしの固定価格見積もり
  • 特定のTYPO3バージョンの経験はありません
  • 彼らはあなたに前のTYPO3マイグレーションプロジェクトを見せることができません

マイグレーションのタイムライン及びコスト予想

現実の数字を話しましょう。これらは2025年のヨーロッパ市場の中規模エンタープライズサイト(500~2,000ページ)に基づいています。

フェーズ 期間 コスト範囲(EUR)
発見と監査 2~4週間 €8,000-15,000
コンテンツモデリング及び戦略 2~3週間 €6,000-12,000
データマイグレーションスクリプト 3~6週間 €12,000-25,000
フロントエンド開発 6~12週間 €25,000-60,000
統合開発 2~6週間 €8,000-25,000
QAとコンテンツ検証 2~4週間 €6,000-15,000
SEO検証とゴーライブ 1~2週間 €4,000-8,000
合計 18~37週間 €69,000-160,000

これらの数字は人々を怖がらせます。しかし、さらに3~5年間TYPO3に留まるコストと比較してください:開発者コスト、ホスティング、開発速度の低迷による見落とされた機会。マイグレーションは通常18~24ヶ月以内に自分自身のために支払います。

あなたの状況に基づいてより具体的な見積もりについては、当社にお問い合わせください、無料の初期評価を実行します。

マイグレーション中のSEO保存

これはマーケティングディレクターを夜寝かせない部分で、当然です。未熟なマイグレーションは何年ものSEO投資を破壊することができます。

譲歩不可能なチェックリスト

  1. 完全なURL在庫 ――Screaming FrogまたはSitebulbを使用してあなたの現在のサイトをクロールしてください。すべてのURL、ステータスコード、タイトルタグ、メタディスクリプション、および正規タグをエクスポートしてください。

  2. 1対1のURLマッピング ――すべての古いURLは301リダイレクトを介して新しいURLを指す必要があります。例外なし。

  3. ページ上のSEO要素を保存 ――タイトルタグ、メタディスクリプション、見出し構造、画像のaltテキスト、および構造化データはすべてマイグレートする必要があります。

  4. 内部リンク監査 ――コンテンツ内のすべての内部リンクはリダイレクトに依存せず、新しいURLを指すようにアップデートする必要があります。

  5. XMLサイトマップ ――すぐに新しいサイトマップを生成し、Google Search Consoleに送信してください。

  6. 90日間監視 ――最初の2週間はGoogle Search Consoleで毎日見て、その後3ヶ月間週1回見てください。クロールエラー、インデックス作成の問題、およびランキング変動を早期に検出します。

現実

完璧な実行でさえ、マイグレーション後の最初の2~4週間内に検索ランキングの10~20%の一時的な低下が予想されます。Googleは再度クロールして再評価する必要があります。あなたがすべてを正しく行った場合、ランキングは回復し、通常6~8週間以内に改善されます。特に新しいサイトが高速化している場合。

ケーススタディ:実際のマイグレーションの様子

ここは実際のプロジェクトに基づいた複合的な例を説明します(機密性のために詳細が変更されています)。

状況: TYPO3 v9サイトを持つドイツの製造会社。4言語(DE、EN、FR、IT)の1,200ページ。news拡張機能の重い使用、カスタム商品カタログ拡張機能、リード生成フォーム用のpowermail。編集体験に不満を持つ3人のコンテンツエディタ。

決定: Storyblok(ヘッドレスCMS) + Next.jsへマイグレーション。

何が起きたか:

  • 発見(3週間): 完全なコンテンツモデルを監査し、14の異なるコンテンツタイプを特定し、47のTYPO3バックエンドレイアウトとコンテンツ要素構成をマップし、すべての統合をドキュメント化しました。

  • コンテンツモデリング(2週間): Storyblokコンテンツモデルを設計しました。14コンテンツタイプを9に削減し、類似したパターンを統合することによって。エディタがStoryblokのビジュアルエディタでプレビューできたビジュアルコンポーネントライブラリを作成しました。

  • データマイグレーション(5週間): すべてのコンテンツテーブル用のPython抽出スクリプトを構築しました。最も難しい部分は?商品カタログ拡張機能が12のテーブルと循環参照を持つカスタムデータベーススキーマを使用していました。 だけのためのETLパイプラインを書いました。

  • フロントエンド(10週間): Tailwind CSSを使用してNext.jsでフロントエンド全体を再構築しました。Lighthouseスコアは平均45(TYPO3)から94(Next.js)に向上しました。モバイルパフォーマンスは劇的に改善されました。

  • QA(3週間): コンテンツエディタはすべての言語のすべてのページを検証しました。23の破損した内部リンクと8つの欠落画像参照を見つけて修正しました。

  • ゴーライブ: リダイレクトマップをデプロイしました(言語ごとに1,200+エントリ)。Search Consoleを監視しました。ランキングは1週間目で12%低下し、4週間目で完全に回復し、8週間目までに15%改善されました。

合計期間: 24週間。合計コスト: €115,000。年間ホスティングとメンテナンス節約: €28,000。エディタの満足度: 圧倒的。

FAQ

典型的なTYPO3マイグレーションにはどのくらいの時間がかかりますか? 中規模サイト(500~2,000ページ)の場合、キックオフからゴーライブまで4~9ヶ月と予想してください。最大の変動因は言語の数、カスタム拡張機能、統合です。シンプルな単一言語パンフレットサイトは8~12週間で完成できます。複雑なワークフローを持つ大規模マルチサイトTYPO3インストールは12ヶ月以上かかることができます。

TYPO3をWordPressにマイグレーションできますか? はい。それは、より一般的なマイグレーションパスの1つです。特に小さな組織にとってです。WordPressには多くの大きな開発者エコシステムとより低いメンテナンスコストがあります。ただし、TYPO3のコンテンツ要素モデルを正しく処理するマイグレーションを確保したい――TYPO3の構造化されたコンテンツアプローチはWordPressのデフォルトブロックエディタより粒度が細かいです。最新のフロントエンドを使用したヘッドレスCMSとしてのWordPressを考慮してください。最高の長期アーキテクチャの場合。

マイグレーション中にGoogleランキングを失いますか? 最初の2~4週間で10~20%の一時的な低下が見られるでしょう。正しい301リダイレクトマッピング、保存されたメタデータ、そしてより高速な新しいサイトを使用してください、ランキングは通常4~8週間以内に回復し、多くの場合改善されます。鍵は完全なURLマッピング戦略を持つことと起動後すぐにSearch Consoleを監視することです。

TYPO3からマイグレーションするコストはいくらですか? ヨーロッパ市場(2025年)では、率直なサイトの場合€40,000-80,000、複数の言語、カスタム拡張機能、統合を持つ複雑なエンタープライズインストールの場合€80,000-200,000+を予想してください。マイグレーション投資の計算時のROI時の開発者コストとホスティングの年間節約を考慮してください――ほとんどの組織は18~24ヶ月以内にマイグレーション投資を回収します。詳細なガイダンスについては、価格ページをチェックしてください。

TYPO3をアップグレードするか、別のプラットフォームにマイグレーションするべきですか? TYPO3 v10またはv11にいて、あなたのチームがプラットフォームに満足している場合、v13 LTSへのアップグレードは理にかなっているかもしれません。しかし、v8またはv9(両方のライフエンド)にいる場合、アップグレード努力はほぼフルマイグレーションと同じくらいです。そして、あなたはまだ縮小する開発者プールと高いメンテナンスコストを扱う必要があります。ほとんどの組織では、非常に古いバージョンからアップグレードするよりもマイグレーションが財務上より有意義です。

TYPO3マイグレーション中にTYPO3拡張機能はどうなりますか? すべての拡張機能は対象プラットフォームで同等のソリューションが必要です。newspowermailsolrなどの人気のある拡張機能には、ほとんどのプラットフォームで確立された代替手段があります。カスタム拡張機能は新しいプラットフォームでのカスタム開発が必要です。良いマイグレーション代理店はすべての拡張機能を発見中に監査し、それぞれに対して具体的な置き換え戦略を提案します。

TYPO3からの段階的マイグレーションを行うことができますか? もちろんです。それは多くの場合、大規模サイトの賢い方法です。TYPO3と新しいプラットフォームを並行して実行でき、セクションを段階的にマイグレーションします。特にヘッドレスアーキテクチャで実用的です。ここで、逆向きプロキシルールを使用してさまざまなセクションを異なるバックエンドから提供できます。リスクを低減しますが、全体的なタイムラインを延長し、インフラストラクチャの複雑さを増加させます。

マイグレーション中にTYPO3の多言語コンテンツを処理するにはどうしたらよいですか? TYPO3の翻訳オーバーレイシステムは、マイグレートするのが最もトリッキーな側面の1つです。各対象プラットフォームはローカライゼーションを異なる方法で処理します。Storyblokはフィールドレベルの翻訳を使用し、Contentfulはロケールベースのエントリを使用し、Sanityはドキュメントレベルの翻訳を使用します。マイグレーション代理店はTYPO3の「接続」と「フリー」翻訳モードの両方を理解し、あなたのサイトが使用する特定のアプローチを処理する抽出スクリプトを設計する必要があります。多言語サイト用の予算の追加時間――それはいつも予想より複雑です。