WordPressサイト移行（AWS→さくら）

この記事は私が管理しているWordPressサイトのホスティング先を、AWS EC2からさくらインターネット（以降「さくら」）のレンタルサーバに移行した際の参考情報を記すものです。

本題に入る前に、私のブログはこのサイト（bills-appworks.net/bills-memo）の他に、WhiteWindというブログサービスにも掲載するようになりました（私の記事エントリ）。現時点では私が開発しているツール「シェルスクリプト実装Blueskyクライアント bsky-sh-cli (Bluesky in the shell)」に関するものが主ですが、このサイトとの使い分けはまだ決めていません。どちらもよろしくお願いいたします。WhiteWindはBlueskyの基盤であるAT Protocolによるサードパーティとしては初のサービスになります（詳細は「WhiteWindをオープンソース化します！！！」を参照）。Blueskyのアカウントがあればすぐに使えますので、ぜひ御利用ください。

本題に戻りますが、この後WordPressサイト移行に関する経緯という名のポエムが続きますので、技術的なことを知りたい方は「2. 構成」まで読み飛ばしてください。

---

目次

• 移行の経緯
• 構成
• 方針
• 手順概要
• 手順詳細
• 参考情報

---

1. 移行の経緯

移行しようとしているWordPressサイトは、最初の構築当時にAWSについて習得し始めた時期で、勉強を兼ねてシングル構成のEC2上にWordPressをインストールして構築しました。

その後別のWordPressコンテンツ（というかこのブログ）を、サーバ費用をケチるために確かApache HTTP Serverのバーチャルホスト機能を使い、ホスティングサーバは同一（の別ディレクトリ）だが別ドメイン（URL）でアクセスすると別のコンテンツ（ディレクトリ）が表示されるようにしました。

さらに数年後、Dockerについて習得し始め、これも勉強を兼ねて2つのWordPressサイトをDockerコンテナベースに再構築しました。確かこの時にEC2を再構築し、OSをAmazon Linux (1)からAmazon Linux 2に移行したかと思います。これが今回の移行元の状態になります。詳細は「2. 構成」に記しています。

このようにして自己技術研鑽を兼ねたサイトの式年遷宮を重ねてきた2024年現在、Amazon Linux 2のEOL（サポート終息）が2025年6月に迫ってきており、何らかのプラットフォーム移行が課題となっていました。

当初は同じAWSのLightsailサービスを利用することを考えていました。これまで技術研鑽を兼ねた運用を続けていましたが、AWSは仕事で使うようになりプライベートでいじる必要性が低下し、IaaSですのでOSパッチより上位のメンテナンスも面倒でした。そこで低レイヤは手をかけなくてよいマネージドサービスへの移行を考え、Lightsailを調べ始めたのですが…あれ？OSの選択がある？それってEOL/EOSで移行が必要になる？…不勉強でこの時初めてLightsailが期待しているようなマネージドサービスではないことに気が付きました。

AWSより以前からホスティングサービス系としてはリムネットやさくらインターネットを利用しており、さくらに関してはレンタルサーバライトプランで塩漬けになっているWeb1.0サイト（CGIベースの掲示板・チャット（！））を保有していました。これらのプロバイダなら契約も楽だしということで、さくらのサービスを調べ始めたところ…WordPressサイト移行に関するドキュメントが整備されており、これならいけそうということで、さくらでの移行に取り掛かりました。

しばらくEC2のような専有インスタンスに慣れていたため、ひさびさの共有サーバは懐かしい感じがしました（専有プランは予算に合わず）。

---

2. 構成

2.1 移行元

2.1.1 利用者インタフェース

2つのサイト（#1、#2）ともトップページ（サーバールート）は静的なHTML、特定のサブディレクトリがWordPressコンテンツとなってます。

URL	URLにアクセスして表示される内容
https://【サイト個別ドメイン】/	（サーバールート）静的HTML
https://【サイト個別ドメイン】/【コンテンツ識別名】/	WordPressコンテンツルート

2.1.2 システム構成

すべてAWS内で構成しています。冗長化していないEC2/EBSのシングル構成で、EC2内にDocker（Docker Compose）コンテナでサービスを構成しています。

