レンタルサーバー 乗り換え 手順 WordPress|制作会社10年と70サイト移行で見えた失敗しない移行設計

レンタルサーバーの乗り換えで本当に怖いのは、速度比較ではありません。移行当日にメールが止まる、DNS切替後に検索流入が数日ゼロになる——比較段階では誰も話題にしない運用トラブルこそが本丸です。

「乗り換え 手順」「WordPress 移行」「サーバー 引っ越し」と検索した方が知りたいのは、おそらく次の3点だと思います。いつ・どの順番で・何をすれば落とさず切り替えられるか／乗り換えるべきタイミングはいつか／やってはいけないこと。

総務省「情報通信白書」でもWebサイト保有率は上昇が続き、それに伴ってレンタルサーバーの長期運用・乗り換えニーズも増え続けています（soumu.go.jp 2026年5月閲覧）。本記事では70サイト分の移行記録から抜き出した失敗しない移行設計を、判断基準と作業順序の両面から整理します。

この記事でわかること

結論を先に書きます

サーバー乗り換えの成否は「速くなる・安くなる」では決まりません。決め手は並走期間とロールバック手段を確保できているかです。

具体的には、旧サーバーを30日並走させ、DNSのTTLを72時間前から短縮しておく。この2点さえ守れば、サーバー乗り換えは怖い作業ではなくなります。逆にここを省くと、地域ごとの混在表示やメール紛失といった事故がほぼ確実に起きます。

乗り換える前に：自社サイトの「健康診断」を3項目だけやる

乗り換えの前に、まず現サーバーの状態を3項目だけチェックします。これを飛ばすと「乗り換えても症状が変わらない」「実は遅いのはサーバーではなくサイト側だった」というケースに当たります。

PageSpeed Insights / GTmetrix で TTFB を測る

最初にやるのはTTFB（Time To First Byte）の測定です。PageSpeed Insights と GTmetrix を両方かけ、サーバーの応答速度を数値で押さえます。

判断の目安はシンプルです。TTFBが安定して600msを超えていれば、乗り換えで体感速度の改善が見込めます。一方、TTFBが200〜300msに収まっているのに遅いと感じる場合、犯人はサーバーではありません。画像最適化・キャッシュ未設定・テーマ重量のいずれかが原因のことが多いです。

ここを測らずに乗り換えると、お金と時間をかけても症状が残ります。まず数値で切り分けるのが先決です。

Search Console でSEO評価を保管する

サーバー乗り換えは、設定を誤ると検索順位を一時的に落とすリスクがあります。だからこそ乗り換え前の記録を残すことが重要です。

Search Console で現在のインデックス済みページ数と主要KWの順位を、乗り換え前に必ずスクリーンショットで保管してください。これが移行後の評価検証の基準になります。「移行前と比べてどうか」を語れる状態を作っておくのが鉄則です。

契約形態・MXレコード・DBバージョンを把握する

ここを把握せずに見積もる方が大半で、後で詰まります。確認すべきは契約形態（共用／VPS／クラウド）・メール送受信に使うMXレコード・PHP/MariaDB（MySQL）のバージョンの3点です。

コントロールパネルでこれらを確認し、移行先候補が同等以上のスペックを満たすかをチェックします。特にPHPとMySQLのバージョン差は、移行後に画面が真っ白になる代表的な原因です。

乗り換えるべきタイミング3つと、避けるべきタイミング3つ

乗り換えには「向く時期」と「事故りやすい時期」があります。アクセスとリスクの観点で整理します。

区分	タイミング	理由
乗り換えるべき	契約更新月の60〜90日前	余裕を持って並走運用できる
乗り換えるべき	アクセスが少ない時期（連休明けの平日午前帯）	切替時の影響を最小化できる
乗り換えるべき	テーマ・PHPのメジャー更新と同期する時	どうせ動作確認するなら一度に済む
避けるべき	広告キャンペーン実行中	DNS切替時の数時間ダウンが集客に直撃
避けるべき	ECのセール期間中	売上の機会損失が大きい
避けるべき	担当者が休暇に入る直前	トラブル対応窓口が空白になる

現場では、移行をキャンペーンの2週間前にずらし、旧サーバーを30日並走させる運用が安定します。並走期間の数千円を惜しんで本番直前に切ると、ほぼ確実に何かが起きるからです。並走コストは保険料と考えるのが現実的でしょう。

WordPress サーバー乗り換えの全体フロー（8ステップ）

