TYPO3マイグレーションチェックリスト:開発者向けステップバイステップガイド
TYPO3マイグレーションを成功させるチェックリスト：開発者向けステップバイステップガイド
十分なTYPO3マイグレーションを経験してきたので、スムーズな移行と6ヶ月の悪夢の違いは準備にかかっていることを知っています。TYPO3は強力なCMSです。1998年から存在しており、特にDAACH地域の非常に複雑なエンタープライズサイトを運営しています。しかし、メジャーなTYPO3バージョン間のアップグレード、または完全に異なるプラットフォームへの移行など、マイグレーションの時間が来たとき、計画がなければプロセスはすぐに醜くなる可能性があります。
これは、最初のTYPO3マイグレーションの前に誰かが私に渡してくれたらよかったと思っているチェックリストです。理論的ではありません。ここの項目はすべて、それをスキップするとどうなるかを見てきたから存在しています。
目次
- 現在のTYPO3インストレーションの評価
- マイグレーション戦略の定義
- コンテンツ監査とデータマッピング
- 技術インフラの準備
- 拡張機能と統合インベントリ
- SEO保護計画
- マイグレーション実行フェーズ
- テストと品質保証
- マイグレーション後のモニタリング
- 一般的なTYPO3マイグレーションの落とし穴
- FAQ
現在のTYPO3インストレーションの評価
何かに触れる前に、何と取り組んでいるのかを正確に理解する必要があります。これは明らかに思えます。そうではありません。本番環境で実行されているTYPO3バージョンさえ知らなかったチームを見てきました。
バージョンと環境監査
ここから始めてください：
# TYPO3バージョンを確認
php typo3/sysext/core/bin/typo3 --version
# またはバックエンドで確認: Help > About TYPO3
以下を文書化します：
- TYPO3バージョン（メジャーとマイナー — 例：TYPO3 v11.5.38 LTS）
- サーバー上で実行されているPHPバージョン
- データベースタイプとバージョン（MySQL、MariaDB、PostgreSQL）
- Webサーバー（Apache、Nginx）
- Composerベースまたはクラシックインストレーション — これは非常に重要です
- インストレーション内のサイト/ドメインの数（マルチサイト設定は複雑さが増します）
- ページツリー内の総ページ数とコンテンツ要素数
ユーザーとパーミッションマッピング
TYPO3のバックエンドユーザーとグループのパーミッションシステムは悪名高いほど粒度が細かいです。be_usersとbe_groupsテーブルをエクスポートして、以下を文書化します：
- 存在するバックエンドユーザーの数
- 構成されているカスタムパーミッション
- 管理者アクセス権を持つユーザー
- カスタムTSconfigオーバーライド
異なるCMSに移行する場合は、これらのロールを新しいシステムのパーミッションモデルにマップする必要があります。TYPO3バージョンをアップグレードする場合、一部のパーミッション構成を更新する必要があるかもしれません。
TypoScriptと構成の複雑性
TypoScript設定の簡単な監査を実行します：
# TypoScriptファイルをカウント
find . -name '*.typoscript' -o -name '*.ts' | wc -l
# setup.txtとconstants.txt（レガシー形式）を確認
find . -name 'setup.txt' -o -name 'constants.txt' | wc -l
数百のTypoScriptファイルと深くネストされた構成がある場合は、マイグレーションに時間がかかることを予想してください。15年間進化した10,000行以上のTypoScriptを持つTYPO3インストレーションを見たことがあります。これは週末のプロジェクトではありません。
マイグレーション戦略の定義
基本的に3つのタイプのTYPO3マイグレーションがあり、他のすべての前に決定する必要があります。
| マイグレーションタイプ | 選択するとき | 複雑性 | 典型的なタイムライン |
|---|---|---|---|
| TYPO3バージョンアップグレード（例：v10 → v12） | TYPO3に留まりたい場合 | 中～高 | 4～12週間 |
| TYPO3からヘッドレスCMS（例：Contentful、Strapi、Sanity） | 最新フロントエンド柔軟性が欲しい場合 | 高 | 8～20週間 |
| TYPO3から別の従来型CMS（例：WordPress、Drupal） | 別のモノリシックCMSが欲しい場合 | 中 | 6～16週間 |
| TYPO3からヘッドレスTYPO3（EXT:headlessを使用） | TYPO3バックエンドと最新フロントエンドが欲しい場合 | 中 | 6～14週間 |
TYPO3内でのアップグレード
TYPO3に留まる場合、公式なアップグレードパスでは各LTSバージョンをステップスルーする必要があります。v8からv12に直接ジャンプすることはできません。まあ、できます。やめてください。
2025年時点での推奨パス：
- v8 LTS → v9 LTS → v10 LTS → v11 LTS → v12 LTS → v13 LTS
TYPO3 v13 LTSは2024年後半にリリースされ、現在のロングタームサポートバージョンです。TYPO3 v12 LTSは拡張ロングタームサポート（ELTS）プログラムを通じて2026年4月までセキュリティアップデートを受け取ります。
TYPO3からの移行
ヘッドレスアーキテクチャに移行しようとしている場合 — 実は、多くのチームにとってこれは理にかなっています — フロントエンドフレームワークのオプションを評価する必要があります。私たちはNext.jsとAstroをヘッドレスCMSプラットフォームと組み合わせたフロントエンド層として広範に機能してきました。
重要な質問は：あなたのコンテンツモデルはTYPO3の複雑性を正当化していますか？200ページのマーケティングサイトを実行している場合、TYPO3はおそらくやり過ぎです。複雑なワークフローを伴うマルチ言語エンタープライズポータルを実行している場合、どこに行こうとしても、マイグレーション中のコンテンツモデリング作業は重大です。
コンテンツ監査とデータマッピング
ここがマイグレーション成功の分かれ目です。コンテンツです。
データベースのエクスポートと分析
TYPO3は主にこれらのテーブルにコンテンツを保存します：
pages— ページツリー構造tt_content— コンテンツ要素sys_fileとsys_file_reference— メディアアセット（FAL）sys_category— カテゴリーtx_news_domain_model_news— ニュース拡張を使用している場合
コンテンツをエクスポートして実数を取得します：
-- ドキュメントタイプ別ページをカウント
SELECT doktype, COUNT(*) as count
FROM pages
WHERE deleted = 0
GROUP BY doktype;
-- コンテンツ要素タイプ別をカウント
SELECT CType, COUNT(*) as count
FROM tt_content
WHERE deleted = 0 AND hidden = 0
GROUP BY CType
ORDER BY count DESC;
-- ファイル参照をカウント
SELECT COUNT(*) FROM sys_file WHERE missing = 0;
コンテンツタイプマッピング
すべてのTYPO3コンテンツタイプ（CType）をターゲットシステムの同等物にマップするスプレッドシートを作成します。遭遇するであろう一般的なTYPO3コンテンツタイプ：
text、textmedia、textpic— 標準テキストコンテンツimage— 画像ギャラリーtable— データテーブルbullets— リストuploads— ファイルリストhtml— 生のHTML（これらはマイグレーション中に常に楽しみです）list— プラグインコンテンツ（ここが複雑になります）- 拡張からのカスタムコンテンツタイプ
list CTypeはトリッキーなものです。これはプラグインコンテンツを表します — ニュースリスト、フォーム、カスタム機能 — そして個別に注目する必要があります。
マルチ言語コンテンツ
TYPO3はコネクテッドモード（翻訳がデフォルト言語レコードにリンクされている場所）またはフリーモードを通じて翻訳を処理します。サイトがどのアプローチを使用しているかを確認します：
-- 翻訳設定を確認
SELECT sys_language_uid, COUNT(*)
FROM pages
WHERE deleted = 0
GROUP BY sys_language_uid;
8言語あり、接続モード翻訳を持つ場合、マイグレーションデータマッピングは8倍複雑になりました。それに応じて計画します。
技術インフラの準備
サーバー要件
TYPO3 v13にアップグレードする場合、2025年時点での最小要件：
- PHP 8.2以上（8.3推奨）
- MySQL 8.0+またはMariaDB 10.4+またはPostgreSQL 12+
- PHP メモリ制限最小256MB（512MB推奨）
- Composer 2.7+
ステージング環境
決して — そして十分に強調することはできません — 本番環境でマイグレーションを直接実行しないでください。設定します：
- 本番環境をミラーリングするステージング環境
- 別のデータベースコピー
- 同一のPHPとサーバー構成
- ファイルストレージアクセス（またはfileadminのコピー）
# 本番データベースをステージングにクローン
mysqldump -u root -p production_db | mysql -u root -p staging_db
# fileadminをrsync
rsync -avz production:/var/www/html/fileadmin/ staging:/var/www/html/fileadmin/
バックアップ戦略
マイグレーション作業が始まる前に：
- タイムスタンプ付き完全なデータベースダンプ
- fileadmin、typo3conf、カスタム拡張ディレクトリを含む完全なファイルシステムバックアップ
- LocalConfiguration.phpとAdditionalConfiguration.phpの設定をドキュメント化
- TypoScriptテンプレートをエクスポート
これらのバックアップをマイグレーション環境から完全に分離した場所に保存します。私は少なくとも3つのコピーを保管しています。
拡張機能と統合インベントリ
TYPO3拡張機能はおそらくマイグレーションの頭痛の最大の源です。これらに対処する方法を説明します。
インストール済み拡張機能をすべてリスト
# Composerベースのインストレーション
composer show | grep typo3
# またはPackageStates.phpをチェック
cat typo3conf/PackageStates.php
各拡張機能を分類
すべての拡張機能について、次を決定します：
| カテゴリー | 必要なアクション | 例 |
|---|---|---|
| コアシステム拡張 | 通常はアップグレードウィザードで処理 | fluid_styled_content、form |
| メンテナンスされているTER拡張 | ターゲットバージョンとの互換性を確認 | news、powermail、solr |
| 放棄されたTER拡張 | 置き換えまたはカスタムソリューションを見つけます | 様々 |
| カスタムサイト拡張 | 手動マイグレーション/書き直しが必要 | あなたのsite_package |
| 商用拡張 | マイグレーションパスについてベンダーに連絡 | in2publish、様々 |
一般的な拡張機能マイグレーションパス
ほぼすべてのTYPO3マイグレーションで見かける拡張機能：
- EXT:news（Georg Ringer） — バージョン互換性を確認します。v11+はTYPO3 v12/v13で動作
- EXT:powermail — 人気のあるフォーム拡張。代替品にはEXT:form（コア）が含まれます
- EXT:realurl — TYPO3 v9以降非推奨。コアルーティングで置き換え
- EXT:tt_address — 通常、素直なアップグレード
- EXT:gridelementsまたはEXT:flux — これらのレイアウト拡張は、アップグレード中に最も多くの痛みを引き起こします。TYPO3から移行している場合、グリッド構造からコンテンツを抽出することを予期します。
SEO保護計画
このセクションをスキップすると、企業は有機トラフィックで数百万ドルを失った可能性があります。その見出しにならないでください。
URLマッピング
- Screaming Frog、Sitebulb、またはAhrefsで完全な現在のサイトをクロール
- すべてのURL をエクスポート（大規模なTYPO3サイトでは数千を予想）
- 完全な1対1 URLマッピング文書を作成
- 上位100ページを有機トラフィック別に特定します（Google Search Consoleで確認）
- トラフィックの多いページのリダイレクト精度を優先します
リダイレクト実装
# .htaccessリダイレクトの例
RedirectPermanent /old-typo3-path/page.html /new-path/page
RedirectPermanent /index.php?id=123 /about-us
大規模なリダイレクトについては、.htaccessに数千のルールを詰め込むのではなく、リダイレクト管理ソリューションを使用してください。最新のスタックに移行する場合、ほとんどのフレームワークと ホスティングプラットフォーム（Vercel、Netlify）にはリダイレクト構成ファイルがあります。
メタデータマイグレーション
TYPO3はSEOメタデータをpagesテーブルに保存します（EXT:seoがv9でコア拡張になったため）：
seo_titleog_title、og_description、og_imagetwitter_title、twitter_description、twitter_imagecanonical_linkno_index、no_follow
すべてをエクスポートしてマップしていることを確認します。500ページ全体でメタディスクリプションを失うことは、回避可能な災害です。
マイグレーション実行フェーズ
TYPO3バージョンアップグレード
各バージョンステップでこのシーケンスに従います：
- Composer依存関係を更新して次のLTSバージョンに
- アップグレードウィザードを実行し、Install Tool（Admin Tools > Upgrade）で
- データベースアナライザーを実行してスキーマを更新
- 非推奨ログを確認して問題を確認
- 拡張機能を更新して互換性のあるバージョンに
- TypoScriptを修正して非推奨と破壊的な変更に対応
- 次のバージョンステップに移る前に徹底的にテスト
# Composerを介してTYPO3コアを更新
composer require typo3/cms-core:^13.4 typo3/cms-backend:^13.4 \
typo3/cms-frontend:^13.4 --with-all-dependencies
# CLIでアップグレードウィザードを実行
php typo3/sysext/core/bin/typo3 upgrade:run
# データベーススキーマ更新
php typo3/sysext/core/bin/typo3 database:updateschema
プラットフォームマイグレーション
ヘッドレスCMSアーキテクチャに移行している場合、実行フェーズは異なります：
- 新しいCMSを設定してコンテンツモデルを構成
- マイグレーションスクリプトを構築してTYPO3データを変換
- バッチでコンテンツを移行 — 最もシンプルなコンテンツタイプから始めます
- メディアアセットを処理 — fileadminからダウンロードして新しいアセットストレージにアップロード
- 選択したフレームワークでフロントエンドを構築
- ゴーライブの前にリダイレクトを実装
- DNSカットオーバーとモニタリング
実際のデータ変換については、通常、TYPO3データベースから読み取り、新しいCMS APIを通じて新しいCMSにコンテンツをプッシュするPythonまたはNode.jsスクリプトを書きます：
import mysql.connector
import requests
# TYPO3データベースに接続
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():
# 変換して新しいCMSにプッシュ
payload = {
"title": page["title"],
"slug": page["slug"],
"seoTitle": page["seo_title"] or page["title"],
"description": page["og_description"] or page["description"]
}
# 新しいCMS APIにPOST
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}")
テストと品質保証
自動テストチェックリスト
- すべてのページが200ステータスコードを返す
- リンク切れがない内部リンク
- すべての画像が正しく読み込まれる
- フォームが正常に送信される
- 検索機能が機能する
- マルチ言語切り替えが機能する
- 古いURLからのリダイレクトが機能する
- Canonical URLが正しい
- XMLサイトマップが有効でアクセス可能
- robots.txtが適切に構成されている
- SSLサーティフィケートが有効
- ページロード時間が許容範囲内（3秒以下）
ビジュアル回帰テスト
Percy、BackstopJS、またはPlaywrightを使用してビジュアル比較を使用します：
# BackstopJSの例
npx backstop init
# backstop.jsonで シナリオを構成
npx backstop reference # 現在のサイトをキャプチャ
npx backstop test # マイグレーション後に比較
パフォーマンスベンチマーク
マイグレーション前後を測定します。マイグレーションはパフォーマンスを向上させるべきで、低下させるべきではありません。
| メトリック | マイグレーション前ターゲット | マイグレーション後ターゲット |
|---|---|---|
| TTFB | < 800ms | < 200ms |
| LCP | < 2.5s | < 1.5s |
| CLS | < 0.1 | < 0.05 |
| FID/INP | < 200ms | < 100ms |
| PageSpeed スコア | 50-70 | 90+ |
サーバーレンダリングされたTYPO3から静的またはエッジレンダリングされたフロントエンドに移行する場合、これらの数値で劇的な改善を見るべきです。
マイグレーション後のモニタリング
DNSをフリップするときマイグレーションは終わりません。少なくとも30日間、以下を監視します：
- Google Search Console — クロールエラー、カバレッジの問題、インデックス作成の問題を監視します。最初の2週間でいくらかの変動を予想してください。
- アナリティクス — マイグレーション前のベースラインとの週対週のトラフィックパターンを比較します。
- 404エラー — 404のログを設定し、逃した URLのリダイレクトを追加します。
- Core Web Vitals — CrUXまたはアナリティクスプラットフォーム経由で実際のユーザーデータを監視します。
- サーバーログ — 異常なエラーパターンを監視します。
以前のトップ50にあったページでトラフィック低下が20%を超える場合はアラートを設定します。
一般的なTYPO3マイグレーションの落とし穴
これらは、数十回のマイグレーション全体で見た（時には作った）間違いです：
1. ソフト削除レコードを無視する。 TYPO3は実際にレコードを削除するのではなく、deleted=1フラグを使用します。マイグレーションスクリプトはこれらをフィルタリングする必要があります。そうしないと、何年も前に削除されたレコードが数千件インポートされます。
2. ワークスペースを忘れる。 サイトがエディトリアルワークフローのためにTYPO3ワークスペースを使用している場合、エクスポートに下書きコンテンツが混在する可能性があります。常にt3ver_wsid = 0でフィルタリングしてライブコンテンツのみを取得します。
3. RTEコンテンツを過小評価する。 TYPO3のリッチテキストエディターの出力には、カスタムタグ、TYPO3固有の構文を持つ<link>タグ、t3:// URIが含まれる可能性があります。これらすべてを解析して変換する必要があります。
4. ファイル参照を破損する。 TYPO3のFile Abstraction Layer（FAL）はsys_file_referenceを使用してファイルをコンテンツに接続します。「コンテンツレコード上の単純な画像フィールド」ではありません — これはリレーションテーブルです。マイグレーションスクリプトはこれらの参照に従う必要があります。
5. 実際のコンテンツ量でテストしない。 マイグレーションスクリプトは10テストページで完全に機能します。15,000ページ と50,000コンテンツ要素で惨めに失敗します。常にスケーリングでテストします。
マイグレーションを計画していて、これらの落とし穴を避けたい場合、私たちはいくつかのエンタープライズチームをTYPO3マイグレーションを通じてガイドしました — 遠慮なく連絡を取ってください、特定の状況について話し合うことができます。
FAQ
TYPO3マイグレーション は通常どのくらい時間がかかりますか？
これはインストレーションの複雑さに大きく依存します。単一言語サイトの標準拡張機能を持つTYPO3 v11からv13への簡単なアップグレードは4～6週間かかる可能性があります。マルチ言語エンタープライズTYPO3サイトの完全なプラットフォームマイグレーション、カスタム拡張機能を使用することは、簡単に3～6ヶ月かかることができます。コンテンツ監査フェーズだけで大規模サイトの場合、2～4週間かかる可能性があります。
TYPO3LTSバージョンをアップグレード中にスキップできますか？
技術的には、すべきではありません。公式の推奨事項は、各LTSバージョンを順番にアップグレードすることです（v8 → v9 → v10 → v11 → v12 → v13）。これは、各バージョンに特定のステップに対するデータマイグレーションを処理するアップグレードウィザードが含まれているためです。バージョンをスキップすることは、これらのデータマイグレーションが実行されないことを意味し、破損した孤立したデータで終わります。一部のエージェンシーはスキップバージョンアップグレードができると主張していますが、数ヶ月後に浮上する微妙なデータの問題を見てきました。
TYPO3からWordPressに移行すべきですか？
それはあなたのニーズに依存します。WordPressは単純なマーケティングサイトを上手く処理しますが、複雑なマルチ言語要件、粒度の細かいパーミッション、またはエンタープライズワークフローのためにもともとTYPO3を選択した場合、WordPressは後退かもしれません。最新のフロントエンドフレームワークと組み合わせたヘッドレスCMSがより適切な選択肢かもしれないことを検討してください。私たちはヘッドレスCMS開発アプローチについて書いており、エンタープライズCMSプラットフォームを離れるチームにとってしばしばより良い意味を持ちます。
TYPO3マイグレーション中に私のSEOランキングはどうなりますか？
完璧なリダイレクトでさえ、2～6週間のランキング変動を予想してください。Googleは、完全にクロールして再インデックスする時間が必要です。影響を最小限に抑めるために：すべてのURLに301リダイレクトを実装し、元のできるだけ接近してコンテンツ構造を保ち、更新されたサイトマップをすぐに送信し、Google Search Consoleでアドレス変更ツールを使用します（ドメインを変更している場合）。リダイレクトを正しく処理するサイトは通常、4～8週間以内に回復します。
ターゲットプラットフォーム上に存在しないTYPO3拡張機能をどのように処理しますか？
最初に、拡張機能が実際に何をするかを決定します。多くのTYPO3拡張機能は、最新のプラットフォームに組み込まれている機能を提供します（フォームビルダー、SEOツール、リダイレクト管理など）。カスタム機能については、同等のプラグイン/サービスを見つけるか、カスタム機能を構築する必要があります。各拡張機能、その目的、置き換え戦略をリストするスプレッドシートを作成します。
ヘッドレスTYPO3に移行する価値はありますか？
TYPO3ヘッドレス拡張機能（EXT:headless）は、チームがTYPO3バックエンドに満足しているが最新フロントエンドを望む場合の正当なオプションです。これはTYPO3コンテンツをJSON APIとして公開し、Next.js、Nuxt、またはAstroでフロントエンドを構築できます。このアプローチは既存のコンテンツ構造とエディトリアルワークフローを保持しながら、プレゼンテーション層を最新化します。良い中間点ですが、TYPO3バックエンドの維持を意味します。
2025年のTYPO3マイグレーションのコストはいくらですか？
概算数字：中規模サイトのTYPO3バージョンアップグレードは$15,000-$50,000の費用がかかります。ヘッドレスアーキテクチャへの完全なプラットフォームマイグレーションは、コンテンツ量、言語数、カスタム機能、統合複雑性に応じて$40,000-$150,000+の範囲です。これらは小さな数字ではありませんが、古く、セキュリティされていないCMSインストレーションの維持コストと比較してください。詳細については、価格ページで、これらのプロジェクトをどのように構成するかを確認できます。
テンプレートを最初から再構築する必要がありますか？
TYPO3バージョンアップグレードの場合、通常は完全ではありません — しかし、非推奨のViewHelpersと新しいAPIを処理するためにFluidテンプレートを更新する必要があります。プラットフォームマイグレーション場合、はい、新しいフロントエンドを構築しています。良いニュースは、Next.jsやAstroのような最新フレームワークは、Fluid/TypoScript時代よりもパフォーマント性の高いフロントエンドを構築するのに大幅に高速化することです。デザインは同じままにすることができます。実装が変わります。