サーバー移転を自社で判断してはいけない理由

「サーバーを乗り換えれば費用が下がる」と安易に判断した結果、メール・SSL・APIが止まった事例は少なくありません。移転前に確認すべき技術的チェックポイントを実案件ベースで解説します。

こんな状況、思い当たりませんか？

「今のサーバー、高くない？乗り換えたら月額半分になるらしいよ」——経営層からそう言われて、Web担当者が慌てて移転作業を進めてしまう。よくある話です。

あるいは逆に、担当者が自分で調べて「このVPSプランの方がスペック高いのに安い」と判断し、上長の承認だけもらってサクッと移転。翌朝出社したら、お問い合わせフォームのメールが一通も届いていない——そんな事態が現場では頻繁に起きています。

サーバー移転は「引越し」に例えられますが、実態は単純な荷物の運搬ではありません。メール送受信の設定、SSL証明書の再発行、外部サービスとのAPI連携、DNSの伝播タイミング……見落としが一点あるだけで、ビジネスに直結する機能が数時間〜数日単位で止まります。

この記事では、Fivenine Designが実際に対応してきた案件を交えながら、自社だけで移転判断・実施をしてはいけない理由と、移転前に必ず確認すべきチェックポイントを技術的な根拠とともに解説します。

なぜ「安易な移転」が深刻な障害を引き起こすのか

サーバー移転で問題が起きるのは、担当者のスキルが低いからではありません。移転に関わる設定の依存関係が複雑すぎるからです。

現代のWebサービスは、以下のような複数のレイヤーが密接に絡み合っています。

flowchart TD
    A[ドメイン / DNS設定] --> B[Webサーバー]
    A --> C[メールサーバー]
    B --> D[SSL証明書]
    B --> E[Webアプリケーション]
    E --> F[データベース]
    E --> G[外部API連携]
    C --> H[SPF / DKIM / DMARC]
    G --> I[決済 / CRM / 分析ツール]

たとえば、IPアドレスが変わるだけで次のすべてに影響が出ます。

SSL証明書：Let's Encryptの自動更新がIPベースのチェックに失敗するケース
メール送信：SPFレコードが旧サーバーのIPを指したまま残り、Gmailにスパム判定される
外部API：IPホワイトリストで制限している決済サービスや在庫管理システムが接続を拒否する
セッション・Cookie：ドメインが変わると既存ログインが強制ログアウトになる

これらは「移転後に直せばいい」という性質のものではなく、移転と同時に設定が完了していないと即座にサービス停止につながります。

サーバー・インフラでお困りですか？

障害対応・移行・パフォーマンスチューニングなど、ご相談ください

無料で相談する

実案件から学ぶ「止まり方」のパターン

ケース1：メールが届かなくなった製造業クライアント

神奈川県内の製造業のお客様で、コスト削減目的でレンタルサーバーを乗り換えた案件です。移転自体は問題なく完了しましたが、3日後から問い合わせメールがすべて消えていたことが発覚しました。

原因はSPFレコードの未更新。旧サーバーのIPが記載されたまま新サーバーからメールを送信したため、受信側（Gmailやoutlook.com）がなりすましと判断してすべてを破棄していました。

SPFレコードとは、DNSに登録する「このドメインから送るメールは、このIPアドレスが正規の送信元です」という宣言です。

# 修正前（旧サーバーのIPが残っている）
v=spf1 ip4:203.0.113.10 include:_spf.sakura.ne.jp ~all

# 修正後（新サーバーのIPに更新）
v=spf1 ip4:198.51.100.25 include:_spf.xserver.jp ~all

加えて、DKIMの署名キーも新サーバーで再生成・DNS登録が必要でした。この2点が揃って初めてメールが正常に届くようになります。

ケース2：決済が止まったECサイト

WordPress + WooCommerceで運営しているアパレル系ECサイトの移転案件です。移転完了後、決済処理だけが「接続エラー」になるという症状が出ました。

原因は決済代行会社（某大手）のIPホワイトリスト制限。旧サーバーのIPアドレスは登録済みでしたが、新サーバーのIPは未登録のため、コールバックURLへのアクセスがすべてブロックされていました。

決済代行サービスの管理画面でIPを追加するだけで解決しましたが、この確認を事前にしていれば移転当日のEC停止は防げました。

移転前に確認すべき外部サービスのリストを必ず作成することが重要です。

# 現在のサーバーIPを確認するコマンド
curl -s ifconfig.me

# または
dig +short myip.opendns.com @resolver1.opendns.com

移転前に確認すべき技術チェックリスト

DNS・ドメイン設定の棚卸し

まず現在のDNS設定を完全に記録します。移転後に参照できるよう、以下のコマンドですべてのレコードをエクスポートしておくことをおすすめします。

# Aレコード確認
dig example.com A

# MXレコード確認
dig example.com MX

# TXTレコード確認（SPF・DKIMはここに入っている）
dig example.com TXT

# すべてのレコードを一覧表示
dig example.com ANY

