今後、ConoHa VPSでWordPressを移転する可能性があるかもしれないので、今回の作業をメモしておく（自分用）。
なお、WordPress移転（引っ越し）プラグインを使えば楽そうではあったけど、無料版では容量に制限があったため、今回は使用しなかった。今後も容量が減ることはないため、プラグインに頼るなら有料ということになる…。
できれば、自力になるけど、無料で済ませたいところではある。
簡単に作業の内容をまとめる。
作業前には、すべてのバックアップをとっておいて元に戻せるようにしておくこと。
ConoHa VPSはイメージ保存ができるので、必ずしておく。
VPSを立ち上げる
VPSの場合、OSを選択できるが、できたら移転元のOSと同じにしておいた方が無難であろう。
KUSANAGIを設定する
#kusanagi initを済ませておく。
#kusanagi init をせずに#kusanagi provisionをしても当然失敗する（一見、正常に完了したように見えるが、ドメインからアクセスしてもエラーになる。）
これも、移転元のKUSANAGIの設定と同じにしておいた方が無難。
今回、WordPressの実行環境をHHVMからPHP7に変更した。どうやら、WordPressはHHVMをサポート外にするやらどうやらというのを目にしたからである。
まず、移転元のVPSでPHP7に変更して問題が無いか確認した上で、移転先でもPHP7を選択した。移転元でも移転先でも今のところPHP7で問題無し。
その他の設定は移転元と移転後も同じ(nginx,mariaDB)
KUSANAGIのプロビジョニングを済ませておく。これで、移転先のWordPressのファイル置き場（DocumentRoot）と、データベースのインポート先ができる。
Let’s encryptによるSSL化はまだできないので飛ばしておく。
WordPressファイルを全てコピー
FTPソフトでダウンロード・アップロードしても良いけど、膨大なファイル数のため、時間がかかりそうだった。
移転元サーバーにて、コマンドでWordPressのある場所までカレントディレクトリ（cd）を移動してからまるごと圧縮
tar -zcvf xxxx.tar.gz DocumentRoot
圧縮したWordPressデータをFTPソフトでダウンロードする。
移転先サーバーにてDocumentRootの中を全て削除する
その後、DocumentRootの上の階層に圧縮したデータをFTPソフトで転送し、コマンドで解凍する。
tar -zxvf xxxx.tar.gz
データベースをエクスポート＆インポートする
今回、データベースのエクスポート前に、「Optimize Database after Deleting Revisions」プラグインで、WordPressの不要なデータ、主に変更前の投稿（リビジョン）を消しておくことにした。
100MBあったデータベースが70MBにスリムアップ。
データベースのエクスポート＆インポートは手軽に「phpMyAdmin」を使えばよいと思うが、70MBのデータベースはエクスポートはできても、インポートは502 Bad Gatewayのエラーで正常に完了しなかった。
（色々、設定をいじればできるのかもしれないが）
データベースのインポートは、コマンドから直接行うことにした。
エクスポートしたデータベースファイルを移転先のサーバーにアップロードする。
アップロードしたファイルの階層にカレントディレクトリを移動する。
$ mysql -u root -p [データベース名] < wordpress.sql
データベース名は#kusanagi provisionで設定したものを入力する。
wordpress.sqlも、データベースをエクスポートしたときに名前をつけるが、そのときのものである。
その後、データベースのrootパスワードを求められるので入力する。
特にcomplete!とも何も表示されないが、1分もたたずにインポートが完了した。
ドメイン変更をする場合
ドメインの変更もあわせて行う場合、エクスポートしたデータベースファイル内のドメインを書き換える。
といっても、莫大な量になるので、私はテキストエディタ（サクラエディタを使った）で「旧ドメイン」・「新ドメイン」へと一括置換した。
ちなみに、私の場合は、テスト環境用のドメインにも移設したかったので、サブドメインに一括置換した。
これで、本番用とテスト用の2つのデータベースファイルを用意できた。
ドメインのDNS設定でAレコードを変更
ここまできたら、後はドメインのDNS設定を変更して、実際にサーバーを移転しよう。
移転元のサーバーのIPアドレスから移転先のサーバーのIPアドレスへ変更する。
今回はネームサーバーの変更はなかったため、私の環境では30分から1時間ぐらいで移転先サーバーへドメインからアクセスできた。
早く変更したい場合はTTLを短く設定しておくと良いだろう。（後から戻しておくこと）
Let’s encryptでSSL化しよう
ドメインからアクセスできるようになったら、#kusanagi provisionで飛ばしていた、Let’s encryptの設定を行う。
これをしないと、たとえば、chromeからアクセスしたときに、元々SSL対応だったサイトがSSL無しになったことで、「この接続ではプライバシーが保護されません」、パスワードやカード情報が盗みとられるなど警告が出てしまう。
なので、この段だけは、ドメインからアクセスできるようになったら、一刻も早く作業しなければならない。
# kusanagi ssl --email ＜メールアドレス＞ ＜プロファイル名＞
設定後、https://ドメインで正常にアクセスできれば、移転作業完了である。
移転元サーバーを削除
しばらく経って特に問題なければ、移転元のサーバーを削除・解約する。
いわゆる「ドメインの浸透問題」がなければ早めに削除できる。
