サーバー移行の手順や注意点が丸わかり!ケース別の移行方法から必要な費用まで解説

サーバー移行の手順や注意点が丸わかり!ケース別の移行方法から必要な費用まで解説

システムの老朽化やパフォーマンス改善、またはコスト削減などを目的として、サーバー移行を検討する機会があるかと思います。しかし、サーバー移行は単なるデータの引っ越しではなく、慎重な計画と実行が求められる重要なプロジェクトです。本記事では、サーバー移行を検討すべきタイミングから具体的な手順、注意点、さらにはケース別の移行方法や費用まで、サーバー移行に関する全てを網羅的に解説します。

この記事でわかること

① サーバー移行を検討すべきケース5選
② 移行先となるサーバーの選び方
③ サーバー移行の8つのステップ
④ サーバー移行の注意点
⑤ 移行先サーバー別の移行方法
⑥ サーバー移行時の一般的な費用
⑦ サーバー移行時のFAQ

目次

サーバー移行を検討すべきタイミング

サーバーの移行には労力が伴うため、闇雲に行うものではなく、現在のサーバー環境に明確な課題が生じたタイミングで検討するのが望ましいです。以下に、特にサーバー移行を検討すべき代表的な状況を紹介します。

サイト表示速度の低下が見られる場合

Webサイトやアプリケーションの表示速度が以前より遅くなっていると感じる場合は、サーバー移行を検討するサインです。アクセス数の増加やデータ量の増大に対して、現在のサーバーのCPUやメモリなどスペックが不足していると、処理能力が追いつかず表示が遅延してしまいます。

このような表示速度の低下を利用者目線で考えてみると、ページ離脱や購入意欲の阻害などにつながるため、早めに対策を講じることが重要です。実際に、ページの読み込み時間が1秒から10秒に増加すると、モバイルユーザーの直帰率(Bounce Rate)が123%増加するというGoogleの報告もあるほどです。自社サイトの表示速度をチェックするためには、PageSpeed Insightsなどのツールを使用して定期的にチェックすると良いでしょう。

引用:Find out how you stack up to new industry benchmarks for mobile page speed

サイト表示速度の低下原因となりうる例

・サーバーのCPU使用率が常時70%を超えている場合
・WordPressなどのCMSを運用している場合、プラグインの増加に伴うリソース消費の増大

サイト表示速度の低下が見られる場合

サーバーの安定性に問題がある場合

現在のサーバーで頻繁に障害やダウンが発生したり、再起動が必要になるなど安定稼働に支障が出ている場合も、移行を検討すべきです。サーバーがしばしば落ちる原因としては、ハードウェアの老朽化、メモリ不足によるスワップの多発、ソフトウェアの不具合、さらに先ほどと重複しますが、トラフィック急増による負荷過多など様々考えられます。

例えば物理サーバーであれば、ハードディスクや電源の故障が増えてきたタイミングがひとつの目安です。このように安定性に不安がある場合、問題が慢性化する前により信頼性の高い新サーバー環境へ移ることで、サービス停止のリスクを減らせます。

サーバーの安定性に問題がある場合

セキュリティリスクが増大した場合

現在利用しているサーバー環境のセキュリティが十分でないと感じた場合も、サーバー移行を検討すべき重要なタイミングです。例えば、OSやミドルウェアのサポート終了に伴いセキュリティパッチが提供されなくなった、管理しているサーバーが古い暗号化方式(TLS1.0など)しか対応していない、といったケースが挙げられます。

こうした状態を放置すると、脆弱性を突かれた攻撃や情報漏洩のリスクが高まり、ビジネスへの甚大な影響をもたらしかねません。事業規模や取り扱うデータの重要度に応じて、より高い安全性を求める場合には、セキュリティ強化を目的としたサーバー移行も有効な施策です。

セキュリティリスクが増大した場合

技術トレンド・新要件に対応したい場合

システムの新たな要件や技術トレンドへの対応が求められる場合も、サーバー移行を検討する好機です。
例えば、Webアプリケーションでモダンなフレームワーク(Next.js、Laravelなど)を使いたい場合、既存サーバーでは動作要件を満たせず、新環境の構築が必要になることがあります。

また、コンテナ技術(Docker、Kubernetes)を活用したい、AIや機械学習の活用をしたい、ゼロトラストネットワーク構成に対応したい、といった要望が出てきた際も、現行サーバー環境では対応が難しい場合が多いでしょう。

このような場合、新たな技術要件に最適化されたインフラへ移行することで、最新技術を活用した開発や運用が可能となり、ビジネス競争力の向上にもつながります。将来を見据えた技術基盤の整備として、サーバー移行は積極的に検討すべき選択肢となります。

技術トレンド・新要件に対応したい場合

コスト最適化・運用効率化を図りたい場合

サーバー運用にかかるコストを見直したい、運用管理負荷を減らしたいと感じた場合も、移行を検討すべきタイミングです。特にオンプレミスサーバーを長年利用している場合、ハードウェアの老朽化による保守費用の増加や、人的リソースに依存した運用管理コストが無視できなくなってくるケースが目立ちます。

上記のような場合は、クラウドサーバーやマネージド型VPS、最新のレンタルサーバーサービスへ移行すれば、必要に応じたリソースの柔軟な増減(スケールアップ※1/スケールアウト※2)が可能となり、固定費を抑えながら安定した運用が実現できます。

コスト面・運用面の効率化を目指すのであれば、現在のサーバー環境が本当に最適なのかを定期的に見直し、必要に応じて移行を検討することが重要です。

※1 スケールアップ:サーバー1台のCPU・メモリなどハードウェアリソースを増強・増設して性能を高めること(垂直スケーリング)
※2 スケールアウト:サーバー台数を増やして処理を分散し、システム全体の性能を高めること(水平スケーリング)

コスト最適化・運用効率化を図りたい場合