• Route 53：WordPressサイトの2つの異なるドメインをホストしているドメインネームサーバです。2つのドメインのサイトとも同じEC2の（Elastic IP）IPアドレスをAレコードで定義しており、2つのサイトに対するリクエストは同じEC2に向けられます。
• CloudWatch Synthetics：WordPressサイトに定期的にアクセスし、サイトが落ちていたら管理者（私）にアラームメールを通知するようにしています（たまにWordpressからデータベースへの接続が永続的に切れてサイトが落ち、復旧を要していたため）。
• EBS：永続的なストレージを管理します。EC2の永続的ストレージとしてバインドし、サイト関連コンテンツ（WordPressを含むサイトディレクトリ、MySQLデータベース、サーバ証明書）の格納領域を各コンテナからDockerボリュームマウントしています。

EC2内の各Dockerコンテナは以下の役割を持ちます（名称は配布コンテナイメージ名）。

• jwilder/nginx-proxy (Reverse proxy)：ホストEC2のポート80/443にバインドして、サイトに対するHTTP/HTTPSアクセスのフロントとなります。このコンテナイメージはリクエストのURLに含まれるドメインを認識し、Docker定義でenvironment節のVIRTUAL_HOSTキーに指定された値とドメインが一致するコンテナにリクエストを転送します（リバースプロキシ）。またこのコンテナでは後述のcentos（Let’s Encrypt）コンテナと共有するボリュームに格納されているサーバ証明書を用いてSSL/TLSを終端します。
• centos (Let’s Encrypt certbot)：centosイメージをベースとし、マウントボリュームにLet’s Encryptの証明書更新プログラム（certbot）やサーバ証明書等を管理しています。サーバ証明書更新処理は、ホストEC2のcronにてコンテナ内のcertbotを定期実行しています。
• wordpress：マウントボリュームにサイトコンテンツを格納しています。サイトごとにコンテナを構成しており、コンテナのDocker定義environment節のVIRTUAL_HOSTキーの値としてサイトサーバールートのドメインを個別に定義しています。
• mysql：マウントボリュームにwordpressコンテナで管理するサイト情報を管理するデータベースを格納しています。WordPressサイトと1:1の対応でコンテナ（RDBMS）を構成しています。

---

2.2 移行先

2.2.1 利用者インタフェース

移行前と変更ありません。

2.2.2 システム構成

一部を除き、さくらにホスティング先を移行しています。

• さくら側
  • さくらのレンタルサーバ　スタンダード：WordPressサイトの導入・移行に関するサービスやドキュメントが充実しており、また移行するサイトはメンテナンスフェーズに入っており技術的トライアル（IaaSとしての裁量性）も今後発生しないことから、レンタルサーバのスタンダードプランがコスト最適で必要十分と判断しました。スタンダードプランでは、MySQLデータベースサーバ、マルチドメイン（これはライトプランでも可能）、SSH接続等が提供される一方、複数契約者による共有サーバとなります。
  • 無料SSL(Let’s Encrypt)サービス：サーバーコントロールパネル（Web管理画面）から設定を行うことによりLet’s Encryptによるサーバ証明書の発行および自動更新を行うことができるマネージドサービスです。この利用により、Let’s Encryptに関する管理をオフロードすることができました。
  • (Web/FTP)サーバー (FreeBSD)：コンピューティングおよびストレージに関するマネージドサービスです（レトロニム的に表現すれば）。この利用により、OSパッチ等の運用をオフロードすることができました。またマルチドメイン機能により、サイトドメインごとのリクエスト振り分け（リバースプロキシ）の管理もオフロードしています。移行元と異なり、同一ユーザーランド（さらに言えば他契約者とも）なのでアイソレーションレベルとしては低下していますが受容します。
  • データベースサーバー (MySQL)：RDBMSに関するマネージドサービスです。この利用によりRDBMSのコンテナ管理をオフロードすることができました。移行元と異なり、同一RDBMSをシェア（さらに言えば他契約者とも）し、サイト間はRDBMS内でのデータベースによる分離なのでアイソレーションレベルとしては低下していますが受容します。
• AWS側
  • Route 53：さくらにもDNSホスティングサービスはあり移行は可能ですが、今回の移行ではAWS側のままとしました。移行作業時に各サイトのAレコードをさくらの(Web/FTP)サーバーIPアドレスに変更します。
  • CloudWatch Synthetics：ドメイン名ベースで監視していますので、特に変更はありません。というかIaaS上に各種サービスをセルフ管理していた移行前と異なりマネージドサービスを利用するようになりましたので、さくらのサービス安定性からして今後は不要でしょう…異常検知したところでこちらで対応できるわけでもないですし。

---

3. 方針

WordPressサイトのおおよその物理構成は以下で、(*)を付けたデータについては移行元からの移行が必要と理解しています。