ここからが本題です。WordPressのサーバー移行は、次の8ステップで進めます。各ステップに固有の落とし穴があるため、順番を飛ばさないのが安全です。

ステップ	作業内容	所要時間	落とし穴
1	移行先サーバー契約・WordPress新規構築	1〜2時間	ドメイン関連付けはまだしない
2	旧サーバーで完全バックアップ（DB＋ファイル）取得	30分〜2時間	プラグイン依存のバックアップは復元失敗が多い
3	移行先へデータ復元（hostsファイル切替で確認）	30分〜1時間	hosts編集を忘れて旧サーバー表示を見続ける事故が定番
4	プラグイン・テーマ・パーマリンク・SSLの動作確認	1〜2時間	この段階でリンク切れと混在コンテンツを潰す
5	メール（MX）の移行 or 残置の方針確定	30分〜1時間	DNS切替と同時にメールが届かなくなる事故が最多
6	DNS切替（Aレコード／ネームサーバー）	5分（反映に数時間〜72時間）	TTLを事前に短くしないと反映が遅い
7	DNS反映後の最終動作確認（複数キャリア／複数地域）	30分〜1時間	スマホ4G・自宅Wi-Fi・社内LANの3経路で確認
8	旧サーバーを30日並走 → 解約	30日	「もう動いてるはず」と早期解約してメール紛失

出典: 70サイトの移行案件記録（2018〜2025）／IPA「DX白書」の中小企業IT資産入替記述（ipa.go.jp 2026年5月閲覧）を参照しつつ整理。

このフローで乗り換え経験ゼロの方が一番ハマるのが、ステップ3の「hostsファイル切替で確認」です。

DNSを切り替える前に、自分のPCだけ強制的に新サーバーを参照させます。hostsファイル（Windows: C:\Windows\System32\drivers\etc\hosts／Mac: /etc/hosts）に1行追加し、本切替の前に新サーバー側でサイトが完全動作するかを確認するわけです。この一手間が、当日の「全ページが真っ白」を防ぎます。

移行先サーバーの選び方：5つの判断軸

「速い」「安い」だけで選ぶと現場で詰まります。70サイトで一貫して使ってきた5つの判断軸を開示します。

WordPress高速化エンジンの実装方式

高速化方式は大きく2系統あります。LiteSpeed（LSCache）か、独自高速化エンジン（KUSANAGI／nginx + FastCGI Cache）かです。

選び方は用途で分かれます。書き込み頻度の高いサイト（EC・会員制）はLiteSpeedが安定する傾向、読み取り中心の情報サイトは独自エンジン＋CDNの組み合わせが伸びる傾向です。

自動バックアップの保持期間

7日保持と14日保持では、トラブル時の復旧難易度がまったく違います。最低14日、できれば30日保持できるサーバーを選んでください。バックアップは「あるか」より「いつまで遡れるか」が効きます。

無料独自SSLの発行と自動更新

無料独自SSL（Let’s Encrypt）の発行が数クリックで完結するか、自動更新の障害時にアラート通知があるかを確認します。SSL失効はサイト全体のアクセス停止に直結するため、ここは妥協できません。

管理画面の応答速度と操作性

意外と見落とされますが、運用フェーズで一番触る場所です。クライアントへ自走運用を引き渡す案件では、管理画面の操作性でConoHa系・SWELL推奨環境を選ぶことが多くなります。日々の更新ストレスは、この一点で大きく変わります。

サポート窓口の質と応答時間

24時間チャット対応か、メールのみで翌営業日返信か。深夜にサーバー障害が起きた経験がある方は、24時間チャットの有無を最重視してください。障害は営業時間を選んでくれません。

サーバー単体の速度はこちらでも検証しています。あわせて主要レンタルサーバーの速度比較と、用途別の総合評価をまとめたレンタルサーバー比較ランキングもご確認ください。

ダウンタイムを最小化するDNS切替の実務

DNS切替は移行作業の最大の山場です。ここでミスると、サイトが数時間〜数日「圏外」になります。落とさないための3点を押さえます。

TTLを72時間前から短縮しておく

DNSレコードのTTL（Time To Live）を、切替の72時間以上前に3600秒→300秒（5分）へ短縮しておきます。

これだけで切替後の反映が一気に速くなります。逆にTTLを短縮せず本切替すると、新旧サーバーが地域ごとに混在表示され、反映が72時間遅れます。最初にやる一手と覚えてください。