移行先となるサーバーの選び方

サーバー移行の目的を決めたら、次に重要なのは適切な移行先サーバーの選定です。ここでは、サーバー選びの際に考慮すべき主なポイントを解説します。

サーバー性能と互換性を確認する

まず、新しいサーバーの性能面が自社サイトやシステムの要求を満たすかを確認します。この確認には、現在直面している課題(速度不足、容量不足など)を解消できる十分なCPU性能、メモリ容量、ストレージ容量を持つサーバーかが評価の基準になります​。

例えばアクセス数が多いECサイトであれば、高速なCPUと十分なメモリ、SSDストレージ搭載のサーバーが望ましいでしょう。同時に、現在動作しているアプリケーションやソフトウェアが新サーバー上でも問題なく動くか互換性の確認も必須です。さらに、OSの種類(WindowsかLinuxか)、ミドルウェアやプログラム言語のバージョン対応など、環境の違いによっては移行後にアプリが正常動作しない可能性もあります。

特にオンプレミスからクラウドへの移行など異なるプラットフォーム間では、事前にテスト環境で動作検証をしておくと安心です。このように、現在のサーバーで動かしているサービスが、新サーバーでも問題なく稼働できる互換性を確保しましょう。

サーバー性能と互換性を確認する

コストと機能のバランスを把握する

次に、サーバーの導入・運用コストと提供される機能のバランスを考慮します。当然ですが、高性能で高機能なサーバーほど費用も高くなるため、自社の予算内で最大限の効果が得られるプランを選ぶことが重要です。

例えば、独自ドメインのメールホスティングやSSL証明書が無料で付帯するレンタルサーバーもあれば、それらが有料オプションのサーバーもあります。また、月額費用だけでなく初期費用の有無、契約期間による割引、トラフィック超過時の追加料金なども確認しましょう。

共有レンタルサーバーであれば比較的安価(数百円〜数千円/月)で基本機能が揃いますが、カスタマイズ性は限定的です。一方、VPSや専用サーバーでは自由度が高い反面、費用は月額数千円〜数万円規模になることもあります​。

そのため、例えば「費用は抑えたいがある程度のカスタマイズが必要」という場合は、VPSがコストと性能のバランスが良い選択肢となる場合が一般的でしょう​。このように、自社にとって必要十分な機能を提供しつつ、無理のないコストで利用できるサーバーを選定することが大切です。

コストと機能のバランスを把握する

将来的な拡張性を考慮する

サーバー選びでは、現時点の要件だけでなく将来の拡張計画も見据える必要があります。事業拡大やサービス成長に伴い、アクセス数やデータ量がさらに増えることが予想されるなら、リソースを柔軟に変更できるサーバー環境が望ましいでしょう。

例えばクラウドサーバーであれば必要に応じてCPUやメモリを増強したり、追加のインスタンスを起動して負荷分散を行うことが比較的簡単です。また、レンタルサーバーでも上位プランへスムーズに変更できるか、VPSであればプラン変更時にデータ移行が不要かなど、拡張性の高さを確認します。

将来的に機能追加(例えば新たなウェブアプリケーションの導入や大容量ストレージが必要なコンテンツ配信など)の可能性がある場合、それに対応できるプラットフォームかどうかも検討材料です。

具体的には「現在の2倍のアクセスにも耐えられるか」「ディスク容量を後から増設できるか」「新しい技術スタックに対応できる環境か」といった観点で、新サーバーの将来性を評価しましょう。サーバー移行は頻繁に行うものではないため、できれば数年先を見越して余裕のある選択をしておくと安心です。

将来的な拡張性を考慮する

サーバー移行の8つのステップ

サーバーの移行先が決まったら、いよいよ具体的なサーバー移行作業に取りかかります。ここでは、サーバー移行を安全に進めるための標準的な8つのステップを順に解説します。計画段階から移行完了後のフォローまで、抜け漏れなく対応しましょう。

移行計画の策定と準備

まずは移行プロジェクトの全体計画を立てます。現行サーバーから新サーバーへの移行対象となる範囲(Webサイト、データベース、メール、アプリケーションなど)を洗い出し、移行方法と手順を文書化しましょう。

また、このタイミングで現行環境の契約状況も確認します。例えば現在利用中サーバーの契約更新日や解約期限を把握し、新旧サーバーの契約が重複する並行稼働期間を十分に確保する計画を立てます。並行稼働期間とは旧サーバーと新サーバーを同時に稼働させておく期間のことで、この期間を設けないと移行中にデータのやり取りが停止してしまう恐れがあります​

また移行作業を行う日時も重要です。可能な限りアクセスの少ない時間帯や日程を選び、必要に応じて深夜や週末に実施する計画を立てます​。移行によるサービス停止や影響範囲について、関係者へ事前アナウンスを行うタイミングも決めておきます。

さらに、万一移行に失敗した場合のリカバリ手順(旧サーバーでのサービス継続やバックアップからの復元)も計画に盛り込んでおくと安心です。準備段階では、新サーバー側に必要なソフトウェアのインストールや初期設定を済ませ、テスト環境で予行演習を行うことも検討しましょう。周到な計画と準備が、移行作業の成功率を大きく高めます。

移行に際しての準備にかかるその他の例

・OSの種類、Webサーバー、データベース、プログラミング言語のバージョン
・テスト環境を構築し、移行作業のリハーサル
・移行作業にかかる時間の見積もり

移行計画の策定と準備

データのバックアップ

先ほどの移行準備の最後で触れたように、移行作業に取り掛かる前に現行サーバー上のデータをすべてバックアップしましょう。このバックアップは、移行作業中に万一トラブルが発生した場合の「命綱」となります。

例えば、移行中に誤ってデータを消してしまったり、ファイルが破損するといった不測の事態が起きても、バックアップがあれば元に戻すことが可能です。移行中にデータ破損が起これば全体に影響が及ぶ可能性があるため、サーバー移行の前には必ずデータのバックアップを取るようにしましょう。