• HTTPサーバコンテンツディレクトリ
  • WordPressコアプログラム（PHP）
  • WordPressテーマ（PHP等）
    • 標準および配布テーマ
    • カスタムテーマ(*)
  • アップロード画像(*)
• データベース格納データ
  • メタデータ
    • WordPressコア管理データ
    • カスタマイズデータ(*)
  • 投稿データ(*)

WordPressサイトの移行方法は、大きく以下の2つが考えられるかと思います。

1. WordPress新規インストール＋データベースデータ移行：WordPressを新規にインストールすることによりデータベース接続等の設定をインストールガイドに沿って行えますので、定義ファイルを直接更新するといったリスクを伴う作業が軽減できます。一般的に示されている手順では加えてデータベース格納データを移行することにより完了とされていることが多いように思いますが、カスタムテーマやアップロード画像を有している場合にはHTTPサーバコンテンツディレクトリの一部移行も必要になると理解しています。
2. HTTPサーバコンテンツディレクトリ＋データベースデータ移行：WordPressに関する物理ファイル・データをまるごと移行します。カスタムテーマやアップロード画像も移行できますが、移行先環境に合わせて定義ファイルを直接更新するといったリスクが生じます。WordPressコアプログラムや各種プラグイン等もまるごと移行しますので、特に移行先でのインストールは発生しません。

今回の移行では、1つのサイトではカスタムテーマや大量のアップロード画像が存在しており、（弱い理由ですが）WordPressサイトの上位ディレクトリに静的HTMLコンテンツも有していることから後者（HTTPサーバコンテンツディレクトリ＋データベース移行）の方法を採用しました。なお定義ファイルの直接更新についてはwp-config.phpのMySQL設定（データベース名、データベースユーザー名、データベースパスワード、データベースホスト名）を変更するだけで済みました。

また移行にあたってはダウンタイムをどの程度許容するかも検討ポイントになり、それによって移行方法も大きく異なってきます。今回移行するサイトについてはほとんど利用が無いサイトで一日二日落ちていても問題ありませんので（…）、ダウンタイムについてはシビアに考慮しない手順となっています。

---

4. 手順概要

おおよそ以下の手順で作業しています。

• 移行元環境の情報確認およびDNS設定調整
• 移行先環境の契約
• データベース作成
• SSH設定
• 移行元サイトのエクスポートおよび移行先への転送
  • 移行元データベースのデータエクスポート
  • 移行元HTTPサーバコンテンツディレクトリのアーカイブ
  • エクスポート／アーカイブファイルの移行先サーバへの転送
• WordPress等コンテンツ移行
  • データベース移行
    • 移行先データベースへデータインポート
  • 移行先サーバフォルダ作成
  • ドメイン設定
  • HTTPサーバコンテンツ移行
    • 移行先HTTPサーバコンテンツディレクトリへのアーカイブ展開
    • WordPress定義ファイル修正
  • DNS切替
• SSL(TLS)設定
• 動作確認／移行元クロージング等

---

5. 手順詳細

各手順は2024年8月現在のものであり、変更される可能性があります。

文中にて【】で囲んだ文字列は環境によって異なりますので、環境に応じた文字列を確認または指定してください。

---

5.1 移行元環境の情報確認およびDNS設定調整

いくつかの情報は移行元および移行先での作業や、トラブル時の対応に必要となりますので確認します。環境によって記述が無い場合もあります。

• WordPress
  • ユーザおよびパスワード（移行先での動作確認のため）
  • wp-config.phpの内容
    移行元がDockerコンテナのwordpressイメージを利用している場合、Docker定義ファイルのWordPressコンテナenvironment節で”WORDPRESS_”をプレフィックスとするキーの値で定義されている場合もあります。
    • MySQL設定
      • WordPressのためのデータベース名：define('DB_NAME', '【データベース名】');
      • MySQLデータベースのユーザー名：define('DB_USER', '【ユーザー名】');
      • MySQLデータベースのパスワード：define('DB_PASSWORD', '【パスワード】');
      • MySQLのホスト名：define('DB_HOST', '【データベースホスト名】');
      • データベース文字セット：define('DB_CHARSET', '【文字セット識別子】');
      • データベースの照合順序：define('DB_COLLATE', '【照合順序識別子】');
    • WordPressデータベーステーブルの接頭辞：$table_prefix = '【接頭辞】';
