サーバー移行（マイグレーション）のやり方完全ガイド：データ損失なしでサイトを安全に移転する方法

サーバー移行（マイグレーション）とは、ウェブサイトのファイル、データベース、メールアカウント、DNSレコード、アプリ設定などを現行サーバーから新しいサーバーへ計画的に移転する作業です。データ損失なしでサイトを移転するには、まず完全バックアップを取得し、新サーバーを同等または最新のソフトウェア環境で準備、ファイルとDBを転送、hostsファイルや仮URLで動作確認、DNS切り替え時はTTLを短く設定、移行後はログ・フォーム・決済フロー・メール配信・SEOシグナルをチェックするのが基本です。

サーバー移行は単なる「コピー＆ペースト」作業ではありません。WordPressやWooCommerce、Laravel、独自PHPアプリ、高トラフィックのニュースサイトや企業メール利用のビジネスなどでは、移行ミスによって注文損失、文字化け、500エラー、SSL警告、メール障害、検索順位低下など重大なトラブルにつながります。だからこそ、移行計画・技術チェックリスト・ロールバック（復旧）シナリオを用意し、慎重に進める必要があります。

本ガイドでは、2026年のSEOやパフォーマンス要件に応じたホスティング/サーバー移転の手順を詳しく解説します。cPanel、Plesk、VPS、クラウドサーバー、マニュアル移行など様々なケースを取り上げ、DNS設定、バックアップ範囲、DB互換性、SSL導入、移行後のSEOチェックまで実用的なノウハウを紹介します。

サーバー移行が必要になるタイミング

サイトを新しいサーバーへ移転する主な理由は、パフォーマンス・セキュリティ・コスト・スケーラビリティの改善です。例えば月間5,000アクセスの企業サイトなら共用ホスティングで問題なく動きますが、日間20,000アクセスのECサイトではCPU制限・遅いDBクエリ・決済画面のタイムアウト等が頻発します。この場合、より強力なホスティングプランやVPS、クラウド基盤への移行が求められます。

移行の必要性を示す一般的なサインは以下の通りです：

• ページ表示速度が3秒を超え、Core Web Vitals指標が悪化している
• ホスティング管理パネルでCPU・RAM・inode・ディスク上限が頻繁に達する
• PHP/MySQL/MariaDB/Node.js/ionCubeなどの最新バージョンが必要
• SSL更新・メール配信・DNS管理で繰り返し問題が発生する
• 既存プロバイダーのサポート品質・バックアップ・セキュリティが不十分
• キャンペーンや季節イベント等で突然トラフィックが増加する

サイトが成長し、現在のプランの限界が近づいているなら、急なトラブル時の移行よりも、事前に計画的なマイグレーションを行う方が遥かに安全です。用途に合わせて ウェブホスティングパッケージ、VPSサーバーソリューション、法人ホスティング を比較し、最適なインフラを選びましょう。

移行準備：最も重要なステップ

データ損失が起こる移行の多くは、移行作業中ではなく、準備不足が原因です。移行前に現サイトの構成を把握し、どのデータを移転するか・どのサービスが中断に弱いか明確にしておく必要があります。

1. サイトの構成を洗い出す

最初のステップは、サイトの技術マップ作成です。CMSやフレームワーク、PHPバージョン、DB種別、ディスク容量、メールアカウント、cronジョブ、DNSレコード、SSL証明書、リダイレクト設定、外部連携などをリストアップします。WordPressの場合、wp-contentだけでなく、.htaccessルール・wp-config.php・DBテーブルプレフィックス・キャッシュプラグイン・メディアファイルも要チェックです。

ECサイトでは決済基盤・配送連携・在庫同期・ERP接続・SMTPサービス・Webhook URL等も詳細に調査が必要。移行後に注文が届かない場合、大抵はファイル転送ミスではなく、APIのIP制限や旧サーバーのセキュリティ設定忘れが原因です。

2. 完全バックアップを取得し検証する

サーバー移行でバックアップ取得は必須ですが、バックアップが実際に復元できるかの検証も重要です。完全バックアップには下記の要素を含めます：

• ウェブサイトファイル：public_html、アプリケーションフォルダ、アップロードディレクトリ、テーマ・プラグイン
• データベース：MySQL、MariaDB、PostgreSQLなど必要なもの全て
• メールデータ：メールボックス、転送設定、フィルター、自動返信設定
• DNSレコード：A, AAAA, CNAME, MX, TXT, SPF, DKIM, DMARC等
• 設定ファイル：.htaccess, nginx.conf, php.ini, cron job, environmentファイル
• SSL証明書・専用セキュリティルール