具体的には、Webサイトの公開ファイル一式、データベースのダンプ(エクスポート)データ、設定ファイル類、メールデータなど、サーバー上の重要データを漏れなく取得します。また、バックアップしたデータが正常に復元可能かも確認しておきましょう​。

バックアップの保存先は新サーバーとは別の安全な場所(ローカルPCや外部ストレージ、クラウドストレージなど)にします。こうすることで、仮に移行作業中に新旧両サーバーで問題が発生してもデータを失わずに済みます。上記のように万全のバックアップ体制を整えた上で、次のステップに進みましょう。

データのバックアップ

新サーバーへのデータ移行

いよいよ、新しいサーバーへデータを移す作業です。まず、新サーバーの契約とセットアップがまだであれば行います。サーバーのOSインストールや初期設定、必要なソフトウェア(Webサーバー、データベース、言語ランタイム等)のインストールを済ませ、新環境を受け入れ可能な状態にしておきます。

その後、バックアップしたデータを新サーバーへ転送しましょう。WebサイトのファイルはFTP/SFTPやrsyncコマンドなどを使ってアップロードします。データベースは事前に新サーバー上でデータベース作成とユーザー設定を行い、旧サーバーで取得したダンプファイルをインポートします。

データ量が多い場合は転送に時間がかかるため、できるだけ圧縮したり、優先度の高いデータから移すといった工夫が必要です​。例えば数百GBに及ぶファイル群を移す場合、まず重要なデータから移行を開始し、移行後すぐに必要とならないアーカイブデータなどは後回しにする、といった手順を踏むことで、サービス停止時間を短縮できます。

また、データ移行の間も旧サーバー側で更新が発生する場合(サイトに投稿が行われる、ユーザーがファイルをアップロードする等)、その差分を後から新サーバーに適用する必要があります。可能であれば移行中はコンテンツ更新を一時停止するか、差分同期の方法を検討しましょう。すべての必要なデータを新サーバーにコピーし終えたら、次はアプリケーションの設定調整に移ります。

新サーバーへのデータ移行

メールやアプリケーションの設定

データ移行が完了したら、新サーバー上で各種アプリケーションやサービスの設定を整えます。まず、企業で利用しているメールサービスを自サーバーで運用している場合、メールアカウントの設定を新サーバー側に行います。

旧サーバーで使用していたのと同じメールアドレス・パスワードのアカウントを新サーバー上に作成し、メールボックスや転送設定なども再現します。これを怠ると、DNS切り替え後にメールが受信できなくなる恐れがあるため重要な作業です

次にWebや業務アプリケーションの設定です。移行したWebサイトが正常動作するよう、新サーバーのWebサーバー(Apacheやnginxなど)の仮想ホスト設定、ドキュメントルートのパス、ファイルのパーミッションを調整します。

WordPress等CMSの場合は、設定ファイル(wp-config.phpなど)のデータベース接続情報を新サーバー用に更新します。また、外部サービスとのAPI連携や、ファイアウォールの設定(特定のIPからのアクセス許可など)があれば同様に新サーバーで設定します。

加えて、SSL証明書の再設定も忘れずに行いましょう。例えば無料で利用可能なLet's Encrypt等を利用している場合は、新サーバー上で証明書を取得し直すか、既存証明書を移行します。商用のSSL証明書であれば、新サーバーの証明書ストアにインストールして設定してください。

最後に、cronジョブ(定期実行タスク)やバッチ処理の設定も移行します。旧サーバーでスケジュール実行していたジョブがある場合、新環境で同じスケジュールになるようcrontab等を設定します。これらの設定が一通り完了したら、サービスイン直前の状態です。

メールやアプリケーションの設定

ドメインとDNS設定の変更

新サーバーへのデータ移行とメールやアプリケーションの設定が完了したら、ドメインの切り替え作業(DNS設定変更)を行います。これによってユーザーからのアクセスを旧サーバーから新サーバーへ誘導します。

具体的には、ドメイン管理サービス(レジストラやDNS提供元)の設定画面で、該当ドメインのDNSレコードを書き換えます。一般的なウェブサイトであれば、Aレコード(またはCNAMEレコード)を新サーバーのIPアドレスに変更し、メールサーバーを運用している場合はMXレコードも新サーバーを指すよう変更します。

DNSの変更はインターネット上に浸透するまでに数時間〜最大48時間程度かかることがあります。切り替えのタイミングは慎重に選びましょう。事前にTTL値(生存時間)を短く設定しておくことで比較的早く新サーバーに切り替わりますが、それでも世界中のユーザーが全員新サーバーを見るまで時間差があります。

DNS切り替え後しばらくは、古いサーバーにも一部のアクセスが届く可能性がある点に注意が必要です。したがって、DNSを変更した後も、完全に新サーバーへトラフィックが移行し旧サーバーが不要になるまで、旧サーバーはそのまま稼働させておきます。

間違ってこの時点で旧サーバーを停止・解約してしまうと、DNSキャッシュが残って旧サーバーにアクセスするユーザーにはサイトが表示されなくなってしまうので注意してください。そして、DNS変更の操作が完了したら、新旧両方のサーバーでアクセス状況を監視しつつ次の確認作業に進みます。

ドメインとDNS設定の変更

動作確認とトラブルシューティング

DNS切り替え後、新サーバーにユーザーのアクセスが向かうようになったら、サイトやアプリケーションの動作確認を行います。自分のPCから実際にドメインにアクセスし、Webページが正しく表示されるか、レイアウトの崩れや画像の表示漏れがないかをチェックしましょう。

