webサイトのサーバー移行をするときのポイント

キーワード：

アクセス数が増加しているのにサーバー側の処理能力が不足している
経費削減のため現在よりも安いサーバーにwebサイトを引っ越ししたい
トラブルや不具合が多いため、別のレンタルサーバーに変えたい
現在利用中のサーバーが昔契約したかなり古いプランのもので機能が不足している

など、webサイトを現在利用中のサーバーから別のサーバーへお引っ越し（移行）する理由は様々です。特に古いサーバーではセキュリティアップデートが適用されず、脆弱性が増すため、古いサーバーを使い続けることはリスクが伴います。弊社にも、webサイトを別のサーバーに移行されたい旨のご相談を多くいただきます。

しかしながら、企業のweb担当者さまには、『サーバー移行の手順が良くわからない』『サーバー移行で間違えてしまったらどうしよう』という不安が付きまといますよね。サーバー移行の手続きは、新旧のサーバー会社やドメイン管理会社などの関係先への手続きが必須になりますし、手順を間違えると、サーバー移行の途中で作業が中断してしまったり、webサイトに動作不良が生じたり、最悪の場合、webサイトが一切表示されなくなったりするなど、思わぬトラブルが発生しかねません。

そこで、今回はサーバー移行作業を不安に思われている企業のweb担当者さまに向けて、サーバー移行の際のポイントを分かり易くお伝えします。今回前提として下記のような手順でサーバー移行作業を行います。

本記事を参考に、ぜひ実践してみてください。

サーバー移行についてルート・シーへ相談したい方はこちらのお問い合わせフォームから。

1.本番環境のデータのバックアップを取得する

まずは、webサイトの本番環境のデータのバックアップを取得しましょう。このバックアップデータは「バックアップデータ」かつ「webサイトの本番環境のデータ」として使用します。

対象となるデータはファイルデータとデータベースのデータ

webサイトのデータには大別して2種類あります。1つはファイルとしてのデータ、もう1つはデータベース(DB)のデータ（WordPressなどのCMSを利用している場合：以下同）になります。ファイルのデータはサーバーへのFTP接続※の上、FTP内の自ファイルの全て、もしくは新サーバーにてwebサイトの本番環境を再現するのに必要なファイルのみを取得します。

※FTPではなくSSH接続が必要な場合があります。

FTPクライアントソフト「WinSCP」を使いファイルデータを取得している例

注意: 既存サーバー内に移行対象となるwebサイトの本番環境以外のデータが存在し、それらのデータが消失しては困る場合は、それらを含めてファイルデータのバックアップを取得しておきましょう。現場によりファイルの置き場所として便宜的にFTPを利用される場合があり、「webサイトの本番環境のデータ」のみを意識していると意外と忘れられがちです。

データベースのデータのバックアップ取得方法

WordPressなどのCMSを利用している場合には、データベースのバックアップも取得しなければなりません。データベースのバックアップ取得には「phpMyAdmin」というウェブブラウザでデータベースを操作するためのデータベース接続クライアントツールを利用する方法が一般的です。多くの場合phpMyAdminはレンタルサーバーのコントロールパネル内から利用できますので、コントロールパネルにログインしてphpMyAdminの画面を開きましょう。

phpMyAdminからデータベースのバックアップデータを取得する手順は簡単です。phpMyAdminの上部のメニューから「エクスポート」を選択し「簡易」の設定のまま下部の「エクスポート」ボタンを押します。これで、データベースのデータをSQLファイルとして取得できました。ちなみに、SQLファイルとはデータベースを操作するためのSQL文(言語)が書かれているテキストファイルのことです。このSQLファイルを別のデータベースに読み込ませることで、データベースの中身を別のデータベースに複製することができます。

phpMyAdminの操作画面例

注意: どのデータベースが「対象となるwebサイト本番環境のデータベース」なのかを事前に把握しておく必要があります。「本番環境のデータベースのデータと間違えて、テスト環境のデータベースのデータを取得していた」なんてことにならないように、対象となるwebサイト本番環境のデータベース名は事前にWordPressなどのCMSの設定ファイル(例:wp-config.php)から調べておきましょう。

2. 新サーバーに本番環境のデータを移行

webサイトの移行先となる新サーバーを新たに契約した後は、（旧サーバーの状態を新サーバーで再現するために）まずは新サーバーのコントロールパネルから必要な設定を行います。具体的には、①旧サーバーでのwebサイト本番環境のドメインと同じドメインを登録、②データベースの作成を行います。