• MySQL
  • Docker定義ファイルのMySQLコンテナcommand節でのオプション--character-set-serverや--collation-serverの値
• サイトのドメイン、WordPressディレクトリ（パス）名

また移行手順の中で、DNS切替にて移行対象のドメインが指すサーバを、移行元サーバから移行先サーバのIPアドレスに変更します。DNSの定義でキャッシュ時間（TTL）が設定されており、この時間が長いと参照元が新たなIPアドレスへアクセスするまで時間がかかる場合があります。移行作業に先立ち、この時間設定を短め（5～15分程度）にしておくとよいでしょう。移行作業が完了したら元の時間に戻します。

---

5.2 移行先環境の契約

以降、参考ドキュメントに沿って操作を進めます。

• サービスプランの選択
  • サービスプラン
    • 移行先のシステム構成で述べたように「さくらのレンタルサーバ　スタンダード」を選択しました。
  • 初期ドメイン
    • デフォルトで指定されているランダムな名称か、希望する任意の名称を指定します。今回の移行では別途ドメイン設定をするため移行サイトの対外的には影響しません。管理者がサーバに対して作業する際の接続先等で利用する場合があります。入力部分についてはサーバにFTPやSSHで接続する際のアカウント名（ユーザー名）やサーバ上ホームディレクトリの名前になります。
  • 独自ドメイン
    • 別途移行元のドメインを設定するため、ここでの独自ドメイン取得は不要になります。「レンタルサーバーだけ契約する」を選択した状態で「お支払方法の選択」をクリックします。
• 会員認証（ログイン）
  • 契約が発生しますのでさくらインターネットの会員として認証が必要となります。私は移行の経緯で述べたようにもともと会員でしたのでログインしました。詳細は割愛します。
• 支払い方法の選択
  • お支払について
    • 契約種別
      • 長期一括契約ほど割引されます。
        私は失敗したのですが…移行断念に備えて「毎月払い」を選択し、移行が成功すれば長期一括契約に切り替えようとしました。しかし初回請求支払が済むまで切り替えができないことを後から知り、また契約後一定期間はお試し期間があって期間中に解約すれば済むため、最初から長期一括契約にすればよかったのでした…
    • 支払い方法
      • 任意の支払い方法を選択します。
        ただし他社取得独自ドメイン設定など一部の機能は本来お試し期間中では機能制限されて使えないのですが、クレジットカード払いだと使える等の違いがありますので注意してください。すぐに正式契約すれば回避は可能ですが。
  • 所有していればクーポンコードを入力するなどして「お申し込み内容の確認へ」をクリックします。
• 申し込み内容の確認
  • 内容に誤りが無いことを確認して「この内容で申し込む」をクリックします。
• 申し込み完了
  • 完了すると会員登録メールアドレスに仮登録完了のお知らせメールが届きます。メール内に各種接続先や認証情報が記載されていますので以降の作業で使用します。申し込み時の「初期ドメイン」に入力した文字列（メール中では「FTPアカウント」の値）がSSH接続/scpコマンド等でユーザ名として使用するものになります。以降では以下のように表記しますので御注意ください。

本手順での表記	内容	例
「移行先サーバユーザ名」	「初期ドメイン」に入力した文字列	myserver
「移行先サーバアドレス」	「初期ドメイン」に入力した文字列＋”.sakura.ne.jp”	myserver.sakura.ne.jp

---

5.3 データベース作成

後述の手順でデータベースに対する作業が発生するため、あらかじめデータベースの準備をします。

以降、参考ドキュメントに沿って操作を進めます。

• データベースを新規作成・追加する
  • 参考ドキュメントに記載されている「複数のデータベースを作成する事ができます。（MySQL5.7でのみ追加が可能です。）」に留意してください。
  • サーバーコントロールパネルログイン
  • データベースを追加
    • “サーバーコントロールパネル” > “Webサイト/データ” > “データベース”
    • 「新規追加」をクリック
    • 最初のデータベース作成と2つ目以降のデータベース作成では異なる部分があることに注意（データベースユーザーは固定で共通のため、そのパスワード設定は初回のみ）して項目を入力し、「作成についての注意事項」に目を通して「同意する」にチェックをし、「作成する」をクリックします。