複数のページを巡回し、リンク切れが発生していないか、フォーム送信や検索機能など動的部分もテストします。さらに、バックエンドでデータベースとの連携があるアプリであれば、データの読み書きが問題なく行えるか確認します。メールに関しても、新サーバーでメールの送受信テストを行い、外部から自分のドメイン宛にメールを送って受信できるか、こちらから送信したメールが届くかをチェックします。

もし問題が見つかった場合は、速やかにトラブルシューティングを行います。例えば、表示されないコンテンツがあればファイルのパーミッションやパス設定を確認し、アプリケーションエラーが出る場合はエラーログを調べて原因を特定します。

また、データベース接続エラーであれば、接続情報やDBサーバーの起動状況を再確認します。加えて、DNSが伝播するまでの間、一部ユーザーはまだ旧サーバーへアクセスしている可能性もあるため、旧サーバー側のログも併せて監視し、不整合が起きていないか目を配ります。

例えば、旧サーバー側で更新が走ってしまった場合、新サーバーに取り込む対応が必要かもしれません。全体として、新サーバー上で想定通りにサービスが提供できていることを慎重に検証しましょう。この段階で洗い出した不具合はすべて解決しておき、万全の状態で最終移行完了へ進みます。

動作確認とトラブルシューティング

最終確認と移行完了のアナウンス

移行作業の最終段階として、すべての機能が新サーバー上で正常に動作していることを確認できたら、移行完了の手続きを進めます。まず、新旧サーバーのアクセス状況を見比べ、ほぼ全てのユーザーが新サーバーへアクセスしていることを確かめます。具体的には旧サーバーのアクセスログやリソース使用率が著しく減少し、数日間問題なく経過したら移行は完了と判断できるでしょう。そのタイミングで、関係者およびユーザーへのアナウンスを行いましょう。

一般公開のウェブサイトであれば、事前に告知していた場合は「予定通りサーバー移行が完了しました。ご協力ありがとうございました」といった旨のお知らせをサイト上やSNSなどで発信すると良いでしょう。そして社内システムの場合は、担当者にメール等で移行完了を伝え、必要であれば新しい接続情報(サーバーのIPやホスト名変更など)を周知します。このタイミングで、ユーザーから「サイトにアクセスできない」「メールが届かない」等の問い合わせが来ていないか確認し、問題があれば個別対応します

また、移行後しばらくの間は念のため旧サーバーの契約を維持しておくと安心です​。完全に新サーバーでの運用が安定し、旧サーバーが不要と判断できるまでは、並行運用の期間として残しておく方がトラブル発生時の戻しが可能だからです。

旧サーバーの解約手続き

新サーバーへの切り替えから一定期間が経ち、問題なく運用できていることを確認できたら、旧サーバーの解約を行います。解約にあたっては、契約していたレンタルサーバーやクラウドサービスの管理画面から退会手続きを進めます。

日割り計算がないサービスでは、契約更新日の直前に解約することで無駄なコストを避けられますのでタイミングにも留意しましょう。また、解約前に旧サーバー内のデータが完全に新サーバーに移行済みであることを再度チェックします。

必要に応じて旧サーバー上のデータを完全に削除したり、サーバーを初期化してから解約することで、機密情報の漏洩を防止できます。オンプレミスなど自社サーバーの場合は、用途変更や廃棄の手続きを進めます。ハードウェアを他の用途に転用するならOSを再インストールし直す、処分するなら専門業者に依頼して物理的に破棄する、といった措置も検討してください。以上で一連のサーバー移行作業は完了です。

旧サーバーの解約手続き

サーバー移行の注意点

上記の手順を踏めば基本的に移行は可能ですが、さらに慎重に進めるために押さえておきたい注意点が複数あります。ここではサーバー移行の際によく問題になりやすいポイントや、見落としがちな点を取り上げ、対策とともに解説します。

DNS切り替えのタイミング

DNSの切り替えはサーバー移行の成否を握る重要なポイントです。切り替えタイミングを誤ると、ユーザーにとってサイトが見られない時間が発生したり、メールが届かないといった不都合が生じます。理想的には、新サーバー側の準備とテストがすべて完了してからDNSを書き換えるということを心がけましょう。それまではユーザーは引き続き旧サーバーに誘導されるため、サービス継続性が保たれます。

そしてDNS変更後は、前述のように新旧サーバー両方がしばらく稼働する並行稼働期間を設けます​。具体的には、DNSを切り替えてから最低でも数日程度は旧サーバーを停止せず残しておき、アクセスが分散してもどちらでもコンテンツを提供できるようにします​。

また、DNS切り替え日は余裕を持ったスケジュールで設定し、時間帯も夜間などアクセスの少ない時を選ぶと良いでしょう。TTL値を事前に短く設定することで伝播時間を短縮します。これらの工夫によって、DNS切り替えに伴うユーザー影響を最小限に抑えることが可能です。万が一、切り替え後に新サーバーで重大な不具合が見つかった場合に備えて、旧サーバーでサービス提供を継続できる体制を維持しておくことが、リスクヘッジになります。

DNS切り替えのタイミング

ユーザーへの事前アナウンス

サーバー移行に伴ってサービスの挙動が変わる可能性がある場合や、短時間でもサイト停止の可能性がある場合は、事前にユーザーへアナウンスしておくのが望ましいです。外部(一般ユーザー)向けのWebサービスであれば、サイト上で「○月○日深夜にサーバーメンテナンスを実施します。その間一時的にサービスをご利用いただけなくなる可能性があります」といった旨の告知を事前に出します。

これによりユーザーはあらかじめ認識でき、仮に短時間アクセスできない時間帯があっても混乱を避けられます。社内システムの場合も、利用部門にメールや掲示で周知しておき、作業時間中は利用を控えてもらうなど協力を仰ぎましょう。

特に業務時間内の移行を余儀なくされる場合は、関係者への説明と理解が不可欠です。アナウンスには、移行作業の日時、影響範囲(例:Web閲覧、データ更新、メール送受信への影響の有無)、問い合わせ先などを明記します。

