脱 Drupal 7 の進め方
Drupal 7 から他のプラットフォームに移行する方法についてまとめました。
Drupal 7 は公式のメンテナンスが 2021 年 11 月に終了することが決定したため、 2020 〜 2022 年の間に脱 Drupal 7 を必要とするサイトがたくさん出てくるものと思います。 drupal.org の公式の統計 によると 2020 年年始の時点で 70 万以上のサイトが Drupal 7 を使っているので、単純計算で考えても月々数万サイトのペースで脱 Drupal 7 が進むことでしょう。
「外部に作ってもらった Drupal 7 サイトを別のプラットフォームに移行したい」「移行は Drupal 7 のときの制作会社と別会社または自社で行いたい」という方は参考にしてみてください :D
ということで以下進め方です。
全体の流れ
おおよそ以下の流れで進めます。
1. 現状分析
最初に Drupal 7 で動いている現行サイトの分析を行います。 移行先を検討・選定する上で重要になるポイントには以下のようなものがあります。
- サイト特性
- データモデル
- 機能
- サイト構成
- ページ数
- 背景
- サイトの位置づけ
- サイトとビジネス上の課題
- ウェブ活用戦略
- 保有能力
- 予算
「データモデル」については、 Drupal の作法に従って作られた筋のよいサイトであれば、大部分がエンティティ（＝ Drupal における広義のコンテンツのこと）として実装されているはずです。
その場合、例えばコアの entity_get_info() 関数を使えばエンティティのメタ情報（≒データモデル）をまとめて確認できるので、まずはこれでデータモデルの概要を把握します。
$entity_types = entity_get_info();
// どのようなエンティティタイプがあるのかを確認
echo implode(PHP_EOL, array_keys($entity_types)));
// =>
// node
// redirect
// file
// taxonomy_term
// taxonomy_vocabulary
// user
// rules_config
// 各エンティティタイプにどのようなバンドルがあるのかを確認
foreach (entity_get_info() as $name => $info) {
echo $name . ':' . PHP_EOL;
echo implode(PHP_EOL, array_keys($info['bundles']));
echo PHP_EOL . PHP_EOL;
}
// =>
// node:
// webform
// page
// article
//
// redirect:
//
//
// file:
// file
//
// taxonomy_term:
// tags
//
// taxonomy_vocabulary:
// taxonomy_vocabulary
//
// user:
// user
//
// rules_config:
// rules_config「機能」については、カスタムモジュールで独自に実装されたものだけでなく、コミュニティ提供のモジュールで実装されたものも漏らさずに洗い出すようにします。 Drupal 7 にはコミュニティ提供の高品質なモジュールがたくさんあったため、サイトで利用されるモジュールは独自開発のものよりもコミュニティ提供のものの方が多いことが一般的です。
2. 移行先の調査
現状分析がひととおり完了したら、移行先の調査を行います。 具体的には、「どのような選択肢があるのか」と「各選択肢にはどのような特徴があるのか」を調べます。
ここでポイントとなるのは「どのような基本姿勢で移行を行うか」です。 移行を単なる「脱 Drupal 」と捉えるか積極的な「サイト改善の機会」と捉えるかで適切な移行先というのは変わってきます。
「サイト改善の機会」と捉えるのであれば、別の CMS への乗り換えが必ずしもベストな選択になるとはかぎりません。 あなたの会社が Drupal 7 を採用した頃とはウェブ環境は大きく変わっており、今日では CMS の他にも
- より自由度の高いウェブアプリケーションフレームワーク
- パフォーマンスや UX/DX に優れた JAMStack
- コスト面に有利なクラウドサービス
等の選択肢が用意されています。
今後ウェブをより積極的に活用していきたいとお考えなら、ぜひ CMS 以外の選択肢も見ておくべきです。
逆に、労力とコストを極力抑えてとりあえず「脱 Drupal 」だけを行いたいのであれば、 Drupal と同種の CMS だけを移行先候補とするのが手っ取り早くて確実です。
3. 移行先の決定
現状分析と移行先の調査ができたら、得られた情報を総合して移行先をひとつに決定します（複数のプラットフォームを併用する場合は複数個に決定します）。
おそらく大半の中小規模サイトは WordPress を選べばまず間違いないでしょう。 現行サイトが Drupal を使って相当マニアックなことをしているわけでなければ、 Drupal から WordPress への移行はさほど難しいことではありません（ただし「 WordPress を正しく使える制作会社に頼む」という前提条件付きです）。
WordPress は世界的に有名なオープンソース CMS の中でシェアを維持できているほぼ唯一の CMS です。 メンテナンスも問題なく行われているため、予想外に廃れたり使えなくなったりするリスクが非常に低く、今「最も安心して長く使い続けられる CMS 」と言えるでしょう。 その意味で WordPress は Drupal 8 / 9 よりも確実な移行先です。
ただし繰り返しになりますが、 Drupal 7 の終了をサイト改善のよい機会と捉えるなら、 CMS 以外の選択肢も見ておくべきです。 さまざまな候補を検討した末に最終的に WordPress を選ぶことになったとしても、 CMS 以外の実用的な選択肢を把握しておくことはその後のウェブ活用戦略に必ず役立ちます。
4. 移行戦略の策定
移行先が具体的に決まったら、実際の移行作業の方針――「移行戦略」を考えます。
CMS の核はやはり「コンテンツ管理」なので、移行戦略においても Drupal 7 で管理していた「コンテンツ」と「コンテンツ周りの仕組み」をどう移行するかが主な焦点になるケースが多いでしょう。
コンテンツそのものの移行については「手作業で行うかプログラムを使って自動化するか」が大きな選択肢になります。 例えば、移行対象のエンティティの数が高々 50 個ほどであれば、わざわざプログラムを書くよりも地道に手作業で移行した方がすばやく確実な場合が多いと思います。 逆に移行が必要なエンティティの数が 50 〜 100 個を越えてくる場合はプログラムを書いた方が効率的で確実かもしれません（ 50 〜 100 という数は適当な目安です。閾値はデータモデルやデータの利用方法によって変わります）。
ちなみに、 Drupal のデータベーステーブルはフィールド単位で細かく分かれているため、ひとまとまりのコンテンツ（例えば 1 記事分のデータ）であってもシンプルな SQL で抽出することができません。 見た目がシンプルなページでも意外と複雑な SQL が実行されているので、 Drupal のデータの抽出には原則 SQL は使わず Drupal の API を通して行うのが原則です。
もうひとつちなみに、 Drupal の API を通したデータ抽出にはいくつかの方法がありますが、コマンドラインでできるとスムーズです。 私が自分用に書いて実際に使ったデータエクスポート用のコマンドを提供する Drupal モジュールを GitHub に置いているので興味がある方は参考にしてみてください。
5. 移行の実施
移行戦略が決まったら、後は実際に手を動かす移行作業を行います。
基本的には粛々と作業をするのみですが、作業をしている中で新たなデータや機能が見つかることもあるでしょう。 そのようなときには前のフェーズといきつ戻りつしながらの作業が必要なので、「必ずしもウォーターフォール型で移行が進むものではない」という共通認識をステークホルダー間であらかじめ共有しておくのがよいと思います。
Drupal はプログラミング言語の PHP で書かれているため、同じ PHP で書かれた CMS （ WordPress 等）に移行すればコストを抑えられるのではないかと考える方もいますが、そのようなことはほとんどありません。 よっぽど複雑なビジネスロジックがあり、最初から移行を想定した設計で作られている場合は別ですが、そのようなケースは現実にはほぼ無いと思っておくとよいと思います。
実際の移行作業が完了し、移行のヌケ・モレ・間違いや機能のバグ等が修正できたら、一連の移行作業は完了です。
……
ということで、脱 Drupal 7 の進め方についてでした。
追記
移行先を具体的に WordPress にしたときの説明記事を書きました。 興味のある方はぜひ参考にしてみてください。
Drupal 開発会社を選ぶときのポイントをまとめました。
Drupal 7 サイトから他のプラットフォームに載せ替えるときに載せ替え先に決め方について書きました。