実務上、移行前に最低2つのバックアップを取得（サーバー内と外部保存）するのが安全です。大規模サイトならrsyncでファイルバックアップ、mysqldumpやパネルツールでDB取得が推奨されます。10GB超のDBは分割・圧縮してバックアップすることで復元リスクを減らせます。

3. DNS TTL値を事前に短く設定

DNS切り替えの伝播を早くするには、移行前にTTL値を短くするのが定番です。例えばTTLが14400秒なら、ユーザーによっては長時間旧サーバーへアクセスし続けます。移行前にTTLを300秒に下げれば、DNS変更後の切り替えがスムーズ。移行完了後、TTLは3600〜14400秒に戻せます。

ドメインのDNS管理は移行成功に直結します。ドメイン管理・DNS設定で困ったら ドメイン検索とドメイン管理 を参考にしましょう。

主要なサーバー移行方法の比較

サイトによって最適な移行方法は異なります。小規模企業サイトならパネル移行で十分ですが、大規模ECサイトやメディアサイトでは段階的な同期やメンテナンスモードが必要となる場合があります。

新インフラ選びでディスク容量だけに目を向けると失敗しがちです。PHPワーカー数・CPUコア・RAM・NVMeディスク・バックアップ頻度・データセンター立地・LiteSpeed/Nginx対応・WAF・DDoS対策などもパフォーマンス決定要素。安さだけで選び直後に再移行を余儀なくされるケースも多いので、事前にニーズ分析をしっかり行いましょう。

サーバー移行のステップバイステップ

ステップ1：新サーバーの準備

新サーバーにOS・Webサーバー・PHPバージョン・DBサービス・必要モジュールをセットアップします。WordPressならPHP 8.2/8.3・最新MariaDB・OPcache・適切なmemory_limitが理想。LaravelではComposer・cron・queue worker・storage権限も重要。旧サーバーのPHP拡張が新側にないと、移行後に白画面や500エラーが出ることも。

セキュリティ面ではSSHポート設定・強力なパスワード・ファイアウォール・マルウェアスキャン・自動アップデートを事前に構築。移行前に新サーバーでセキュリティ基盤を整えると、後で対応するより楽です。SSL証明書導入が必要なら SSL証明書の設置 を移行計画に必ず含めてください。

ステップ2：ファイル転送

サイト規模に応じてFTP/SFTP/SSH/rsync/パネルバックアップなどを使います。小規模サイトはアーカイブ圧縮→新サーバーで展開で十分ですが、大規模ならrsyncで初回コピー→DNS切り替え直前に再同期が推奨されます。アップロードディレクトリが頻繁に更新されるサイトは特に時間短縮になります。

転送後はファイル権限をチェック。一般的にはフォルダは755、ファイルは644ですが、アプリごとに要件が異なります。wp-config.phpや.envなど機密ファイルは全員が読めないように。さらに、.htaccessや.user.iniなど隠しファイルも必ずコピーされているか確認しましょう。

ステップ3：データベース移行

DB移行はデータ損失防止の最重要部分。先に旧サーバーでdumpを取得し、新側でDBとユーザーを作成します。文字コードはutf8mb4が推奨。日本語などの文字化けを防ぐため、export/import時のcollationを揃えることが必須です。

WooCommerceや会員制サイトのようにリアルタイムでDB更新が発生する場合、移行中はメンテナンスモードを利用。DNS伝播中に一部ユーザーが旧・新サーバーにアクセスし、データ不整合が起こるのを防ぎます。重要サイトでは最終DBdumpはメンテモード後に取得しましょう。

ステップ4：設定ファイルの更新

DB名・ユーザー名・パスワード・ホスト・ファイルパス等を新サーバー環境に合わせて編集します。WordPressならwp-config.php、Laravelなら.env、独自アプリならconfig.php等を確認。絶対パスやIPアドレス、SMTP設定、キャッシュディレクトリが旧サーバーのままだと表面上は動いても裏でエラーが起こります。

またPHPのmemory_limit、upload_max_filesize、post_max_size、max_execution_timeはサイト用途に応じて調整。例えば管理画面で200MB画像をアップロードする場合、upload_limitが32MBだと移行成功しても運用できません。

ステップ5：DNS切り替え前に動作チェック

最も安全な移行方法は、DNS切替前に新サーバー側でサイト動作確認を行うことです。PCのhostsファイルにドメインと新IPを記載すれば、一般ユーザーは旧サーバーを閲覧しつつ、自分は本番ドメインで新サーバーの動作を確認できます。