そしてユーザー目線で考えると、移行完了後には追って結果報告をする旨も添えることが親切です。また、SNSやメールマガジン等でユーザーに直接通知できる場合は、それらも活用すると目に触れる媒体が増えるためおすすめです。

このように事前アナウンスを適切に行うことで、移行に伴う一時的な不便に対する理解を得やすくなり、トラブル時の問い合わせ対応もスムーズになります。結果として想定外の対応コストが嵩む可能性が低くなります。

ユーザーへの事前アナウンス

SEO観点での影響

Webサイトを運営している場合、サーバー移行がSEO(検索エンジン最適化)に与える影響も気になるところです。基本的に、同じドメイン名でサーバーのみを移行する場合、検索順位に大きな変動が起こる可能性は低いとされています。Googleなどの検索エンジンは、サイトの一時的なダウンやIPアドレスの変更には比較的寛容であり、短期間で復旧すれば評価を維持できる場合が一般的です。

参考:サイトを移転する方法,Google 検索セントラル
参考:IPアドレスが変わるサーバーの移転を行います。対策しているキーワードの順位に影響がありますか?,CyberAgent SEO LAB


ただし、移行に伴ってドメインを変更する場合は話が別です。ドメイン変更はサイトのURLがすべて変わることを意味するため、適切なリダイレクト(301リダイレクト)の設定などSEO上の配慮を行わないと、検索評価がリセットされ大きく順位を落とす可能性があります​。実際、「サーバー移行時に新規ドメインに変更するとSEOにマイナスの影響が出る可能性が高い」と指摘されています​。

参考:Should You Change Your Domain? The SEO Risks & How to Get It Right.,ASP Solutions Ltd.

したがって、可能な限りドメインはそのままでサーバーのみを移行することが望ましく、やむを得ずドメインを変える場合は全ページで旧URLから新URLへのリダイレクトを設定し、Googleサーチコンソールの「アドレス変更ツール」を使うなど慎重な対応が必要です。

参考:アドレス変更ツール,Search Console ヘルプ

また、サーバー移行直後にクローラー(検索エンジンの巡回ロボット)がサイトにアクセスした際、もしダウンしていたりエラーが続くと評価に影響する可能性もゼロではありません。移行作業はできるだけ迅速に行い、検索エンジンに正常なサイトを早期に認識してもらうようにしましょう。移行が落ち着いたら、サイトマップの再送信や、主要ページのインデックス状況チェックなども実施し、問題がないか確認することをおすすめします。

SEO観点での影響

移行後の監視

サーバー移行が完了した後も、しばらくは慎重な監視体制を維持しましょう。新しいサーバー環境で本番運用を開始した直後は、想定外の問題が表面化する可能性があるためです。具体的には、サーバーのリソース使用率(CPUやメモリ消費、ディスクI/Oなど)に異常がないか、新しい環境特有のエラーログが出ていないかを監視します

監視ツールを導入している場合は、閾値設定の見直しも必要かもしれません。例えば、クラウド環境に移行したことでスケーリングが自動化されたなら、負荷のピーク時に自動でインスタンスが増減しているかなどをログで確認します。

また、サービスのレスポンス速度が移行前と比べてどう変化したか、外形監視を行ってユーザー視点での数値を計測することも大切です。移行直後は、「ここが使いにくくなった」「特定の機能がおかしい」といったフィードバックも考えられますので適宜チェックするようにしましょう。

仮に問題が発見された場合、速やかに対処するのはもちろん、必要であれば一時的に旧環境に戻すことも検討します(クラウド移行の場合はスナップショットから旧構成を復元するなど)。移行直後の段階を安定稼働へ軟着陸させるイメージで、慎重に監視・運用を行いましょう。

移行後の監視

ケース別の移行方法(移行先サーバーの種類別)

一口にサーバー移行と言っても、移行先のサーバー環境によって具体的な方法や注意点が異なります。ここでは、移行先の種類ごとに一般的な移行方法のポイントを解説します。自社のケースに近いものを参考にしてください。

レンタルサーバーへの移行

レンタルサーバーとは、ホスティング事業者が提供するサーバー環境を月額料金で借りる形態で、特に共有レンタルサーバーの場合は1台のサーバーを複数ユーザーで共有します。レンタルサーバー間の移行方法としては、基本的に前述した手順と同じ流れで進めます。

まず新しいレンタルサーバーの契約を用意し、そこにドメインを追加(独自ドメイン利用の場合)して、旧サーバーからWebサイトのデータとデータベースを移行します

レンタルサーバーでは多くの場合、コントロールパネルが提供されており、一般的にこのコントロールパネル上でデータのバックアップ・リストアが可能です。例えば、旧サーバーで提供されているバックアップ機能でWeb公開ディレクトリとDBのエクスポートを行い、新サーバーのコントロールパネルでインポートする、といった手順です。

また、一部のレンタルサーバー事業者は他社からの移行代行サービスを提供しています​。専門知識に不安がある場合、新サーバーの提供元に移行作業を依頼できるか確認してみると良いでしょう。レンタルサーバー間の移行では、WordPressサイトなどでドメイン名やパスが変更になると設定修正が必要になる点に注意します(多くのケースではドメインはそのままでプランだけ移動するので問題ありません)。

共有サーバーでは他ユーザーへの影響を考え、大量データの転送は深夜に行う、.htaccessの扱いに互換性があるか確認する、といった細かな点にも気を配ります。全体として、レンタルサーバーは比較的手軽に扱える環境なので、提供元のマニュアルに沿って進めれば大きな問題なく移行できるケースが多いでしょう。

レンタルサーバーへの移行

オンプレミス(サーバー)への移行

オンプレミス環境への移行とは、自社が用意したサーバー(社内設置サーバーや自社契約のデータセンター内サーバー)でシステムを運用する形に移ることを指します。オンプレミスの場合、ハードウェアの調達やOSのセットアップから自社で行う必要があるため、移行手順も自由度が高い反面、自己責任の範囲が広がります

