超簡単にConoHa WINGに引っ越し！WordPressデータ移行 ～ドメイン変更なし可&サービス無停止対応
サイト管理人
超簡単にConoHa WINGに引っ越しする方法 ～WordPressデータ移行
この記事では「WordPressデータを超簡単にConoHa WINGに引っ越し(データ移行)する方法」について解説します。
今回紹介する方法ではサーバーの引っ越し(データ移行)先がConoHa WINGであれば、現在使っているレンタルサーバーがどこであっても、この方法でWordPressのデータ移行をすることができます。
以下のような要望を持つ方に役に立てると思います。
- WordPressの全データをConoHa WINGに移行をしたい
- ドメインはそのまま変更せずにサーバーを引っ越ししたい
- 新しいドメインに変更してサーバーを引っ越ししたい
- Webサイトを停止することなくサーバー移行したい
- 失敗やデータ紛失などのリスクなくサーバー移行したい
- データ移行した新サーバーで完全に本番と同じ環境(本番のURL)で確認テストしてからリリースしたい
- データのエクスポートとかFTP転送とか面倒でリスキーでスキルのいる手順はいやだ
- とにかく自動でできる簡単な手順を教えて！
多くの方に読んでいただけるよう、Windows, MacOSなど様々なOSに対応したやり方で解説していきます。
この記事を監修・執筆した専門家
こんにちは！この記事を監修・執筆した斎藤はじめと申します。
私は現役のエンジニアで、普段はWordPressの開発案件などをメインに担当しています。経歴としては誰もが知っている月間数千万人が利用するサービスの開発をしたり、今でも月間数百万人が訪問する規模のWordPressサイトの運営しております。WordPressを触らない日はありません。
そんな私がプロの目で解説していきます！
WordPressのレンタルサーバー「ConoHa WING」について
本題に入る前にConoHa WINGについて紹介しておきます
| 料金・価格の安さ (コスパ) | |
|---|---|
| お試しのしやすさ (無料お試し体験) | |
| 性能・スペック (表示速度・耐久性) | |
| トラブル解決 (サポート体制・情報量) | |
| 使いやすさ・操作性 (初心者向) | |
| 総合評価 |
東証一部上場企業のGMOインターネットが運営。全ての評価において一番バランスがよく及第点以上。最短１時間から利用できる。
また、以下を前提条件として移行手順の解説を進めます。
今回、WordPressサーバーの引っ越し先であるConoHa WINGの新規登録自体も終わっている
移行先で運用するドメイン自体の取得は終わっているものとします。
ConoHa WINGの新規会員登録が終わっていない方はこちらを参考にして見てください。
その他のレンタルサーバーサービスについてはこちらの記事で紹介しています。
では本題のConoHa WINGのサーバー引っ越し手順の解説に戻ります。
全体のデータ移行手順の流れ
全体のサーバーの移行手順は以下の流れで紹介していきます。
- ①移行先サーバーでドメインを追加設定する方法
- ②独自SSLを設定する方法
- ③WordPressのデータを全て自動データ移行する方法
- ④移行先のデータを本番URLで最終確認する方法
- ⑤本番リリース(ネームサーバー切り替え)
- ⑥本番リリース後の確認や注意点
①移行先サーバーでドメインを追加設定する方法
ConoHa WINGでサーバー移行先のドメインを設定します。
この設定は「引っ越し先のConoHa WINGでこのドメインを使い始めますよ」という初期設定のようなものです。
ConoHa WINGの管理画面にログインして以下のようにクリックします。
サーバー管理＞ドメイン＞＋ドメイン
ドメイン名を入力します。
現時点では無料独自SSLを「利用する」にしても、ネームサーバーの設定上サーバーがConoHaに向いてないので失敗します。
が、ここでは以下の表示で正常です。
これらの意味は、ネームサーバーがConoHaに向いてないので独自SSLは有効になっていないけど、ConoHaへの新ドメインの利用追加設定自体は正常に終了しているということです。最後にネームサーバーを切り替えればよいだけです。
なお、ドメイン追加の設定が有効になるまで5～10分かかるようです。設定作業自体はこのまま進めてかまいません。
②独自SSLを設定する方法
先ほど「ドメインの追加設定」の際に追加したので、特に単体で「独自SSL設定」をする必要はありません。
参考までに、個別の独自SSL設定をするには以下のようにアクセスします。
③WordPressのデータを全て自動データ移行する方法
ドメイン追加、独自SSLの設定を終えたら、いよいよWordPressの全データを移行(引っ越し)します。
面倒な手間やスキルのいらないConoHa WINGが公式の機能である「WordPressかんたん移行」を使います。
これはサーバー移行元に管理者権限でアクセスさせて全てのデータをエクスポートし、移行先(ConoHa WING)にデータ転送してインポートするということを自動でやってくれます。
ConoHa WINGの「WordPressかんたん移行」を実行する
管理画面から以下のようにアクセスします。
サイト管理＞サイト設定＞＋WordPress
移行元と新しい移行先の設定内容を入力します。移行元も移行先も同じURLです。
| 設定内容 | 説明 |
|---|---|
| インストール方法 | かんたん移行を選択 |
| テスト移行 | 利用しない。今回はもっと精度の高いテスト方法を紹介します。 |
| バージョン | バージョンは4系か5系か。WordPress管理画面下部のバージョンと同じものを選んでください。 |
| 移行元ユーザー名・パスワード | 本番の管理者ユーザーのものを入力 |
| データベース | 移行元とは同じにはできません。DB名、ユーザー名は何でもよい。ランダムな文字列が望ましい。忘れてもあとで確認しようと思えばできます。接頭辞はセキュリティ的にランダムに指定されます。 |
| テーマのインストール | 新規でテーマを入れるか？ということなので「なし」にします。 |
保存が成功するとこのようなバルーンが出ますが、これは移行が始まったというだけで、完了したわけではありません。
データ移行の進捗は以下から確認できます。
サイト管理＞サイト設定＞WordPress
かかる時間はサイトの規模にもよりますが、数百記事のサイトで1～2時間程度はかかりました。エックスサーバーは同じデータ量で10～20分だったので、やや長めの印象です。
定期的に進捗をチェックしましょう。1～2時間後にエラー終了というのが最悪なので、先に以下のエラー項目をチェックしてから移行を始めると無駄が少ないかもしれません。
特に大きなファイルなどがある場合、最後の最後にエラーが出てしまうので待ち時間が無駄が大きいです。
ConoHa WINGの「WordPressかんたん移行」でデータ移行エラーが出る
１度でデータ移行がうまく行けばよいのですが、エラーが出て移行が失敗することも多いと思います。
筆者の環境でも何度か以下のようなエラーが出ました。
解決方法のポイントを解説していきます。
WordPress簡単移行エラー例
エラーの原因は主に以下の２パターンになると思います。
- A. サーバー移行元のWordPressへの管理者ログイン失敗
- B. サーバー移行元のWordPressのデータが大きすぎる
- C. その他のエラー
| パターン | エラーメッセージ |
|---|---|
| A. サーバー移行元のWordPressへの管理者ログイン失敗 |
「ファイルサイズが大きい、またはファイル数が多すぎます」 「移行元にログインができません」 「移行元サイトログイン確認」 |
| B. サーバー移行元のWordPressのデータが大きすぎる |
「テーブル容量・行数エラー」 「予期せぬエラー」 |
| C. その他のエラー |
「移行元にプラグインがインストールができません」 等 |
A. サーバー移行元WordPressへの管理者ログイン失敗
パターンAのメッセージの場合は移行元WordPressへのログインが失敗しています。
そもそもログイン名やパスワードが間違っているなどは当然の事、管理者権限ユーザーでログインしているかどうか確認しましょう。
また、ログイン画面へのBasic認証やGoogle reCAPTCHAなどセキュリティ系のプラグインの導入もよく失敗の原因になります。
一時的に無効にしてしまいましょう。
どうしても解消しない場合は最悪１つ１つプラグインやレンタルサーバーのセキュリティ設定などOFFにしていく必要があります。
例えば移行元がエックスサーバーの場合は以下のようなコントロールパネル上で行うセキュリティ設定などです。
各レンタルサーバー会社に様々な設定が存在します。
B. サーバー移行元WordPressのデータが大きすぎる
パターンBのメッセージの場合時は移行元WordPressの何らかのデータが大きすぎるためです。
何かのプラグインのログなどでデータベースの行数や容量が多すぎる場合(数十万行～数GB～)や、バックアッププラグインなどで数GBのファイルなどが存在する場合は失敗してしまうようです。原因をとりのぞいてください。
データベースの行数・データ容量を調べてレコードを削除する
データベースの行数を調べるにはDB管理ツールphpMyAdminでデータベースの中身をのぞいてみましょう。
phpMyAdminは通常レンタルサーバーの管理パネルから利用できる場合が多いですが、よくわからなければこのプラグインが便利です。
WordPressプラグイン「WP phpMyAdmin」
管理画面にphpMyAdminへのログインリンクが貼られるだけのプラグインです。
phpMyAdminでテーブルの行をチェックして大きすぎるものがないか確認してください。
あった場合は「空にする(truncate)」からデータレコードを削除できます。「削除(Delete)」はテーブルごと削除なのでしないでください。
※そのテーブルのデータを削除してよいかどうかは各自判断してください。
WordPressディレクトリのファイルの容量を調べる
WordPressのディレクトリ(フォルダ)内に大きなファイルがないか調べます。FTPソフトを使うと容量を取得できることが多いです。
筆者が利用しているFTPソフトの「FileZilla」ではこのようにサイズを見れます。
他の人気FTPソフト「FFFTP」にもディレクトリの容量計算機能が存在します。
1GBのバックアップファイルがあるようです。
必要であればダウンロードしてから削除するなどの対応をしてください。
※そのファイルを削除してよいかどうかは各自判断してください。
C. その他のエラー
その他のエラーが起きている場合、移行プログラムのアクセスに対して何らかのプラグインが影響を与えている可能性も高いので一度プラグインを全て無効にして移行を実行してみてください。
移行が済んでから全て有効に戻しましょう。
【プラグインを全て無効化する手順】
エラーが出る場合は公式ページも一応参考にしてみてください。
④移行先のデータを本番URLで最終確認する方法
サーバーの引っ越し(データ移行)が終了したら次はリリース前の最終確認です。
ここで紹介する方法がすごい点はブラウザ上での確認テストをリリース前に「本番と同じURL」で行えることです。
本番と同じURL。不要なトラブルを避けるにはこれが本当に重要です。
おそらく他のほとんどのサーバーの引っ越し方法の場合、この手順を仮のURLなどで進めようとするためにサービス停止期間ができてしまったり、完全なテストができずに移行後の不具合などのリスクが増えてしまいます。
システムのてテストは本番とまったく同じ環境でしっかり確認するのが鉄則です。
それには「本番のURLで引っ越し先サーバーの内容を見る」必要があります。
一見、矛盾した難しいことに聞こえますが、以下の設定を進めていくことで「本番のURLで引っ越し先サーバーの内容を見る」ことができます。
移行先サーバーのIPアドレスを確認
事前準備として移行先サーバーのIPアドレスを確認しておきます。
ConoHa WINGの確認方法は以下のように管理画面から見ることができます。
サーバー管理＞契約情報＞サーバー情報
このIPアドレスは後程使うので控えておいてください。
本番のURLで移行先サーバーの内容を見るための準備
それでは「本番のURLで移行先サーバーの内容を見る」ための設定をしていきます。
サーバー移行後のサイトの確認には以下の2つのツールを使います。
なお、ブラウザはChromeを使います。
- Chromeアドオン「Website IP」
- デスクトップ版アプリ「SwitchHosts」
ちょっと面倒ですが、２つとも使い方はものすごく簡単。手法としてはプロが開発でも使う高度なものですので覚えておいて損はありません。
ぜひやってみてください！
Chromeアドオン「Website IP」のインストール
Website IPは現在見ているサイトのサーバーIPアドレスを表示してくれるChromeアドオンです。
Chromeで以下にアクセス。
https://chrome.google.com/webstore/detail/web…
から「追加」ボタンをクリックするだけです。
インストールすると右下に現在表示しているサイトのIPアドレスが表示されるようになります。
この機能を利用して、移行元の本番サイトか？リリース前の移行先のサイトか？を見分けるのに使います。
※移行元も移行先も見た目がまったく同じため今どちらを見ているか区別がつかないためです。
デスクトップ版アプリ「SwitchHosts」のインストール
「SwitchHosts」は簡単に言うとブラウザにURLを入力されたとき表示されるサイトを本来のものと入れ替えてしまえるツールです。
その仕組みはコンピュータ内のドメインに対するIPアドレスの紐づけの設定を変えることで実現しています。
いわゆるhostsファイルの変更というものです。
この機能を使ってブラウザに本番のURLを入力してもサーバー引っ越し後のページを表示させる、などという事ができます。
リリース前の一時的なテストに使います。
- ※同名のアプリは無数にあるので注意
- ※WindowsだけでなくMacOSなど他にも対応しています
- ※chrome上のhosts切り替えアドオンはいくつかありますが、2022年現在は他はどれも機能しなくなっていました。
では早速インストールしていきましょう。
以下のリンクからDownloadに進みます。
OS、マシン環境別にインストーラーが並んでいます。
バージョンはその時期によって違うと思いますが自分の環境にあったものを選んでください。
windowsの場合は一番上のexeファイルでよいと思います。
インストーラーをクリックすると、環境によっては「危険ですがインストールしますか？」的な意味合いの警告が出るかもしれません。
hostsファイルの修正は悪用すれば、URLを偽った別サイトの表示さえできてしまうので、通常の使い方ではないよ？大丈夫？という警告です。
今回はそれがやりたいので、そのまま進めてください。
次へ。
インストール。
アプリが起動します。
＋をクリックして設定を追加します。
好きな設定の名前をつけてOKをクリック。
(※実際はドメイン名＋レンタルサーバー名などの組み合わせがいいと思います)
右側のエリアに
IPアドレス＋スペース+ドメインを記入します。
(ドメインはスペースに続けて複数記述可能)
この設定はこの本番ドメインを偽(リリース前のデータ移行先サイト)のサイトに入れ替えてしまうという設定です。
トグルスイッチをONにすることで設定が有効になります。
おそらくここでほとんどの人がエラーになると思いますので補足しておきます。
「SwitchHosts」のエラーが起きたら
通常の環境だと設定を有効にした際に、おそらく以下のようなエラーが起きるはずです。
「No permission to write to the Hosts file.」
これはシステムファイルであるhostsファイルへの書き込み権限がないことを表します。hostsファイルはとても大事なシステムファイルなので、上書きには管理者権限が必要です。
管理者権限でアプリを起動するため、いったん「SwitchHosts」を終了させます。
再度、スタートボタンから「管理者として実行」でSwitchHostsを起動させます。
(Windows10の例)
これでトグルスイッチを有効にできるはずです。
今度はこんなメッセージになります。
無事、SwitchHostでhostsへの追加設定が終わったら、Chromeで本番のURLにアクセスしてください。
サイトの内容が表示されて、さらに先ほどインストールしたアドオン「Website IP」によって、ブラウザの右下に出るIPアドレスが今設定したIPアドレスと一致していれば成功。
「本番のURLで引っ越し先サーバーの内容を見る」状態の完成です。
うまくアドレスが切り替わらない場合はchromeをいったん再起動してアクセスしてみてください。
(ダメなら全てのChromeウィンドウを閉じるか、最悪PCを再起動してみてください)
おそらくChrome全閉じでIPが切り替わるはずです。
これでリリース前のサイトの内容を確認していきます。
本番のURLでリリース前にサイトを最終確認する
では最終確認の準備が全て終わったところで、いよいよ実際にサーバー移行先のサイトを見てまったく同じ見た目や動作をしているか確認してみましょう。
確認項目はそのサイトによって様々だと思いますが、ここでは共通する基本的な確認項目をピックアップしてみます。
以下に確認項目の例を示しますので参考にしてみてください。
1.検索エンジンからの見た場合
- サイトマップ/sitemap.xml等は作成されているか？中身は大丈夫か？
- /robots.txtファイルは移行元と先で変化ないか？
- 設定したリダイレクトなどはうまくいっているか？
2.マーケティングやビジネス用のタグ
サイトでビジネスを行っている場合などは、以下のテストをしっかりやっておきましょう。
- Googleアナリティクスは反応しているか？(リアルタイムで確認)
- Googleサーチコンソールは動いているか？(後日確認)
- 他、自分で設置したコンバージョン設定などの動作を最終チェック
3.サイトの管理機能など
サイトの管理運営もスムーズに移行できるように以下だけは最低限やっておきましょう。
- FTPアカウントにはログインできるか？
- WordPressダッシュボードにはログインできるか？
4.ディレクトリを比較
あくまで「WordPress」の移行機能なのでWordPressのディレクトリ以外はコピーされないことが多いです。
(/wp-admin/, /wp-content/, /wp-includes/のみ)
独自に作ったディレクトリやファイルがある場合は移行されていないと思います。
新旧で差異がないか確認してみましょう。
WordPressのシステムファイルもレンタルサーバーの初期設定になっていることがほとんどです。
特に注意なのが.htaccessとwp-config.phpやwp-setting.phpです。
移行すべき設定があれば、その部分を手動で移行しましょう。
- 独自に作成したフォルダやファイルの移行の漏れなどがないか？
- 特に初期化されている.htaccessやwp-config.php、wp-setting.phpの設定の移行は必要ないか？
5.テーマとプラグイン
テーマとプラグインが動作しているか１つ１つチェックします。
できれば以下のことをやってみましょう。
- テーマを切り替えてみる(別のテーマにしてからもとに戻す)
- 全てのプラグインをいったん無効にして再度有効にしてみる。
※プラグインの有効化のタイミングで何かの処理を実行する場合も多いので、プラグインの無効化→有効化だけで解消する問題も多々あります。
特に.htaccessを修正するような、リダイレクトやセキュリティ関係のプラグインは移行のタイミングで無効化されることが多いです。
6.他レンタルサーバー特有の機能
- レンタルサーバー間でのセキュリティ設定の差異などをチェック
各レンタルサーバーは特にセキュリティ面など独自で様々な機能を提供しています。
多くの場合はデフォルトのままでも問題はないと思いますが、独自でカスタマイズした場合などは差異があった場合に問題ないかチェックしておきましょう。
おまけ(トラブルシューティング)
実際にConoHa WINGにサーバー移行中に起きた不具合の解消方法を紹介しておきます。参考にしてください。
関係ない場合は読み飛ばしてください。
無料テーマCocoon(コクーン)のスキンが適用されない
無料テーマCocoonのデザイン(CSS)がちょっと変だなと思ったらCocoonスキン選択がなくなっている可能性があります。選択しなおしてください
無料テーマCocoon(コクーン)の設定保存ができない
管理画面でCocoonの設定保存しようとすると以下のような画面でエラーになってしまう場合。
原因はConoha WINGにデフォルトで導入されているSiteGuard Liteという機能です。
おそらくCocoon内部の構造がセキュリティ的に競合してしまっているみたいなので、管理者限定で無効にしてしまいましょう。
ConoHaの管理画面から無効にできます。
サイトセキュリティ＞WAF
履歴から１つ１つ除外していきます。
これで更新できるようになったはずです。
⑤本番リリース(ネームサーバー切り替え)
引っ越し先の最終確認が終わったらいよいよ本番リリースです。
本番リリースに必要な最後の作業
最後の作業内容はドメイン管理サービス（レジストラ）のネームサーバー登録を変更することです。この設定がインターネット上に反映された時点でサーバー移行先が本番となり、ユーザーがアクセスしはじめます。
列車の線路の進路切り替えのようなイメージでしょうか？わかりにくかったらすみません。。
レジストラにネームサーバーを登録する、とは？
「レジストラにネームサーバーを登録する」ということは簡単に言いかえると「ドメインの管理人(レジストラ)にサーバーの居場所を知っている案内人(ネームサーバー)」を教えてあげることです。この設定はドメインを取得した元のドメイン管理サービス(レジストラ)側での操作が必要です。
ドメイン管理サービス自体は各レンタルサーバー会社がサーバー事業とセットでやっている場合が多いです。レンタルサーバーの申し込みと同時にドメインを取得した場合などは大抵そのパターンになります。
ここでは、例としてお名前.comの例だけ示します。
(※移行元でドメインを取得した場合は移行元レンタルサーバーの管理画面内での作業になると思います。)
他のサービスの場合も「ドメインのネームサーバー変更」という趣旨のメニューを探してみてください。
ネームサーバーを確認する
レジストラに設定すべきConoHa WINGのネームサーバー名は以下のページから確認できます。
ns-a1.conoha.io
ns-a2.conoha.io
というのがそれにあたります。これを控えておきます。
レジストラでネームサーバー設定する
お名前.comでドメインを取得した場合
お名前.comがレジストラの場合、お名前.comにWordPressのサーバーの場所を知っている案内人(ネームサーバー)を登録します。
お名前comにて次のようにアクセスして、先ほど控えたネームサーバー名を最低2つ記入します。
現在の設定はすべて消して、上書きしてください。
この設定の反映は数分～数時間かかることが多いです。
（お名前.comの公式では最大72時間とありますが、さすがにそこまでかかったことは１度もないです）
ネームサーバーの反映が終われば、自動的にそのタイミングが本番リリースです。
反映のタイミングのこともあるので、しばらく新WordPressへの修正はhosts経由で行うかIPを確認した上で行いましょう。
いろいろ修正したけど実は古いサーバーを修正してた！！なんてことになったら最悪ですもんね。
⑥本番リリース後の確認や注意点
おめでとうございます！これで本番リリースに向けての作業は終了です。
リリース後の複数端末でのチェック
あとは、本番リリース後も最終確認の際のチェック項目を再度絞ってやってみるとよいでしょう。
「SwitchHosts」によるhosts設定をしてないパソコンやスマホからのチェックなども忘れずに。
またサーバー移行後しばらくは、小まめにアクセス解析やコンバージョンなどのデータは見るようにしましょう。
サーバー移行元レンタルサーバー契約の維持
新サイトのリリース後、新しい環境で何があるかわかりません。何かトラブルがあっても設定などを復元できるようサーバー移行元のレンタルサーバー契約は念のため1～2か月は残しておいた方がよいでしょう。安定稼働を確認してから契約解除しましょう。
「SwitchHosts」hosts設定の削除
また、落ち着いてからでもいいので、設定した「SwitchHosts」のhosts設定も全て無効にしておきましょう。
ドメイン移管について
ドメイン自体をサーバー移行元のレンタルサーバー会社で取得した場合、サーバー利用の契約とは別に、ドメインの管理契約だけはその会社と結び続けることになります。ドメインを持ち続ける場合は、1～数年単位で更新の料金を支払うことになります。
ドメイン管理にも携帯電話番号のMNPのように乗り換えが存在しますが、決して必須というわけではないでしょう。
乗り換え手続き自体もそこそこ大変です。また、取得後2か月未満のものやドメインの種類によっては移管に対応してないドメインも存在します。
最後に
最後までお読みいただきありがとうございました！
長い作業でしたが、お疲れさまでした。
終わりにレンタルサーバー比較や他のレンタルサーバーにデータ移行(引っ越し)するまとめ記事を紹介しておきます。
移行先のConoHa WINGについて
| 料金・価格の安さ (コスパ) | |
|---|---|
| お試しのしやすさ (無料お試し体験) | |
| 性能・スペック (表示速度・耐久性) | |
| トラブル解決 (サポート体制・情報量) | |
| 使いやすさ・操作性 (初心者向) | |
| 総合評価 |
東証一部上場企業のGMOインターネットが運営。全ての評価において一番バランスがよく及第点以上。最短１時間から利用できる。