項目名	選択・入力・表示内容
データベースバージョン	利用時期によって可能な選択肢が異なる場合があると思いますが、任意のバージョンを選択します。前述のように複数サイトの移行では「5.7」が必要となります（ただし作業時点では「5.7」しかありませんでした）。
データベース名	画面項目上部に表示されている移行先サーバユーザ名（＋アンダーバー）が固定プレフィックスとして付与されます。この画面ではプレフィックスに続く任意の名称を入力します。データベース名は「【移行先サーバユーザ名】_【当項目入力文字列】」となります。
データベースユーザー名	移行先サーバユーザ名と同一で固定となります。変更することはできません。
データベース接続用パスワード	（最初のデータベース作成時のみ）任意のパスワードを入力します。併記されている指定可能文字について注意してください。特に使用可能な記号は非常に少なくなっています。
データベース接続用パスワード再入力	（最初のデータベース作成時のみ）パスワード指定誤り防止のため前記で入力したパスワードを再入力します。
データベース文字コード	基本的には移行元データベースと同じ文字コードを選択します。今回の移行ではwp-config.php、Docker定義ファイルのMySQLコンテナ起動時パラメタ（command）の定義内容から、「UTF-8 (utf8mb4)」を選択（デフォルト）しました。

データベースを作成するとサーバーコントロールパネルのデータベースサーバ欄にデータベースサーバのアドレス（URL）やデータベース名が表示されます。これらは後の手順で利用しますので控えておきます。移行先データベースサーバアドレスについては「mysql【個別発行番号1】.【移行先サーバアドレス】」「mysql【個別発行番号2】.db.sakura.ne.jp」の併記がされており、どちらでもかまいません。

移行元のWordPressでは関連データベースの更新に権限範囲を絞った専用のMySQLユーザーを作り、その認証情報でデータベース接続を行っていました。さくらのスタンダードプランではMySQLサーバは他契約者と共有するシェアードサービスであり、MySQLに独自ユーザを作成することはできません。このため移行先では前記の設定で提供されるデータベースユーザー名およびパスワードをすべてのWordPressで共用することになります。

---

5.4 SSH設定

今回の移行では、ファイルのサーバ間転送や定義ファイル修正について、クライアントPCを中継（ダウンロード、アップロード）せずサーバ上（サーバ間）に鍵認証によるSSH接続（およびscpファイル転送）で直接作業を行いましたので、移行先さくらレンタルサーバに対するSSH設定を行います（移行元サーバはすでにSSH接続ができている前提）。パスワード認証等の場合は「SSHを利用したい」を参照してください。

以降、参考ドキュメントに沿って操作を進めます。

• サーバーコントロールパネルログイン
• 鍵ペアを作成
  • “サーバーコントロールパネル” > “サーバー情報” > “SSH公開鍵”
  • 「新規追加」をクリック
  • 「追加方法」で「鍵ペアを生成して登録※ECDSA (521 bits) 鍵」を選択します。「パスフレーズ」や「コメント」は任意に指定（または省略）してください。
  • 「登録する」をクリック
  • 秘密鍵のダウンロードがWebブラウザのファイル保存ダイアログで行われますので、クラアイントPCの任意の場所（セキュリティ上安全な場所にしてください）に保存します。

以降は参考ドキュメントに記載されていない本手順独自の操作になります。

• AWS EC2（移行元サーバ）にSSH接続
• ~/.ssh/ディレクトリに作成した秘密鍵ファイルを配置
  • アップロードでも、クライアントPCで秘密鍵ファイルを開いてコピーし、EC2ターミナル画面でペーストするなどすることでも可能。ファイルの権限は”chmod 600 <移行先サーバ秘密鍵ファイル>“（所有ユーザのみread/write可）等で適切に設定します。
• さくらサーバにSSH接続確認（以下コマンド例）

ssh 【移行先サーバユーザ名】@【移行先サーバアドレス】 -i ~/.ssh/【移行先サーバ秘密鍵ファイル名】

---

5.5 移行元サイトのエクスポートおよび移行先への転送

以降の移行作業について、環境を行ったり来たりしなくても済むよう、ここでまとめて移行元サイトのエクスポートと移行先サーバへの転送を行っておきます。

• 移行元データベースのエクスポート：以下はDocker経由コンテナホストからのコマンド例。コマンド実行後にMySQLのrootパスワード入力待ちになりますのでパスワードを入力します。

docker exec -i 【MySQLコンテナ名】 sh -c 'exec mysqldump --single-transaction 【移行元データベース名】 -uroot -p' > 【データベースエクスポート名】.sql

• 移行元HTTPサーバコンテンツディレクトリのアーカイブ（コマンド例。zipコマンド末尾のピリオドに注意）