移行方法としては、まず新サーバー(物理マシン or 自社で用意した仮想環境)を立ち上げ、そこに既存サーバーと同じソフトウェア構成を再現します。例えば旧サーバーがLinux+Apache+PHP+MySQLで動いていたなら、新サーバーにも同様のバージョン(もしくは互換性のある最新バージョン)の環境を構築します。

次にデータを旧サーバーから新サーバーへコピーしますが、オンプレミスではネットワーク帯域を自由に調整できる場合も多く、大容量のデータでもLAN経由で高速に転送できる利点があります。サーバーごとラックから移動するような物理的なリロケーションの場合は、一度データを外部ストレージにバックアップしてから新環境にリストアする手順が必要になるでしょう。

さらにオンプレミス移行では、ネットワーク設定も重要です。自社内のIPアドレス体系の中で、新サーバーに適切な固定IPを割り振り、ファイアウォールの設定を行います。ドメインのDNSも自社で管理している場合は、社内DNSサーバーの書き換えなども発生します。

そして、可用性を高めるため、移行に合わせて冗長構成(クラスタリングや RAID構成の見直しなど)を組むことも検討されるでしょう。その分、移行手順は複雑になりますので、テスト環境で一連の流れをシミュレーションしてから本番移行に臨むことが重要です。

上記のようにオンプレミスへの移行は、ハードウェアの性能向上やセキュリティ要件の徹底などメリットもありますが、環境構築や運用に高度な知識が要求されます。そのため自社に専門技術者がいない場合は、移行時にシステムインテグレーターなどの支援を受けるケースもあります。

オンプレミス移行の大まかな流れ

VPSへの移行

VPS(仮想専用サーバー)への移行は、現在の環境からより自由度の高い仮想サーバー環境へ移し替えるケースです。VPSはレンタルサーバーとクラウドサーバーの中間のような存在で、1台の物理サーバーを仮想化技術で分割して専用サーバーのように使えるサービスです。

移行方法は基本的にオンプレミスサーバーへの移行に近い手順になります。すなわち、新しいVPS上にOSをセットアップし、必要なソフトウェアをインストール、設定した後、旧サーバーからデータをコピーする形です。

VPSの場合、レンタルサーバーと違いGUIのコントロールパネルでの自動移行機能などはないことが多く、コマンドラインでの作業が中心となります。例えばLinux系のVPSであれば、scpやrsyncを使って旧サーバーからファイルを一括コピーし、MySQLのデータベースはmysqldumpでエクスポート・インポートする、といった具合です。

環境構築は自由な反面、セキュリティ設定やチューニングも自分で行う必要があります。ファイアウォール設定(iptablesやクラウド提供のセキュリティグループ設定)、SSHの鍵認証設定、不要なポートの遮断などセキュリティ強化策を講じつつ移行を進めましょう。VPS移行ではroot権限での細かな作業が増えるため、確実に手順をこなせるスキルかどうか見極め、こちらも必要であれば専門家のサポートを受けることも検討してみましょう。

VPSへの移行の大まかな流れ

クラウドサーバーへの移行

クラウドサーバーへの移行は、Amazon Web Services (AWS)やMicrosoft Azure、Google Cloud Platform (GCP)などのクラウドサービス上にシステムを移すケースです。クラウドへの移行は「クラウドマイグレーション」とも呼ばれ、近年非常に増えています。

クラウド環境は従量課金制でリソースを柔軟に増減でき、高可用性機能も充実していますが、その反面設定項目が多く複雑です。移行の基本ステップ自体は、結局のところ新たな仮想マシン(クラウドインスタンス)上に環境構築しデータを転送する流れであり、VPS移行と似ています。

ただしクラウド特有のサービスを活用した移行方法も存在します。例えばAWSではAWS Application Migration Serviceという専用の移行サービスが提供されており、オンプレミスや別環境のサーバーを継続的にレプリケーションしておいて、タイミングを見計らってAWS上でカットオーバーできる仕組みがあります。これを使うとダウンタイムを最小化しながら移行できます。

AzureにもAzure Migrate、GCPにもMigrate for Compute Engineといったツールがあります。小規模なWebサイトであれば、そこまでのツールを使わずとも、従来通りファイルとDBをエクスポート/インポートする手順で十分でしょう。

クラウド移行の注意点としては、ネットワークの設定(VPCやサブネット、セキュリティグループ、ロードバランサー設定など)が複雑なこと、そして費用面での予測を立てておくことです。クラウドは使った分だけ課金されますが、設定によっては想定以上のリソースを消費してコストが膨らむケースがあります​。

そのため、移行後しばらくは請求額を細かくチェックし、不要なリソースが動きっぱなしになっていないか確認しましょう。技術面では、クラウド特有のマネージドサービス(例:AWSのRDSやS3、AzureのApp Serviceなど)を活用すると構成が変わるため、既存システムをそのまま移すのではなく、クラウド向けに再設計する「リファクタリング」を伴うこともあります。しかしこの記事では、基本となるサーバーの引っ越しという観点で説明しました。クラウド移行を行う際は、移行計画段階でこれらクラウド利用の方針も決めておくと良いでしょう。

サーバー移行時の一般的な費用

サーバー移行にかかる費用はケースバイケースで大きく異なります。自社で作業を行う場合と外部に委託する場合、あるいは移行先のサーバー種別によって、主な費用項目とその金額感が変わってきます。ここでは一般的なパターン別に、費用の考え方を紹介します

オンプレミス(サーバー)へ移行する場合の費用

オンプレミス環境へ移行する際の費用は、主にハードウェアおよびインフラ整備に関わるコストが中心になります。まず新しくサーバー機器を購入する場合、その購入費用が発生します。一般的な企業向けサーバー機(ラックマウント型など)の場合、スペックによりますが数十万円から数百万円の予算を見ておく必要があります。

