gotohayato.com

moon indicating dark mode
sun indicating light mode

脱 Drupal 7 の進め方

2019/12/21CMSDrupal 7

Drupal 7 から他のプラットフォームに移行する方法についてまとめました。

Drupal 7 は公式のメンテナンスが 2021 年 11 月に終了することが決まったため、 2020 〜 2022 年の間に脱 Drupal 7 を必要とするサイトがたくさん出てくるものと思います。 drupal.org の公式の統計 によると 2020 年の年始の時点で 70 万以上のサイトが Drupal 7 を使っているので、単純計算でも月々数万サイトのペースで脱 Drupal 7 が進むことになるでしょう。

「外部に作ってもらった Drupal 7 ベースのサイトを別のプラットフォームに移行したい」「移行作業は現行サイトの制作会社と別会社か自社で行いたい」というような方は参考にしてみてください :D

ということで以下進め方です。

全体の流れ

おおよそ以下の流れで進めます。

  1. 現状分析
  2. 移行先の調査
  3. 移行先の決定
  4. 移行戦略の策定
  5. 移行の実施

1. 現状分析

最初に Drupal 7 で動いているサイトの分析を行います。 移行先を検討・選定する上で重要になるポイントには以下のようなものがあります。

  • サイト特性
    • データモデル
    • 機能
    • サイト構成
    • ページ数
  • 背景
    • サイトの位置づけ
    • サイトとビジネス上の課題
    • ウェブ活用戦略
    • 保有能力
    • 予算

「データモデル」については、 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 」と捉えるか積極的に「サイト改善の機会」と捉えるかです。 脱 Drupal ではなくサイト改善の機会と考えるのであれば、 Drupal と同等の別 CMS への乗り換えが必ずしもベストな選択とはかぎりません。 Drupal 7 を採用した頃とはウェブ環境は大きく変わっており、今日では

  • より自由度の高いウェブアプリケーションフレームワーク
  • パフォーマンスや UX/DX に優れた JAMStack
  • コスト面に有利なクラウドサービス

等々、 CMS 以外に有力な選択肢がいくつもあります。 Drupal 7 のメンテナンス終了をよい機会と捉えウェブをこれまで以上に活用していこうと考えるなら、 CMS 以外の選択肢もぜひ見ておくべきです。

逆に、労力・コストを極力抑えて「脱 Drupal 」だけを行いたいのであれば、 Drupal と同種の CMS を主な移行先候補としてあげるのが手っ取り早くて確実です。

3. 移行先の決定

現状分析と移行先の調査ができたら、そこから得られた情報を総合して、移行先をひとつに決定します(複数のプラットフォームを併用する場合は複数個に決定します)。

おそらく大半の中小規模サイトは WordPress を選べばまず間違いないでしょう。 現行サイトが Drupal で相当マニアックなことをしているのでなければ、 Drupal から WordPress への移行が問題になるようなケースはそうありません(ただし「 WordPress を正しく使える制作会社に頼む」という条件付きです)。

WordPress はメジャーなオープンソース CMS の中でほぼ唯一シェアを伸ばし続けている CMS です。 メンテナンスも活発に行われており、予想外に廃れてしまったり不可抗力で使えなくなったりする可能性が低く、「今最も安心して長く使い続けられる CMS 」と言ってもよいでしょう。

ただし前述のとおり、 Drupal 7 の終了を機にこれまで以上にウェブを積極活用しようと考えるのなら、 CMS 以外の選択肢も見ておくべきです。 さまざまな候補を検討した末に最終的に WordPress を選ぶことになったとしても、 CMS 以外の実用的な選択肢を持っておくことはその後のウェブ活用戦略に必ず役立ちます。

4. 移行戦略の策定

移行先が具体的に決まったら、実際の移行作業の方針――「移行戦略」を考えます。

CMS の核はやはり「コンテンツ管理」なので、移行戦略においても Drupal 7 で管理していた「コンテンツ」と「コンテンツ周りの仕組み」をどう移行するかが主な焦点になるケースが多いでしょう。

コンテンツそのものの移行は「手作業かプログラムを使って自動化するか」が最も大きな選択肢になります。 例えば、移行対象となるエンティティ(= Drupal における広義のコンテンツ)の数が高々 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 の進め方についてでした。

関連記事


後藤隼人
個人事業でウェブ開発やマーケティングをしています。
GitHub