メール（MX）とWeb（Aレコード）を分けて考える

「サーバー乗り換え＝MXも自動で切り替わる」という誤解が、メール事故の最大要因です。MXを旧サーバーに残置するか、新サーバーへ移すかを事前に決めて文書化してください。

現場で多用するのは「旧サーバー解約までの30日間はMXを旧側に残し、WebのAレコードだけ新側に切る」という移行パターンです。これでメールを止めずにWebだけ先行移行できます。

切替直後にやる「3経路チェック」

切替後30分以内に、スマホ4G・自宅Wi-Fi・公衆Wi-Fi（または社内LAN）の3経路で、サイト表示・フォーム送信・カート遷移を確認します。

経路によってDNSの反映タイミングが違うため、1経路だけだと「自分のPCでは表示されているのに、ユーザーには見えていない」状況を見落とします。1経路チェックは確認したつもりの落とし穴です。

乗り換え後にやる「30日チェックリスト」

切り替えて終わりではありません。乗り換え後の30日間の監視で、初めて移行は完了します。

経過日数	確認項目	想定アクション
1日目	全ページ表示／フォーム送信／決済テスト／メール送受信	エラーが出たら旧サーバーへ即時切り戻せる状態を維持
3日目	Search Consoleのクロール状況／インデックス減少有無	クロールエラーのURLを一括チェック
7日目	主要KWの検索順位／流入数	移行前比較で大きく落ちていないか
14日目	GA4の直帰率・滞在時間／速度メトリクス	LCP・INP・CLSのCore Web Vitals改善を確認
21日目	バックアップが新サーバーで正常取得されているか	復元テストを1サイトで試す
30日目	旧サーバー解約手続き／メールの最終移行確認	解約前の「再ダウンロード」「最終バックアップ」を必ず取る

出典: 筆者作成（70サイト移行記録のうち、トラブル発生案件を逆算した監視項目リスト）／IPA「中小企業の情報セキュリティ対策ガイドライン」の継続監視記述を参照（ipa.go.jp 2026年5月閲覧）。

特に7日目の順位チェックは要です。ここで大きな落ち込みがなければ、移行は概ね成功と判断できます。30日目の解約直前には、最終バックアップと再ダウンロードを忘れないでください。

乗り換え時に「絶対にやってはいけない」5つの行動

最後に、現場で事故を生んできたやってはいけない5つを挙げます。どれも一度やると取り返しがつきにくいものです。

なかでも3つ目のTTL短縮忘れは被害が大きい項目です。これを怠ると、切替後72時間にわたって新旧サーバーが地域ごとに混在表示され、注文の一部が古いDBに書き込まれる事故につながります。チェックリストの起点は、いつもこのTTL短縮です。

当サイトの推奨スタック：SWELL × エックスサーバー or ConoHa WING

現場で個人クライアントに引き渡す際の標準スタックは、WordPressテーマ「SWELL」＋ レンタルサーバーはConoHa WING / エックスサーバーのどちらかです。

• SWELL：国内最高峰クラスの高速化とGutenberg対応。ブロックエディタの操作性で「自走運用への移行」がスムーズ。
• ConoHa WING / エックスサーバー：共用サーバーながらWordPress専用高速化・自動バックアップ・無料SSLが標準実装。乗り換え時のサポート品質も安定。

この組み合わせなら、乗り換え後の運用負荷が下がるのが最大のメリットです。引き渡し後にクライアント自身が更新できる状態まで、無理なく持っていけます。

姉妹サイトWebサイト制作ノート（awcs.org）では、サーバー選びとセットで考えるテーマ選び・コーポレートサイト構築の全体設計を整理しています。サーバー単体ではなく、サイト全体の設計から検討したい方はあわせてご覧ください。

よくある質問

レンタルサーバー乗り換えで、現場でよく受ける質問を整理します。

まとめ：乗り換えは「並走とロールバック」で決まる

本記事の核心を最後に整理します。

本記事は、総務省「情報通信白書」・IPA「DX白書」「中小企業の情報セキュリティ対策ガイドライン」・W3C / WAICのWeb標準仕様といった公開情報と、70サイトの移行記録を突き合わせて整理しました。

乗り換え判断の核心は「速くなる・安くなる」よりも、並走期間とロールバック手段を確保できているかです。並走30日とTTL短縮72時間の2点さえ守れば、サーバー乗り換えは怖い作業ではなくなります。

---

免責事項

---