加えて設置場所の用意(自社サーバールームの空きスペース確保、電源・空調設備の負荷増加への対応など)や、ラックマウントするための備品、ネットワークスイッチやケーブルといった周辺機器の費用も考慮します。

さらにOSやソフトウェアのライセンス費用も忘れてはいけません。Linux系なら無料で済む場合も多いですが、Windows Serverなど商用OSを導入するならライセンス購入費用がかかります。さらに、サーバー構築作業を自社で賄えない場合、SIer等に設計・構築を委託する費用も発生します。

その場合の作業費用は内容次第ですが、数十万円規模になることもあります。また、オンプレミスの場合ランニングコストとして保守費用や電気代なども後々かかってきますが、これは移行「後」のコストになりますので、移行プロジェクトとしては初期導入費用が中心となります。総じてオンプレミス移行は他の形態に比べ初期費用が高くつく傾向がありますが、自社資産となる分カスタマイズ性が高く、長期的には減価償却でコストコントロールしやすいメリットもあります

レンタルサーバーへ移行する場合の費用

レンタルサーバー(共有ホスティング)への移行費用は、他の選択肢と比べると比較的低く抑えられるケースが多いです。主な費用は、新たに契約するレンタルサーバーの利用料金です。多くのレンタルサーバーでは初期費用が無料〜数千円程度、月額費用も数百円から高くても数千円程度に収まります​。

参考:レンタルサーバー費用相場:レンタルサーバー料金の比較,Shopify Japan 株式会社

例えば大手レンタルサーバーの標準プランなら月額1,000円前後で、ディスク容量や転送量も中小規模サイトには十分なことが多いです。したがってサーバー代そのものの負担は小さいと言えます。移行作業を自力で行う場合も、費用としては管理者の工数(人件費)が内部コストとしてかかるのみです。

仮に外部に移行作業を委託する場合でも、一般的なWebサイト1件の移行代行であれば、相場として5万円〜10万円程度が多いようです。もちろんサイトの規模や難易度によって上下し、複数サイトをまとめて移行する場合などはさらに費用がかかります。また、稀にレンタルサーバー業者がキャンペーンで他社からの移転を無料で手伝ってくれる場合もあります​。そうしたキャンペーンを利用できれば、ほぼ新サーバー代のみで移行が完了するでしょう。

参考:WordPressサーバー移行費用の相場は?移管先のおすすめサーバーも紹介,株式会社イード
参考:《7/10まで》サーバー移転代行の無料利用回数を増加!「サーバー移転代行0円キャンペーン」,Xserver レンタルサーバー

まとめると、レンタルサーバーへの移行費用は「新サーバー契約費用 + (必要に応じて移行作業代行費用)」と考えればよく、これは比較的明確で見積もりやすいでしょう。

VPS(仮想専用サーバ)へ移行する場合の費用

VPSへの移行で発生する費用は、レンタルサーバーとクラウドの中間的なイメージです。まずVPS自体の利用料金ですが、スペックに応じて月額数千円程度からあります​。例えばメモリ4GB・CPU数コア・SSD数百GBの一般的なVPSプランなら、月額2,000〜5,000円程度が一つの目安です。

一部に初期費用がかかるサービスもありますが、最近は無料のことが多いです。したがって、新サーバーの契約費用としては年間で数万円程度を見込んでおけば足りる場合が多いでしょう。次に移行作業に関する費用ですが、VPSは自由度が高い分、もし外部委託すると作業ボリュームに応じて費用が発生します。

レンタルサーバー移行に比べ環境構築(OS設定やセキュリティ設定など)の工程が増えるため、その分の人件費/委託費が上乗せされると考えられます。概ね小規模サイト1つをVPSに移すだけなら、5万〜10万円程度の見積もりになることが多いでしょう​。

ただし、複雑なシステム(例:複数のDockerコンテナを使っている、マイクロサービス構成になっている等)を移行する場合や、運用監視の仕組みまで構築する場合は、さらに高額になることもあります。自社でエンジニアが対応できるなら、コストは新サーバー代だけで済みますが、その場合でも移行にかかる社内工数を見積もり、人的リソースを確保する必要があります。

結果的に、VPS移行の費用は「VPS利用料金(ランニングコスト) + 移行に要する人件費」という構成になります。なお、VPSへの移行時には、将来的なコストとして管理やメンテナンスに関わる負担も考慮すべきです。レンタルサーバーよりは自社で管理する部分が増えるため、運用担当者の育成や、障害発生時の対応など、目に見えないコストも発生します。それでも、独自にチューニングしてパフォーマンス向上を図れるメリットなどを考慮してVPSを選択するケースが多くあります。

クラウドサーバーへする場合の費用

クラウドサーバー(IaaS)への移行では、費用体系がやや特殊になります。クラウドサービスは初期費用が不要で、使った分だけの従量課金が基本です。そのため、新サーバー契約にあたってまとまった初期費用は生じません。

例えばAWSで一般的なEC2というサーバーを1台立てる場合でも、事前費用ゼロで開始できます。ただし、移行後のランニングコストが月々発生しますクラウドの月額費用は、サーバーのスペックや台数だけでなく、ディスク容量、データ転送量、付加サービス利用状況によっても変動します

小規模なWebサーバー1台だけを動かすのであれば、月に数千円〜1万円程度に収まるケースもありますが、企業システムとして信頼性を高めるために冗長化構成にしたり、データベースをマネージドサービスにしたりすると、たちまち数万円〜十数万円/月になることもあります​。さらにアクセス急増時には費用(データ転送料金)が跳ね上がる可能性もある点に留意が必要です​。