# Aレコード確認
Resolve-DnsName -Name example.com -Type A

# MXレコード確認
Resolve-DnsName -Name example.com -Type MX

# TXTレコード確認
Resolve-DnsName -Name example.com -Type TXT

SSL証明書の移行計画

SSL証明書には大きく分けて2種類の対応が必要です。

証明書の種類	移転時の対応	難易度	注意点
Let's Encrypt（無料）	新サーバーで再発行	低	DNSが向いてからでないと発行できない
有料SSL（認証局発行）	CSR再生成 → 再申請	高	発行まで数日かかる場合あり
共有SSL（レンタルサーバー附属）	プラン解約で失効	中	独自ドメインSSLへの切り替えが必要

Let's Encryptの場合、新サーバーにDNSが向いていない状態では証明書が発行できません。つまり「DNSを向けてからSSLを発行する」という手順が必須ですが、DNSが完全に切り替わるまで最大48時間（TTL次第）かかります。この間は旧サーバーを維持し続ける必要があります。

環境変数・設定ファイルの移行

LaravelやWordPressを使っている場合、設定値が環境変数やファイルに分散しています。以下は移転時に必ず更新が必要な設定の例です。

# Laravel .env の主要設定（移転時に変更が必要になる項目）
APP_URL=https://example.com          # ドメイン変更時に更新
DB_HOST=127.0.0.1                    # 新DBサーバーのホストに変更
DB_DATABASE=new_db_name              # 新サーバーのDB名に変更
DB_USERNAME=new_db_user
DB_PASSWORD=new_db_password

MAIL_HOST=smtp.new-server.com        # メールサーバーの変更
MAIL_PORT=587
[email protected]

AWS_BUCKET=your-bucket-name          # S3使用時は変更不要だが確認必須
REDIS_HOST=127.0.0.1                 # Redisを使っている場合

WordPressの場合は wp-config.php に加え、データベース内の siteurl と home オプションも更新が必要です。

-- WordPress: URLが変わる場合はDB内も更新
UPDATE wp_options SET option_value = 'https://new-example.com' WHERE option_name = 'siteurl';
UPDATE wp_options SET option_value = 'https://new-example.com' WHERE option_name = 'home';

-- コンテンツ内のURLも一括置換（WP-CLIを使う場合）
-- wp search-replace 'https://old-example.com' 'https://new-example.com' --all-tables

よくある失敗パターンと回避策

失敗1：TTLを下げずにDNSを切り替えた

DNSのTTL（Time To Live）は、DNSの情報がキャッシュされる時間です。デフォルトは3600秒（1時間）〜86400秒（24時間）に設定されていることが多く、切り替え後も旧IPに向き続けるユーザーが出ます。移転の1週間前にTTLを300秒（5分）に下げておくのが鉄則です。

失敗2：移転後すぐに旧サーバーを解約した

DNS伝播が完了するまでの数時間〜48時間は、旧サーバーにアクセスするユーザーが混在します。旧サーバーを即解約すると、その間のアクセスが完全に失われます。最低でも1週間は旧サーバーを維持することを契約条件として計画に組み込んでください。

失敗3：ステージング環境でしかテストしなかった

本番ドメインのDNSが切り替わった直後は、証明書エラー・リダイレクトループ・セッション不整合などが同時多発することがあります。/etc/hosts を使ったローカルでの事前確認を必ず行ってください。

# /etc/hosts に追記して新サーバーに向けてローカルからテスト
# （DNS切り替え前に新サーバーの動作確認ができる）
198.51.100.25  example.com
198.51.100.25  www.example.com

上記は弊社が関わってきた移転案件の傾向をまとめたものです。DNS関連が約4割を占めており、「移転したのにサイトが表示されない」「メールが届かない」といった問い合わせの大半はここに起因しています。

サーバー・インフラでお困りですか？

障害対応・移行・パフォーマンスチューニングなど、ご相談ください

無料で相談する

サーバー管理、丸ごとお任せください

サーバー保守・運用

監視・障害対応・パフォーマンス改善まで、安定稼働をサポートします

200件以上の制作実績顧客満足度97% 初回相談無料

サービス詳細 30秒で送信 — 無料で相談する

※ 通常1営業日以内にご返信します

まとめ：移転を「成功」で終わらせるために

サーバー移転は、適切な準備と手順を踏めば安全に実施できます。ただし「費用が安くなるから」という理由だけで判断し、技術的な影響範囲を把握しないまま進めることが最大のリスクです。

特に、メール送信・SSL・外部API連携の3点は移転当日に止まると即ビジネス損失に直結します。事前調査・並行稼働期間・切り戻し計画の3つがセットで揃って、初めて安全な移転と言えます。

自社内にインフラ知識を持つエンジニアがいない場合は、移転判断の段階からプロに相談することを強くおすすめします。Fivenine Designでは、現状のサーバー環境の調査・移転計画の策定から実施・確認まで一貫してサポートしています。「コストを下げたいが、リスクが心配」という段階からご相談いただけます。