cd 【WordPressコンテナボリュームマウント先】/var/www/html
sudo zip -r 【コンテンツアーカイブ名】.zip .

• データベースエクスポートファイル／HTTPサーバコンテンツアーカイブファイルの移行先サーバへの転送（コマンド例）

scp -i ~/.ssh/【移行先サーバ秘密鍵ファイル名】 【データベースエクスポート名】.sql 【移行先サーバユーザ名】@【移行先サーバアドレス】:~
scp -i ~/.ssh/【移行先サーバ秘密鍵ファイル名】 【コンテンツアーカイブ名】.zip 【移行先サーバユーザ名】@【移行先サーバアドレス】:~

---

5.6 WordPress等コンテンツ移行

本手順の第一参考ドキュメント「他社からWordPressコンテンツを移転したい（phpMyAdmin利用）」では、手順の途中で他のドキュメントを参照しているため、上記のように階層（入れ子）構造になっています。

さくらのドキュメントではいくつかの移行方法が提供されています。前記の「phpMyAdmin利用」の他では「他社からWordPressコンテンツを移転したい（SnapUp利用）」という方法もあります。しかしこちらの方法では「前提条件」に「WordPressのマルチサイト機能を使用していない事」とありましたので、今回の選択肢からは外しました。

また以下のように記載があり、お試し期間中は適用できないことも理由にありました。マルチサイトを使っておらず、正式契約をしているケースでは活用できるかと思います。

バックアップ＆ステージングの利用開始

【バックアップ＆ステージング】利用開始・解除を参照し、移転先サーバーにてバックアップ&ステージングを利用開始してください。
※お試し期間中は利用できません。料金の支払い後に利用を開始してください。

また今回の移行ではデータベースのインポートにphpMyAdminを使わずmysqlコマンドを利用していたり、wp-config.phpを直接サーバ上で編集していたり、参考ドキュメント手順途中に出てくるSnapUpによるバックアップ＆ステージングの利用が、参考ドキュメント該当部分には書いていませんがサービス説明注記や前記の通りお試し期間では使えないといった背景により、以降の説明ではドキュメントとは異なる作業や順番の入れ替えがあります。

以降、参考ドキュメントをベースに独自作業も交えて操作を進めます。

• データ移転
  • 移転元のデータベースのデータをエクスポート
    • 今回の移行では前記の手順でエクスポート済ですのでここではスキップします。
  • 移転先のデータベースにデータをインポート
    • 参考ドキュメントではphpMyAdminによる方法（クライアントPCからのアップロード）が記載されていますが、本手順では移行元サーバでエクスポートしたデータを移行先サーバ上に転送済みですので、mysqlコマンドを使った方法を記します。移行先サーバで以下のコマンド実行後にMySQLのデータベースユーザのパスワード入力待ちになりますので、データベース作成手順で設定したパスワードを入力します。
      mysql -h 【移行先データベースサーバアドレス】 -u 【データベースユーザ名(=移行先サーバユーザ名)】 -p 【データベース名】 < 【データベースエクスポート名】.sql
    • mysqlコマンドでのインポートが完了しましたら、phpMyAdminでデータがインポートされていることを確認するのもよいでしょう。
  • 移転元のサイトデータをダウンロード
    • 本手順では移行元サーバでアーカイブしたコンテンツを移行先サーバ上に転送済みですのでここではスキップします。
  • 設定ファイルを編集
    • 本手順では後のステップ（移行先サーバ上で直接編集）で行いますのでここではスキップします。
  • 移転先にサイトデータをアップロード（本手順では転送済データの配備）
    • コントロールパネルにログイン
    • ドメイン追加
      • 参考ドキュメントでいくつか記載されている参照ドキュメントのうち今回の移行にマッチするのは「他社で取得・管理中のドメインを設定したい」ですが、今回の移行ではマルチドメインを利用するケースにあたりますので、「マルチドメインを設定したい」を参考とします。
        • マルチドメイン設定
          • フォルダ作成
            • “サーバーコントロールパネル” > “Webサイト/データ” > “ファイルマネージャー”
            • ファイルマネージャー起動直後は「/home/【移行先サーバユーザ名】/www/」がカレントディレクトリとなっています。
            • 「表示アドレスへの操作」の「フォルダ作成」をクリック
              
            • フォルダ名を入力し「OK」をクリック
              • これはマルチドメイン設定での個別ドメインごとのサーバールートディレクトリとなります。サーバールートとなりますので、ここで指定したフォルダ名は利用者には表出しません（URLには含まれません）。どの個別ドメインに対応するディレクトリかを自分が識別しやすい任意の名前を指定してください。
          • ドメイン追加・設定
            • 今回の移行にマッチするのは「他社で取得・管理中のドメインを設定したい」になりますので、以下はこのドキュメントを参考とした手順になります。
              • 独自ドメイン設定
                • 独自ドメイン追加（この操作をしてもDNS設定は変更していませんので、まだ利用者がドメインURLでアクセスされる先は移行元のままです）
                  • “サーバーコントロールパネル” > “ドメイン/SSL” > “ドメイン/SSL”
                  • 「ドメイン新規追加」をクリック
                  • 「他社で取得したドメインを移管せずに使う」の「追加」をクリック
                    • お試し期間では利用不可ですが、クレジットカード払いであれば利用可能
                  • 「他社で取得した独自ドメインの追加」に移行するサイト個別ドメインのドメイン名（FQDN）を入力し、「追加」をクリック
                  • 画面に追加したドメインが表示されていることを確認
                • ネームサーバーの指定
                  • まだSSL(TLS)設定やHTTPサーバコンテンツ移行が済んでいませんのでここではスキップします。
            • ドメイン一覧画面に追加されたドメインの「設定」をクリックし、「基本設定」をクリック
            • “ドメイン設定” > “基本設定”で以下の設定を行い「保存する」をクリック
              • 「ドメイン利用設定」
                • 「マルチドメインとして利用する」を選択（デフォルト）
                • 「www.が付与されたサブドメインも利用する」については私は利用しないため外しました。
              • 「Web公開フォルダ」
                • 前ステップで作成した、個別ドメインに対応するサーバールートディレクトリを指定します。
              • 「www.転送設定」
                • 私は利用しないため「転送しない」を選択しました。
          • データのアップロード
            • アーカイブしたコンテンツを移行先サーバ上に転送済みですので、アーカイブを移行先サーバで以下のコマンドで展開します。
              cd ~/www/【作成したドメインサーバールートディレクトリ名】