ここでクラウド移行の作業費用についても考えてみましょう。基本の手順はVPSと同様ですが、クラウド特有のネットワーク設計やセキュリティ設定があり、自社でノウハウが無い場合はクラウドに強いエンジニアや業者に頼る場面もあるでしょう。

その際の委託費用は、やはり数十万円規模(システムの規模によっては100万円以上)になる場合もあります。ただ、クラウドベンダー自身が提供する移行ツールを活用できれば、比較的低コストでダウンタイムも抑えて移行できることもあります。

ここまでで解説したように、クラウド移行では費用の見通しを立てにくい部分がありますので、まずは試算を行うことが重要です。各クラウドサービスの料金計算ツールを使って、現行システムを載せ替えた場合の月額費用をシミュレーションしてみましょう。

その上で、移行作業費用の見積もりも含め、オンプレや他の選択肢と総合的に比較検討することをおすすめします。場合によっては、全てをクラウドに移すのではなく、一部はオンプレや他のサービスに残すハイブリッド構成の方がコスト効率が良いこともあります。自社の要件に照らし合わせて、最適なコストバランスを追求してください。

クラウドサービスプロバイダー各社の料金計算ツール

サーバー移行時のよくある疑問

最後に、サーバー移行に関して多くの人が抱く典型的な疑問について回答します。ドメイン名の扱いから外部委託、具体的なアプリケーション移行まで、気になるポイントをQ&A形式で確認しておきましょう。

ドメインはそのままでサーバー移行できる?

はい、できます。サーバー移行時にドメインは基本的にそのまま利用可能です。多くのケースでは、「ドメイン名(例:example.com)は変えずに、そのドメインが指すサーバー先だけを旧環境から新環境へ切り替える」という形で移行します。具体的には、前述したようにDNSの設定を変更し、ドメインが新サーバーのIPアドレスを指すようにします​。

これによりユーザーから見ればURLは同じまま、中身のサーバーだけが入れ替わることになります。ドメイン名自体を移す必要はないので、移行完了後もブックマークやリンクはそのまま有効ですし、SEO的にもドメインを維持する限り評価への影響は少なくて済みます。

注意点の振り返り

・ドメインをそのまま使う場合でも旧サーバーと新サーバーの並行運用期間を設けることが重要
・ドメインとサーバーの契約先が異なる場合(例:ドメインはドメイン専門会社で取得し、サーバーはホスティング会社で借りている)の場合は、ドメイン管理元でDNSを書き換える手順となる。
・旧サーバー業者でドメインも管理している場合、新サーバー業者にドメインを移管するか、ドメイン管理は旧業者のままにしてDNS先だけ変えるかを選択する。

サーバー移行を外部委託する場合はどうする?

外部委託には大きく分けて2通りあります。ひとつは、新しく契約するサーバー提供会社が用意している移行サービスを利用する方法です。いくつかのレンタルサーバー会社では、他社からの移行を代行してくれるサービスがあります​

例えばレンタルサーバー「カラフルボックス」では、契約者向けにWordPressサイト移行代行などのサービスを提供しています​。新サーバーを申し込む際に併せて依頼できるので手軽です。そしてもうひとつは、サーバー移行専門の業者やフリーランスに外注する方法です。

自社のケースが一般的なWebサイト移行に収まらない場合(複雑なシステム構成など)、サーバー移行の実績豊富な業者に直接依頼すると良いでしょう。依頼の際は、現在のサーバー環境と移行先の環境、移行希望時期、移行にあたって重視すること(ダウンタイムを極力短くしたい等)を伝え、見積もりを取ります。費用相場は前述のようにサイト1つで5万〜10万円程度ですが、内容によって変動します​。

依頼する場合は、実績や評判を調べ、機密保持契約(NDA)を結ぶなど慎重に進めましょう。なお、一部の業者では移行後の運用代行までまとめて請け負ってくれることもあります。社内にIT担当者が少ない場合には、そうしたトータルサポートを検討するのも良いでしょう。

WordPressを別サーバーに移行する方法は?

人気CMSであるWordPressサイトの移行もよくあるケースです。WordPressを別サーバーに移行するには、「手動で移行する方法」や「専用プラグイン等を使う方法」などがあります。下記記事で詳細に解説しておりますのでご確認ください。


WordPressをAWSに無料で構築・移行するならクロジカへ

このようなお悩みがある企業様におすすめ

・WordPressをAWSやさくらのクラウドに無料で構築・移行したい
・24時間365日の監視/復旧を求めている

クロジカサーバー管理は、2004年の創業以来、法人向けにクラウドに精通したエンジニアによる高度なセキュリティを担保したクラウド運用を提供し続けています。サーバー稼働数は315台に上り、サーバー稼働率は99.989%と高水準の環境を提供しています。24時間365日の監視保守対応はもちろん、独自の自動復旧システムの構築により安定したサーバー環境を実現しています。クロジカシリーズ合計で1,800社以上の導入実績があり中小企業から大手上場企業まで幅広い支援を行っています。

監修者:クロジカサーバー管理編集部

コーポレートサイト向けクラウドサーバーの構築・運用保守を行うサービス「クロジカサーバー管理」を提供。上場企業や大学、地方自治体など、セキュリティ対策を必要とするコーポレートサイトで250社以上の実績があります。当社の運用実績を踏まえたクラウドサーバー運用のノウハウをお届けします。

コーポレートサイトクラウドでセキュアに

コーポレートサイトをクラウドでセキュアに クロジカガイドブック

無料ではじめるサーバー管理
クロジカガイドブック

「クロジカサーバー管理」の詳しい内容がわかる資料をご用意しました。
  • コーポレートサイト構築・運用の課題を解決
  • クロジカサーバー管理の主な機能
  • 導入事例
  • 導入までの流れ

詳しい資料をご覧いただけます

クロジカサーバー管理のサービス内容を記載した資料をダウンロードできます。
クロジカの機能や事例が分かる
資料ダウンロード