①では、主となるドメインを登録する他に、サブドメインを登録できる場合があります。例えば、主ドメインのテスト用環境として「test.」というサブドメインを作成し、そのサブドメインをテスト用環境として運用することが可能です。

②のデータベースの作成時には、旧サーバーのwebサイト本番環境のデータベース名と同じデータベース名を付けます。（同じデータベース名にした方が移行作業をスムーズに進められます。）

テスト用環境の構築時の注意点

「test.」等のサブドメインを使用してテスト用環境を新たに構築する場合は、ファイルもデータベースもテスト環境用に用意しなければなりません。その際、テスト環境用のデータベースの中で本番ドメインの記述がある箇所は全て頭に「test.」を付けることや、テスト環境用のWordPressなどのCMSの設定ファイル(例:wp-config.php)のうち、参照データベースをテスト環境用のデータベース名に変更する必要があるなど、作業量は大幅に増える点にご注意ください。

サーバーによりコントロールパネルの画面や操作手順は異なりますので、不明点があれば契約したサーバーのヘルプページ等を参考にしましょう。

新サーバーにwebサイトの本番環境を再現

続いて、新サーバーにwebサイトの本番環境を再現(複製)するため、取得したバックアップデータを新サーバーに配置します。通常、新サーバーを契約すると、コントロールパネルのIDやパスワード、FTP/データベースのIDやパスワード等の情報が入手できますが、それらを使って、取得済みのバックアップデータのうち、ファイルはFTPにて適切なディレクトリ（https://本番環境のドメイン名/となるように）にアップロードし、データベースは新サーバーのコントロールパネル内のphpMyAdminからSQLファイルをインポートします。

この時、FTPでファイルをどのディレクトリにアップロードするのか、またはphpMyAdminからどのデータベースにSQLファイルをインポートするのかは、旧サーバーのwebサイト本番環境の状態を参照しながら、新サーバーの方に再現しましょう。（FTPの中身のディレクトリ構造は旧サーバーと新サーバーで少し異なると思いますが、webサイトのドキュメントルートを考慮してファイルをアップロードする必要があります。）

3. 新サーバー側の本番環境の表示確認

ファイルとデータベースを新サーバーに適切に配置できたら、次に新サーバー側のサイトの表示確認を行います。この時点では、ブラウザでhttps://本番環境のドメイン名/
を表示すると、旧サーバーの方の本番環境が表示されることになりますが、前述の「新サーバーにファイルとデータベースを適切に配置できたかどうか」を確認するには、ブラウザでhttps://本番環境のドメイン名/にアクセスしたときに、新サーバーの方の本番環境が表示されるように設定を行うことが適切です。

hostsファイルの編集

そこで、WindowsやMacではhostsファイルというシステム設定ファイルを編集することで、通常DNSサーバーが担っている「ドメイン名とIPアドレスの対応」を自身のPC内で処理(名前解決)することができます。Windowsの場合は、hostsファイルの場所は下記になります。

C:\Windows\System32\drivers\etc\hosts

このhostsファイルをテキストエディタで開き、定められた形式の通りにドメイン名とIPアドレスの対応を記述します。（念のため、編集前にhostsファイルのバックアップを取っておくと良いでしょう。）

記述形式: 新サーバーのグローバルIPアドレス　本番環境のドメイン名; ↓
記述例: 555.666.777.888 sample-site.co.jp

新サーバーのグローバルIPアドレスは、新サーバーの契約完了時にレンタルサーバー会社から届くメールに記載されていることが多く、他にはサーバーのコントロールパネル内からもグローバルIPアドレスが参照できるかと思います。

hostsファイルを上書き保存したら、再度ブラウザでhttps://本番環境のドメイン名/
を表示してみてください。旧サーバーの方の本番環境ではなく、新サーバーの方の本番環境が表示されるはずです。WordPressなどのCMSを利用しているサイトの場合は、CMSの管理画面にログインできるかどうかも併せて確認します。

ただし、旧サーバーの本番環境をそのまま複製しただけなので、表示されているページが本当に新サーバーの方の本番環境なのかどうかを見分けることは難しいでしょう。そこで、見分ける方法の一つとして、試しに新サーバーの本番環境の方のトップページに（今ブラウザに表示されているページが新サーバー側の本番環境であることがわかるように）一時的に何らかの変更を加えても良いかもしれません。その際は、ページの表側ではなく、念のためページの裏側のソースコード上でのみ確認できるようなコードを記述すると無難です。もし万が一間違えて旧サーバーの方の(現)本番環境を変更してしまっても、特段の支障は出ないためです。