unzip ~/【コンテンツアーカイブ名】.zip
              • 展開したディレクトリ／ファイルの所有ユーザ／グループがWordPressの想定と異なるとWordPressのバージョンアップ等が失敗する場合があります。sshログインしたユーザ（移行先サーバユーザ）で展開すると、ユーザが移行先サーバユーザ名、グループが”users”、で展開されますが、これで問題無いようです。
            • スキップしていた設定ファイルの編集をここで行います。wp-config.php（展開したディレクトリのコンテンツ識別名サブディレクトリ（WordPressコンテンツルート）に存在）をvim等のエディタで編集します。
              • デフォルトでは日本語が文字化けしますが、以下の設定で回避できます（参考：さくらサーバのスタンダードプランでvimが文字化けする）
                • ログインスクリプトを編集
                  • vim ~/.cshrc
                • 以下の行を追加
                  • setenv LANG ja_JP.UTF-8
                • 再ログイン（SSH接続）
              • 編集内容
                • WordPressのためのデータベース名：define('DB_NAME', '【移行先で作成したデータベースの「データベース名」】');
                • MySQLデータベースのユーザー名：define('DB_USER', '【移行先で作成したデータベースの「データベースユーザー名」（＝移行先サーバユーザ名）】');
                • MySQLデータベースのパスワード：define('DB_PASSWORD', '【移行先で作成したデータベースの「データベース接続用パスワード」】');
                • MySQLのホスト名：define('DB_HOST', '【移行先で作成したデータベースのデータベースサーバアドレス（FQDN）】');
          • ブラウザでの確認
            • まだブラウザで表示できるための設定（DNS切替、SSL(TLS)設定）が済んでいませんのでここではスキップします。
• 表示確認
  • 参考ドキュメントで記載されている手順で利用するSnapUpは、今回の移行の際はお試し期間中でステージング機能が利用できなかったためスキップし、以降に記載する手順でぶっつけ本番でDNSを変更して設定・確認しました。
• DNS切替
  • 今回の移行ではAWS Route 53にてサイトドメインのAレコードが示すIPアドレスを移行先サーバ（Web/FTPサーバ）のIPアドレスに変更しました。DNS設定調整で説明したようにTTL期間のタイムラグが生じますので、その時間程度待機してから次のステップに進みます。

---

5.7 SSL(TLS)設定

