実例：アップグレードなしWordpressサイトのサーバー移転

作業案件概要

今回一気に2件のWEBサイトをやってしまいます。

同じサーバー間では移転先で独自ドメインの設定ができない理由についてはこちらのページをご参照下さい。

ポイント：Wordpressのバージョンが古い

本来は移転元のWordpressのバージョンが古いのでできるだけアップグレードしていくべきですよね。

しかしあまり使っていないサイトなので、とにかく一つのサーバーに統合して保存ができれば良いというクライアントからの要望でした。要は予算があまりないのです。

ですので今回はアップグレード作業なしで、強引に移転をさせる事を決定しています。。

結果使えないプラグインが出てくれば、その部分は機能削除をしていく事で了承を得ています。

アップグレードなし移転の流れ

手順１：データベースのバックアップ

移転元サーバーのphpMyAdminに入り、データベースファイル（sqlファイル）をバックアップする必要があります。

プラグインからのバックアップに失敗

最初は「backWPup」プラグインを使って保存しようとしたのですが、バージョンの問題なのかエラーが出てしまいました。

ですのでphpMyAdminからDBファイルをエクスポートする事になります。

DBパスワード変更

移転元のMySQLバージョンが5.0、移転先のMySQLバージョンは5.6

2013年にhetemlでPHP5.4がリリースされました。

そのため、2013年2月6日以前に作成されたMySQL5へ、PHP5.4以上のバージョンから接続を行うためには、一度コントロールパネルのデータベースよりパスワード変更の必要がありました。

ですのでデータベースパスワードを変更します（パスワードは8文字以上15文字までの場合は任意）。

DBのパスワード再設定画面。画面上はパスワードを設定した後なので「対応」と表示されています

このパスワードはWordpressのDB接続パスワードですので、変更した際にwp-config.phpに記載されているDBパスワードも一緒に変更する必要があります。

そうしないと移転させていないのに移転元サイトが映らなくなります。

wp-config.phpのパスワードを変更

phpMyAdminでDBファイルのバックアップ

phpMyAdminにログインをして、sqlファイル一式をバックアップ（エクスポート）します。

手順２：Wordpress構成ファイルのバックアップ

これはFTPソフトから一式おこないます。

バックアップを取ったのが日中だった事もあり、通信が遅く非常に時間が掛かりましたね。

結局段階を追ってダウンロードをしました。特に残りを土日にすると全然違いました。

手順３：移転先サーバーでWordpress初期構成を準備

移転先サーバーに独自ドメインを設定し、Wordpressを新規インストールします。

この時、DBユーザー名やパスワードはメモしておきましょう。移転先のphpMyAdminにアクセスする時に必要なためですね。

手順４：データベースファイルのインポート

移転先サーバーphpMyAdminでデータベースファイルをインポートします。

この時、元々入っているWordpressデータベースのテーブル（wp_commentmetaやwp_userなど全て）を全てリネーム（名前変更）します。

名前を変える理由

通常インポートをした時は同じテーブル名だと上書きされていくのですが（元テーブルは何も入っていないので）、今回は上書きの際にエラーが出るので、上書きをせずに新規にインポートさせます。

確認のため、sqlの欄で一つずつsql命令を書いてリネームしていきます。

名前変更はとにかく上書きされなければ何でも構いません、リネームしたテーブルは使いませんので。

sql例

ちなみに全て「wp_」から始まりますので、全て「wp2_」に接頭語を変更しました。

リネームの様子

リネームが済んだらインポート欄で、ダウンロードしていたsqlファイルを選択してインポートします。

これでリネームしたテーブルとは別に正常にインポートされました（安心しました、よかった）。

インポート後wp2_とwp_のテーブルがそれぞれ入っている状態

手順５：ダウンロードデータのアップロード

ダウンロードしていたWordpress構成データを移転先へアップロードします。

プラグインも一応全てまずは入れてしまいます。

wp-config.php は特に触らずにそのままにしておきます。DBユーザ名やDBパスワードは新規インストール時のパスワードをそのまま使うためです。

手順６：hostsファイルの変更

確認するパソコンのhostsファイルを変更します。自分だけ移転先サーバーでの状態を確認するためですね。

hostsファイルの書き換え手順・編集方法法についてはこちらをどうぞ。

2件サイトがあるので2件とも設定をしてしまいます。

手順７：サイト状態確認

Wordpressの管理画面へログインします。データベースが更新されてダッシュボードが開きます。

案の定プラグインはいくつかエラーが出ている様ですが、対象箇所は有効化せずにそのままにしました。

プラグインの出力部分を手作りでしている箇所はテーマファイルの該当箇所を消すなどの対処をしましたね。

入力画面を従来のものにするプラグイン

今回はバージョンが5.3で、5.0以降は投稿ページの入力画面が大きく変わっています（グーテンベルクエディターGutenberg Editor）。

そのため4.0系までメインだったプラグインのClassic Editorをインストールしておきます。

元の入力画面じゃないとお客様は戸惑われますしね。

これで移転は完了です。

あわせて読みたい関連記事

今回の案件の経緯

予算の縛りがある

本来はクライアントの所有する他のWEBサイトが入っているサーバー（ここもheteml）に統合するのが目的です。

そして保守の関係もあって、今回の移転作業に関して申受けできる費用範囲が決まっていました。

同じサーバー間でのサイト移転は独自ドメインが管理画面から設定できないので、通常の方法では移転ができません。

一度heteml以外のサーバーへ移して、もう一度hetemlへ戻すという2段階の移転の方が、細かい事をやるよりも手っ取り早いと思いました。

エラーのリスクはあります。

今回の条件下では大きな問題はなかったものの、もしDBファイルやプラグインなどWEBサイト表示の根幹にかかわるエラーが出ていたら危ない状況でした。

そうなると修正対策を取る（別途追加見積もりになる）しかなくなります。それで予算が膨らむのは先方も困ります。

移転元のサーバーは今回契約期限が迫ってた

もし大きなエラーが出てそれに対処をする場合、追加の見積もりや先方の了承、修正作業などいろいろ時間が掛かってしまいます。ましてや同じサーバー間での引越しであればなおさらです。

ところが2サイトとも契約しているサーバーの契約期限が迫っていました。もう次は更新をしない予定でいました。

私が管理しているのXサーバーに一旦移しておけば、とりあえず移転元のサーバーは契約満期とともに閉じる事ができるという面でも、2段階移転はやはり都合が良かったのですね。

まあ一旦Xサーバーにサイトを移しても、もし移転時に深刻なエラーが出ていたら正常に映らない訳ですから、リスクを回避した事にはなりませんけどね。

結果としてXserverへ移動させて良かったと思います。

結果大きなエラーがなく移転できる事がわかったので、この後もう一度Xserverからhetemlの統合サーバーへ移転させる予定です。

本来の手順とは違いますので注意です。

最初の方でも述べていますが、本来はアップグレードをちゃんとおこなって、機能をそのまま維持して移転するのがセオリーですよね。

今回はクライアントがそれほど移転状態に厳格ではなかったので良かったのですが、本来はプラグインのバージョンアップ或いは差替えなどをおこなって、きちんと機能水準を保った移転をおこなうべきです

2段階移転は実施するのに問題は無いと思います。

バージョンが離れていても移転自体は可能である事が今回証明できていますが、もちろん移転するWordpressデータによって違うと思いますので、必ずしも100%保証するものではありません。

一押し人気コーナー紹介