httpsへの記述変更

関連して、旧サーバーの本番環境が「http」通信で、新サーバーの本番環境が「https」通信となることが想定される場合は、読み込みエラーを未然に防ぐため、新サーバーの本番環境側各ページのソースコード内の「http」の箇所を「https」に書き換える必要があります。（「https」通信＝SSL適用となるため、前提として新サーバーのコントロールパネルにおいて、有料・無料のSSLサーバー証明書の適用作業が必要になります。）

httpsへのリダイレクト設定

さらに、「http」でサイトに流入してきた場合を想定して、「http
⇒https」へのリダイレクト(自動転送)設定をしておくと尚良いでしょう。リダイレクト設定はサーバーによってはコントロールパネル内から設定できる場合もありますが、webサーバーソフトウェア「Apache」のサーバー設定ファイルである「.htaccess」ファイルで行うことが一般的です。（ちなみに「.htaccess」ファイルの記述内容は、「.htaccess」ファイルが置かれているディレクトリおよびその下層のディレクトリに対してのみ適用されます。）

この時点で新サーバーの方の本番環境が上手く表示されない場合は、これまでの手順のどこかで間違っていることが考えられますので、手順を見直してみましょう。

4. DNS（ネームサーバー）の変更

最後にDNSの変更です。DNS（Domain Name System）とは、前述のhostsファイル編集のところでも少し触れたように、ドメイン名とIPアドレスを対応(変換)するためのインターネット上の仕組みのことです。通常サーバー移行の際は、この「DNSの変更」を行います。なぜなら、サーバーが変わるとそれに伴いIPアドレスも変わるためです。

ドメインの移管とDNSの変更

「ドメインの移管（ドメインの管理会社を変更すること）」と「DNSの変更（ネームサーバーを変更すること）」は、似ているようで実際には異なる概念ですので注意が必要です。サーバー移行の要件から、今回やろうとしていることが「ドメイン移管」なのか、「DNSの変更」なのか、それとも「ドメイン移管とDNSの変更の両方」なのかを整理した上で、必要に応じてドメイン管理会社やDNSの管理会社に変更申請の手続きを行うことになります

本記事では、弊社で取り扱うサーバー移行の一般的な例として、今回「DNSの変更のみを行う」ことを前提に説明を続けます。

さて、「DNSを変更」するとどうなるのかですが、DNSを変更すると「どのサーバーを利用するかを変更する」ことができます。具体的には、https://本番環境のドメイン名/ においてDNSの変更前は旧サーバーの本番環境が表示されるのに対し、DNSの変更後は新サーバーの本番環境が表示されるようになります。（「DNSの切り替え」と言うこともあります。）

DNSの変更方法

DNSの変更は、通常ドメインの管理会社（レンタルサーバー会社と同じ場合もある）のコントロールパネル内から行います。ただし、DNS変更の方法にも「ネームサーバーの変更」と「DNSのAレコードの変更」の2種類あり、どちらの方法とするかは状況によります。
また、DNS変更の手続きが完了しても、すぐにはその変更内容が反映されない点に注意が必要です。インターネット上には通信速度向上のため「キャッシュDNSサーバー」というDNS情報を一定期間保持する仕組みがあり、一定の期間が経過しないとDNS情報が更新されないからです。一般的には最大72時間程度でDNS変更が反映されると言われることが多いですが、私の実例ですと、数時間程度でDNS変更が概ね反映（浸透）されることが多いと感じています。

DNSの変更後の注意点

DNS変更後の「DNSの浸透」の期間中は、ネットワーク環境によって新・旧のどちらかのwebサーバーおよびメールサーバーが参照されるため、DNS変更後もしばらくは旧サーバーの契約および状態を維持しておくと良いでしょう。そして、DNS変更後72時間以上が経過し、新サーバーの方のwebサイトが表示されていることが確認できた後にwebサイトもメールも新サーバーの方を向いていることが確認できた後に、（若干の猶予期間を設けた上で）旧サーバーを解約すると良いかと思います。ただし、旧サーバー解約の前には、念のため以下の点をご確認ください。