このステップではLet’s Encryptの設定を行いますが、その過程で対象ドメインに対してLet’s Encryptサービス側から有効性確認のためのアクセスが行われます。そのため前ステップでのDNS切替がLet’s Encrypt側からの参照に反映されていないと設定が失敗しますので、DNS切替後はTTL期間程度待ってから進めてください。

以降、参考ドキュメントに沿って操作を進めます。

• 設定・申し込み手順
  • “サーバーコントロールパネル” > “ドメイン/SSL” > “ドメイン/SSL”
  • マルチドメイン設定で追加したサイト個別ドメインの「設定」をクリックし、「SSL設定」をクリック
  • 「登録設定を始める」をクリック
  • 「SSL証明書の利用種類を選択」で「Let’s Encrypt（無料SSL）」の「利用する」をクリック
  • 「無料SSL証明書登録」で表示文面およびLet’s Encryptの利用ポリシーに目を通し、「確認」の「Let’s Encryptの利用ポリシーに同意する」をチェックし、「無用SSLを設定する」をクリック
  • 「ただいま無料SSL証明書の発行手続き中です。」と表示されます。
    • 10分程度待つと、さくら会員登録メールアドレスに「[さくらインターネット]SSLサーバ証明書発行のお知らせ」という件名のメールが送付されるので受信できるまで待ちます。
• 確認
  • メール受信後、ウェブブラウザで”https://【移行サイト個別ドメイン】/”にアクセスし、ページの表示とサーバ証明書に問題が無いことを確認します。
    • 以下を確認するとよいでしょう。
      • サイトトップページ（”https://【移行サイト個別ドメイン】/”）：今回の移行では静的HTML
  • “http://【サイト個別ドメイン】/”（SSL/TLSのhttpsではなく、非SSL/TLSのhttp）にアクセスしてエラーになったり、httpsに転送されないようであれば、強制的にSSL/TLSのhttpsに転送されるようにすることも望ましいと考えられます。今回の移行では私の環境ではこれまでの手順で特に他に設定することなく転送されるようになっていました。参考までに私の環境のサーバーコントロールパネルの”ドメイン/SSL”のドメイン”基本設定”では「SSLの利用：SSLを利用する」はON、「HTTPS転送設定：HTTPSに転送する」はOFFとなっています。
    • もし御自身の環境で転送されないようであれば、以下のドキュメントが参考になると思われます。
      • ドメインリダイレクトを設定したい
      • WordPressのサイトをSSL化したい

---

5.8 動作確認／移行元クロージング等

• 動作確認
  • SSL(TLS)設定で確認したサイトトップページの他、以下の表示が問題ないことを確認します。
    • WordPressトップページ（”https://【サイト個別ドメイン】/【コンテンツ識別名】/”）
    • WordPress管理画面（”https://【サイト個別ドメイン】/【コンテンツ識別名】/wp-admin/”）および認証
    • WordPressの管理画面の以下の情報で移行先サーバで稼働していることが確認できます（バージョンによって異なる可能性あり）。
      • （左側メニュー）”ツール” > “サイトヘルス”
      • 画面中央上部に「ステータス」「情報」と並んでいるので「情報」をクリック
      • サイトヘルス情報の一覧の「サーバー」をクリックして展開
      • 「サーバー構造」の値が”FreeBSD”で始まる文字列であれば、さくらの(Web/FTP)サーバー(FreeBSD)で動作していることが推定されます。
• 他移行サイトの移行
  • 複数のサイトが移行対象の場合、それぞれのサイトに対して「5.3 データベース作成」から前ステップの動作確認までを実施します。
• 移行元クロージング
  • 以下はもし設定されていれば速やかに対応します。
    • 移行元サーバでのLet’s Encrypt certbot定期実行（cron等）無効化
      • DNS切替をした時点で移行元サーバでのサーバ証明書更新処理が無意味（Let’s Encryptサービス側からの有効性確認リクエストが移行元には届かない）となるため早めに無効化することが望まれます。
  • 以下は任意のタイミングで対応します。
    • 移行元サーバのWebサーバ停止（私の環境ではdocker-compose down）
    • DNSのTTL時間設定を戻す
    • EC2/EBS等のリソース停止・削除

6. 参考情報

今回の移行では利用しませんでしたが、移行パターンによっては参考となるドキュメントを以下に記します。

• WordPressのインストール手順を知りたい
• 動作確認のためにhostsファイルを利用したい
• データベースのエクスポート（書き出し）とインポート（読み込み）をしたい（phpMyAdmin）
• SSHを利用したい