テスト項目には下記が含まれます：

• トップ・カテゴリ・商品・ブログ・問い合わせページが表示されるか
• フォーム送信・会員ログイン・パスワードリセット・決済フローは正常か
• 画像・CSS・JSファイルが欠落なく読み込まれるか
• 管理画面はエラーなしで利用できるか
• SSL証明書が正しいドメインで導入されているか
• 404/500/mixed content/リダイレクトループ等のエラーはないか
• robots.txt・sitemap.xml・canonicalタグが正しく設定されているか

ステップ6：SSL証明書の導入

現代のウェブサイトではSSLはセキュリティだけでなくSEOやユーザー信頼の必須条件です。新サーバーでSSL導入前にDNS切り替えると「安全でない」警告が出ることも。DNS切替直前または同時にSSL証明書を発行・セットアップしましょう。Let’s Encryptなど無料SSLも多くのサイトで十分ですが、決済を扱う企業サイトでは高い認証レベルのSSLが推奨されます。

SSL導入後は、HTTP→HTTPSへの301リダイレクト、mixed contentエラーなし、サイトマップにHTTPS URLが含まれているか必ず確認。SSL商品や導入方法については SSL証明書 をご参照ください。

ステップ7：DNSレコードの切替

テスト完了後、DNSのAレコードを新IPへ変更します。メールも同サーバーで移転する場合はMX/SPF/DKIM/DMARCも更新。メールが外部サービスの場合はMXレコードを変更しないこと。よくあるミスは、ウェブだけ移転したいのにメールレコードも変えてしまい、メール送受信が停止することです。

DNS伝播は数分〜24時間ほど。TTLを事前に短くしていれば、ほとんどのユーザーはすぐ新サーバーへアクセスします。この間、旧サーバーは即停止せず、最低48時間（できれば72時間）は稼働させておきましょう。

ステップ8：最終同期とログチェック

DNS切替後、旧サーバー側で新規データが書き込まれていないか確認。特に注文・問い合わせ・会員登録・コメントなどを比較。Webサーバーのaccess/errorログで、どのIPがどちらのサーバーへアクセスしているか把握できます。

移行直後24時間は500エラー・404急増・遅いDBクエリ・CPU急騰・メールキューの滞留などを監視。これらを怠ると、表面上は正常でも裏でコンバージョン損失が起こる場合があります。

データ損失なしで移行するためのプロ用チェックリスト

以下のチェックリストは、実際にトラブルが起こりやすいポイントを網羅しています。移行前後にこのリストを確認することで、マイグレーションリスクを大幅に抑えられます。

• 移行作業はアクセスの少ない時間帯に計画された
• 完全なファイル・DB・メール・DNSバックアップを取得した
• バックアップが復元可能かテスト済み
• DNS TTL値を24時間以上前に短く設定した
• 新サーバーにPHP・DB・必要モジュールを準備した
• ファイルを全て転送し、権限を確認した
• DB文字コード・collationの互換性を検証した
• 設定ファイルを新サーバー情報に更新した
• hostsファイルで切替前に動作テスト済み
• SSL導入・HTTPSリダイレクトを確認した
• DNSのA/AAAA/MX/TXTレコードを正しく更新した
• 旧サーバーを最低48時間稼働させた
• Google Search Console・Analytics・ログを監視した

SEO損失を防ぐ移行後チェック

サーバー移行はURL構造が変わらない限り、理屈上SEO順位に影響しません。しかし実際には、速度低下・404エラー・誤robots.txt・SSL未導入・リダイレクトミスが順位に響くため、移行後のSEOチェックは技術移行と同じくらい重要です。

URLとリダイレクト確認

移行時にURL構造が変わらなければ301リダイレクトは最低限でOKですが、同時にドメイン・パーマリンク・ディレクトリ構造を変更する場合は、旧URLから新URLへ必ず301リダイレクトを設定。302（仮リダイレクト）はSEOシグナルの継承には不適。例えば /product/abc → /shop/abc への移転なら、個別リダイレクトを実施。全ての旧URLをトップページにリダイレクトすると、ユーザー体験とSEO双方で悪影響です。

robots.txt・サイトマップ確認

テスト環境で検索エンジンブロック目的のDisallowをrobots.txtに記載した場合、本番切替時に必ず解除。これが移行後のインデックス消失の典型的な原因。サイトマップには新しいHTTPS URLを含め、Google Search Consoleで再送信しましょう。

パフォーマンスとCore Web Vitals

新サーバーが高性能でも、キャッシュ設定ミスで速度が低下する場合があります。LiteSpeed Cache・Redis・OPcache・CDN・画像最適化を正しく構築。移行後1週間はPageSpeed Insights・Chrome UX Report・サーバーログでLCP/INP/CLS指標の悪化がないか追跡。ホスティングのパフォーマンス改善には WordPress速度最適化 も活用してください。

メール移行時の注意点

多くのサイト移行でウェブファイルは無事転送できても、メール移行が抜け落ちがち。メールが現サーバーに保存されている場合は、メールボックス・ユーザーパスワード・転送・フィルターも移行対象。IMAP同期は旧ボックスのメールを新側へ移す信頼できる方法です。

DNSではMXがメールサーバー、SPFが送信権限、DKIMが署名、DMARCがドメインポリシーを決定。これらが誤設定だと、メールは迷惑フォルダ行きや完全拒否されることも。移行後はGmail・Outlook・企業メールへテスト送信し、メールヘッダーも確認しましょう。

よくあるサーバー移行ミス

成功する移行プロジェクトの共通点は、単純なミスを事前に防げていることです。下記は頻出のトラブル例：

• バックアップなし・検証なしの移行
• DNS TTL短縮せずにIP切替
• DNS伝播完了前に旧サーバー停止
• DB文字コードミスで日本語文字化け
• .htaccess/nginxのリダイレクト設定漏れ
• SSL未導入でHTTPSトラフィックを新サーバーへ誘導
• メールのMX/TXTレコードを誤更新
• 旧サーバー経由のキャッシュプラグイン放置
• 移行後のSearch Console/ログ監視を怠る

特にリアルタイム販売サイトでは、移行作業は平日ピーク時ではなく、アクセス・注文数が最も少ない時間帯に行うこと。大規模ECなら15〜30分のメンテナンスウィンドウを設けることで、裏側のデータ不整合も予防できます。

プロによる移行サポートが必要なケース

簡単な紹介サイトなら手作業移行も可能ですが、プロに依頼した方がコスパ・安全性が高いケースもあります。月商が大きいECサイト・大量メールアカウント保有企業・独自ソフト利用ポータル・高トラフィックメディア・規制データを扱うビジネスは該当します。

プロ移行サポートは事前分析→バックアップ→テスト環境構築→転送→DNS切替→検証→監視の流れ。単なるファイル移転だけでなく、ビジネス継続性も守ります。Hostragonsへ移行を検討する際は、ホスティング・ドメイン・SSLをセットで見直し、最適な移行プランを Hostragons ホスティングソリューション でご確認ください。

まとめ：計画的なサーバー移行がダウンタイム・データ損失を防ぐ

サーバー移行は、しっかり計画されていれば恐れる必要はありません。成功の鍵は、完全バックアップ・正しいサーバー準備・DNS TTL計画・テスト環境・SSL導入・メールチェック・移行後監視を漏らさないこと。DBが頻繁に更新されるサイトでは最終同期・メンテナンスモードが特に重要です。

要するに、データ損失なしでサイトを移転するには急がず、全ステップを検証し、旧サーバーをすぐ停止しないこと。インフラ刷新で安全・高速なサイト運営を目指すなら、Hostragonsのホスティング・ドメイン・SSLを比較し、落ち着いて最適な移行計画を立てましょう。

よくある質問

サーバー移行はどれくらい時間がかかりますか？

サイト規模・構成によって異なります。小規模WordPressなら30〜60分で移行可能ですが、大規模ECやメールアカウント多数の企業サイトでは準備・テスト・DNS伝播含め1〜3日かかることも。

移行中、サイトが停止しますか？

計画通り進めればダウンタイムは数分程度、またはユーザーが停止を感じないケースもあります。DNS TTLを事前に短縮・新サーバー事前テスト・DNS伝播完了まで旧サーバー稼働がポイントです。

データ損失を防ぐ最重要ステップは？

最も大切なのは検証済みの完全バックアップ。ファイル・DB・メール・DNSの全データを保存し、特に注文・会員データがあるサイトはメンテモード後の最終DBバックアップを取得しましょう。

サーバー移行でSEO順位は落ちますか？

URL構造維持・サイト高速化・SSL導入・リダイレクト適正なら移行自体でSEO順位が下がることはありません。ただし404エラー・誤robots.txt・遅いサーバー・不適切な301リダイレクトは悪影響となり得ます。

メールアカウントも移行できますか？

メールが旧ホスティング管理なら別途移行が必要です。メールボックス・転送・フィルター・MX/SPF/DKIM/DMARCレコードを確認。メールが外部サービスならMXレコードは変更不要です。