サーバー移設の手順と見落としやすい注意点【完全解説】

サーバー移設は、手順を誤るとデータ消失や長時間のサービス停止を招く作業です。この記事ではサーバー移設 手順 注意点を網羅的に解説します。サーバー移設 手順 注意点を正しく把握し、事前の現状調査からDNS切り替え、旧サーバー廃棄までを一貫して管理することで、ダウンタイムを最小限に抑えられます。この記事では、計画段階から移設後の運用体制構築まで全工程を網羅し、読了後すぐに自社の移設プロジェクトを始められる実践的な情報をお届けします。

サーバー移設とは？移行が必要になる主な理由

サーバー移設とは、稼働中のサーバー環境を別のハードウェアやデータセンター、クラウド基盤へ移し替える作業を指します。単なる物理的な移動だけでなく、OS・ミドルウェア・アプリケーション・データの全てを新環境で再現する作業が含まれます。

移設が求められる場面は多岐にわたります。ハードウェアの老朽化による故障リスクの増大は、最も多い移設理由の一つです。メーカーの保守期限が切れると、部品交換や障害対応が受けられなくなり、業務停止のリスクが高まります。

コスト面の見直しも大きな動機です。総務省「令和6年通信利用動向調査」（2025年5月公表）によると、企業のクラウドサービス利用率は80.6%（前年77.7%）に達しています。オンプレミスからクラウドへの移行によって、運用コストの最適化を図る企業が増えている状況です。

章末サマリー：サーバー移設はハードウェア老朽化・コスト最適化・クラウド化が主な動機であり、OS・データ・アプリケーションの全てを新環境で再現する包括的な作業です。

移設前に確認すべき現状調査の全項目

移設の成否は、事前の現状調査でほぼ決まります。調査が不十分なまま作業を始めると、移行先で「動かない」「つながらない」というトラブルに直面しやすくなります。

最初に把握すべきはOS・ミドルウェアのバージョン情報です。Webサーバー（Apache・Nginx）、データベース（MySQL・PostgreSQL）、プログラム言語（PHP・Java・Python）のバージョンが新環境でも対応しているか確認します。バージョン差異がアプリケーションの動作不良を引き起こすケースは少なくありません。

ネットワーク設定も漏れなく記録してください。IPアドレス、サブネットマスク、デフォルトゲートウェイ、DNS設定、ファイアウォールのルール一覧が対象です。SSL証明書の種類・有効期限・発行元、ドメインの管理者情報とレジストラも把握しておきます。

見落としやすいのがcron（定期実行タスク）の一覧と、外部サービスとの連携設定です。API接続先のIPアドレス制限やWebhookの通知先URLなど、サーバー単体では完結しない依存関係を洗い出しておくと、移行後のトラブルを大幅に減らせます。

章末サマリー：OS・ネットワーク・SSL・アプリケーション・定期タスクの5領域を網羅的に調査することが、移設トラブル防止の基盤です。

移設計画の立て方：スケジュールと担当者の設定

「いつ・誰が・何をするか」を明確にしないまま始める移設は、作業の抜け漏れや責任の所在が曖昧になりがちです。計画段階で体制と工程を固めておくことが、円滑な移設の前提条件です。

スケジュールを組む際は、自社の繁忙期を避けた日程を選びます。月末の締め処理やセール期間中の切り替えは避けてください。DNS切り替えの実施は、問い合わせ対応がしやすい平日の早朝か、利用者の少ない休日が適しています。

体制面では、最低限「プロジェクト責任者」「インフラ担当」「アプリケーション担当」「検証担当」の4役を割り当てます。兼務でも構いませんが、各工程の担当と判断者を明文化しておくと、トラブル発生時の初動が早くなります。GXOが支援した案件では、担当者の役割が明文化されていなかったプロジェクトで、切り替え当日に指示系統が混乱し、作業時間が2〜3倍に延びるケースが繰り返し見られました。役割の明文化だけで、当日の対応速度が大きく変わります。

工程表には「作業」と「判定基準」をセットで記載します。「新サーバーにデータを移行する」だけでなく、「移行後にレコード数が一致することを確認する」という完了条件を添えておくと、作業品質が安定します。

章末サマリー：繁忙期を避けた日程設定・4役の担当明確化・完了条件付きの工程表作成が、移設計画の三本柱です。

新サーバーの選定基準：オンプレミス・クラウド・レンタルの比較

移行先のサーバー選びを誤ると、移設後に再度の移行が必要になる場合があります。自社の要件に合った選択肢を見極めるために、3つのタイプの特徴を整理します。

IDC Japan（2022年3月発表）の予測では、国内パブリッククラウドサービス市場の年平均成長率は18.8%とされ、2026年には約3兆7,586億円規模に達する見込みです。クラウド移行を検討する企業が増える一方で、業種や扱うデータの性質によってはオンプレミスが適している場合もあります。

選定の判断軸は「初期投資の許容範囲」「求める可用性」「社内に運用できる人材がいるか」の3点です。これらを明確にしたうえで比較検討すると、移行後に後悔しにくくなります。

章末サマリー：オンプレミス・クラウド・レンタルにはそれぞれ強みがあり、初期投資・可用性・運用人材の3軸で自社に合った選択をすることが大切です。

データバックアップの手順と保管方法

バックアップは移設作業の「保険」です。万が一データが破損した場合でも、正しいバックアップがあれば復旧できます。逆に、バックアップが不完全だと取り返しのつかない事態になりかねません。

バックアップ対象は大きく3つに分けられます。まずファイルデータです。Webコンテンツ、アップロードされた画像や文書、ログファイルなどをまとめて取得します。次にデータベースです。mysqldumpやpg_dumpなどのツールを使い、全テーブルのエクスポートファイルを作成します。最後に設定ファイルです。Webサーバー、データベース、メールサーバー、cronの設定を個別に保存します。

保管先は1箇所に限定しないでください。ローカルストレージに加えて、クラウドストレージや物理メディアへのオフサイト保管（遠隔地での保管）を併用します。最低でも2世代分のバックアップを保持しておくと、直前のバックアップ自体に問題があった場合にも対処できます。

バックアップの取得後は、リストア（復元）テストを必ず実施してください。「取ったつもりが中身が空だった」「文字化けで使えなかった」という事故は珍しくありません。テスト環境にリストアして正常に動作するかまで確認して、はじめてバックアップが完了したといえます。

1. バックアップ対象を3分類に整理する（ファイル・DB・設定ファイル）

2. 取得コマンドを実行し、ファイルサイズを確認する

3. 複数の保管先に転送する

4. テスト環境でリストアして動作確認する

章末サマリー：ファイル・データベース・設定ファイルの3種を対象に、複数の保管先と世代管理を組み合わせ、リストアテストまで実施することがバックアップの鉄則です。

新サーバーの環境構築：OSからアプリケーションまでの設定手順

環境構築は「下のレイヤーから順に積み上げる」のが原則です。OSのセットアップを終えてからミドルウェア、そしてアプリケーションの順に進めます。

OSのインストール後は、カーネルパラメータやタイムゾーンの設定を確認します。旧サーバーと同じタイムゾーンに合わせておかないと、ログの時刻やバッチ処理のスケジュールにずれが生じます。セキュリティアップデートの適用もこの段階で済ませます。

Webサーバーの設定では、旧環境の設定ファイルをそのまま持ち込むのではなく、新環境に合わせて調整してください。ドキュメントルートのパス、バーチャルホストの設定、アクセス制御のルールは環境によって異なる場合があります。

データベースのインストール後は、文字コード（UTF-8）と照合順序の設定を旧環境と一致させます。この設定が異なると、日本語データの文字化けや検索結果の不一致が起きます。GXOの支援経験では、文字コードの不一致は移設後トラブルの中で最も発見が遅れるケースの一つです。本番稼働から数日後に管理画面の日本語項目だけが文字化けする報告を受け、原因究明に半日以上かかった事例があります。照合順序の確認は移行前チェックリストに必ず加えてください。

アプリケーションのデプロイ後は、依存ライブラリのバージョンが旧環境と同一かを確認し、動作テストを行います。

章末サマリー：OS → Webサーバー → データベース → アプリケーションの順に構築し、各レイヤーで旧環境との設定差異がないかを1つずつ確認することが構築の基本です。

データ移行の実施手順：ファイルとデータベースの転送方法

データ移行では「転送」と「整合性確認」をセットで行うことが前提です。転送だけで終わらせると、途中で通信エラーが起きていたことに後から気づく可能性があります。

ファイル転送にはrsync（差分同期ツール）がよく使われます。SSH経由で暗号化された通信路を確保しつつ、差分のみを転送できるため効率的です。大量のファイルがある場合は、初回の全量転送を事前に済ませておき、切り替え直前に差分転送だけを行う「二段階方式」が有効です。

データベースの移行は、mysqldump（データベースのエクスポートツール）でSQLファイルを出力し、新サーバーでインポートする方法が一般的です。大規模なデータベースでは、テーブル単位で分割してエクスポートすると、万一エラーが起きた際に該当テーブルだけを再実行できます。

転送後の整合性確認では、ファイルの総数とサイズの比較、データベースの各テーブルのレコード数の照合を行います。チェックサム（md5sum等）を使ったファイル単位の検証も有効です。

章末サマリー：ファイルはrsync、データベースはmysqldumpが定番の転送手段であり、転送後に必ずファイル数・レコード数・チェックサムで整合性を確認することが移行品質を担保します。

動作検証：移行後に必ず確認すべき項目一覧

動作検証を省略して本番切り替えを行うと、利用者からの障害報告が殺到するリスクがあります。切り替え前に新サーバー上で十分な検証を実施してください。

Webサイトの表示確認では、トップページだけでなく下層ページ、問い合わせフォーム、ログイン機能、検索機能など主要な導線を一通り操作します。画像やCSSの読み込みが正常か、リンク切れがないかも確認対象です。

メールの送受信テストは見落とされやすい検証項目です。送信テスト（フォーム経由・システムメール）と受信テストの両方を行い、迷惑メール判定されていないかも確認します。SPFレコードやDKIM設定が正しくないと、送信メールが届かない場合があります。

パフォーマンスの検証も欠かせません。ページの読み込み速度を計測し、旧環境と大きな差がないかを比較します。負荷テストツールを使ってアクセス集中時の応答速度を事前に確かめておくと安心です。

検証の結果は「合格基準」と照らし合わせて判定します。「表示されればOK」ではなく、「応答時間が旧環境比120%以内」のような数値基準を設けておくと、判断がぶれません。

章末サマリー：Web表示・メール送受信・アプリケーション機能・パフォーマンスの4領域を、数値基準を設けて検証することで、切り替え後のトラブルを防止できます。

並行稼働の設定と旧サーバー維持の期間目安

「いきなり全面切り替え」はリスクが高い方法です。新旧サーバーを一定期間並行稼働させることで、問題が見つかった際に旧サーバーへ素早く戻せる体制を確保できます。

並行稼働中に新サーバーの動作確認を行うには、hostsファイル（ドメインとIPの対応を手動設定するファイル）の編集が便利です。確認者のPC上でhostsファイルを書き換え、ドメインを新サーバーのIPに向ければ、DNS切り替え前に新環境での表示やアプリケーション動作を確認できます。

旧サーバーの維持期間は、業種やシステムの規模によって異なりますが、DNS切り替え後に少なくとも2週間は維持しておくことを推奨します。メールの配送遅延やDNSキャッシュの残存により、切り替え後もしばらくは旧サーバーへアクセスが届くことがあるためです。

維持期間中は旧サーバーのアクセスログを定期的に確認し、アクセスがゼロに近づいたことを確認してから契約解除に進むと安全です。

章末サマリー：並行稼働によるリスク低減・hostsファイルでの事前検証・DNS切り替え後2週間以上の旧サーバー維持が、安全な移行の三要素です。

DNS切り替えの手順とTTL設定の考え方

DNS切り替えはサーバー移設の「最終スイッチ」です。この工程の進め方を誤ると、Webサイトにアクセスできない時間が長引きます。手順を正確に把握してから実施してください。

切り替えの1週間前に、TTL（Time To Live：DNSレコードのキャッシュ保持時間）を短縮します。通常は86,400秒（24時間）程度に設定されていますが、移行前に300〜600秒（5〜10分）まで下げておきます。こうすることで、切り替え後にDNSキャッシュが速やかに更新されます。

切り替え当日は、Aレコード（ドメインとIPアドレスの対応）を新サーバーのIPに変更します。メールサーバーも移行する場合は、MXレコードの変更も同時に行います。変更後、反映までに最大72時間かかる場合がありますが、TTLを事前に短縮していれば多くの場合は数時間以内に反映されます。

切り替え後はTTLを元の値に戻すことを忘れないでください。短いTTLのままだとDNSサーバーへの問い合わせ頻度が上がり、わずかながら名前解決の遅延が発生する場合があります。

章末サマリー：TTLを1週間前に短縮 → Aレコード・MXレコード変更 → 反映確認 → TTL復元の順で進めることが、ダウンタイムを最小化するDNS切り替えの手順です。

SSL証明書の移行と再発行手順

SSL証明書の移行を怠ると、サイトにアクセスした際に「この接続は安全ではありません」という警告が表示され、利用者の信頼を損ないます。

まず既存の証明書の有効期限と種類を確認します。DV証明書（ドメイン認証型）・OV証明書（組織認証型）・EV証明書（拡張認証型）のいずれかによって、移行の手順が異なります。有効期限が残っている場合は、証明書ファイル（CRT）と秘密鍵（KEY）を新サーバーにコピーして設定することで引き継げます。

有効期限が近い場合や、Let's Encrypt（無償で利用できる証明書発行機関）を使っている場合は、新サーバー上で再発行する方法が簡便です。Let's Encryptはコマンド一つで証明書を取得・更新できるため、小規模なサイトでは移行を機に切り替えを検討してもよいでしょう。

設定後は、ブラウザでhttpsアクセスして証明書の情報を確認します。ドメイン名の一致・有効期限・証明書チェーンの正当性を検証してください。

章末サマリー：既存証明書の有効期限と種類を確認したうえで、コピーまたは再発行で新サーバーに適用し、httpsアクセスで検証するまでがSSL移行の一連の手順です。

メール環境の移行で見落としやすいポイント

Webサイトの移行は順調でも、メール環境の移行で問題が発覚するケースは少なくありません。メールは業務に直結するため、送受信の停止は営業機会の損失に直結します。

MXレコードの変更タイミングはDNS切り替えと同時に行います。しかし、SPFレコード（送信元サーバーの正当性を証明するDNS設定）の更新を忘れると、新サーバーから送信したメールが受信側で迷惑メール扱いされる恐れがあります。新サーバーのIPアドレスをSPFレコードに追加してから切り替えを行ってください。

DKIM（メールに電子署名を付与する仕組み）を利用している場合は、新サーバーでの鍵ペア生成とDNSへの公開鍵登録が別途求められます。加えて、DMARC（SPFとDKIMの検証結果に基づく受信ポリシー）の設定も見直してください。

メールデータ（過去の送受信メール）の移行も忘れがちな作業です。IMAPを使っている場合は、メールクライアント側でアカウント設定を新サーバーに変更するだけで済む場合もありますが、サーバー側にメールを蓄積している場合はデータの移送が必要です。

章末サマリー：MXレコード変更に加え、SPF・DKIM・DMARCの送信ドメイン認証設定の更新と、メールデータの移送がメール移行の見落としやすいポイントです。

移設時に起きやすいトラブルと原因・対処法

どれほど慎重に準備しても、移設時にトラブルがゼロになることはまれです。発生頻度の高いトラブルとその原因を事前に把握しておくことで、初動対応を速められます。

GXOの支援経験では、移設後トラブルの約7割が「設定の転記漏れ」に起因していました。特にcronジョブと外部API連携の設定は、旧環境のドキュメントに記載されていないケースが多く、移設後に初めて存在に気づくことがあります。設定項目をチェックリスト化し、2名以上でダブルチェックする仕組みを入れるだけで、発生件数を大幅に減らせます。

万が一、復旧に時間がかかる場合は、DNSを旧サーバーに戻して一時的にサービスを復旧させる判断も選択肢に含めてください。「戻せる状態」を維持しておくことが、移設における最大のリスク対策です。

章末サマリー：移設トラブルの多くは設定漏れに起因しており、チェックリストとダブルチェック、旧サーバーへの切り戻し手段の確保が対策の柱です。

移設コストの目安：自社対応と外部委託の費用比較

移設にかかるコストは、自社対応か外部委託かで大きく変わります。判断を誤ると、予算超過やスケジュール遅延を招くため、事前に費用構造を把握しておくことが欠かせません。

自社対応の場合、直接的な支出は少なく見えますが、担当者が通常業務と並行して対応するため、本業への影響が隠れたコストとなります。一方、外部委託では費用が明確になるかわりに、社内にノウハウが蓄積されにくい側面があります。

判断基準としては、「社内にサーバー構築の経験者がいるか」「移設対象が複雑か（複数台・複数サービス）」「移設の期限が厳しいか」の3点を検討してください。経験者がおらず、対象が複雑で、期限が迫っている場合は、外部委託のほうが結果的にコストを抑えられる可能性があります。

章末サマリー：自社対応は見えにくい人件費に注意し、外部委託は明確な費用で工期短縮が見込める選択肢です。経験者の有無・対象の複雑さ・期限の3点で判断してください。

外部委託を検討している場合は、GXOに早期相談いただくことで、費用と期間の概算を無料でお伝えできます。お気軽にご相談ください。

移設後の運用体制づくりと監視設定

移設が完了した直後こそ、監視体制の整備が求められるタイミングです。新環境特有の問題は、稼働開始後に初めて表面化するケースが少なくありません。

死活監視は最低限の設定です。Webサーバーが応答しているかをHTTPリクエストで定期的に確認し、異常時にメールやチャットで通知します。無料で使える監視ツールもあるため、予算が限られている場合でも導入できます。

リソース監視（CPU・メモリ・ディスク使用率の継続的な計測）を加えると、障害の予兆を検知できます。ディスク使用率が急上昇している場合はログの肥大化、メモリ使用率が高止まりしている場合はアプリケーションのメモリリークを疑えます。

ログの一元管理も移設後に見直すべき項目です。アクセスログ・エラーログ・アプリケーションログを一箇所に集約し、検索・分析できるようにしておくと、障害発生時の原因特定が速くなります。

運用ルールとしては、「バックアップ取得の頻度と確認方法」「セキュリティアップデートの適用タイミング」「障害時の連絡フローと判断基準」を文書化しておきます。

章末サマリー：死活監視・リソース監視・ログ収集の3つの監視設定と、バックアップ・アップデート・障害対応のルール文書化が、移設後の安定運用の基盤です。

旧サーバーの安全な廃棄・契約解除の手順

旧サーバーの処理を怠ると、不要なコストが発生し続けるだけでなく、データ漏えいのリスクも残ります。移設プロジェクトは旧サーバーの廃棄まで含めて完了と考えてください。

物理サーバーの場合は、ディスク内のデータを完全消去する必要があります。単にファイルを削除するだけではデータの復元が可能なため、ディスク全体を上書き消去するツールを使用します。リース返却の場合は、リース会社が指定するデータ消去方法を確認してください。

データ消去後は、廃棄証明書（データ消去証明書）を取得しておくと、後から情報管理の記録として活用できます。クラウドの場合は、インスタンスの削除とあわせてストレージやスナップショットも全て削除し、契約の解約手続きを忘れずに行います。

契約解除のタイミングは、新サーバーでの運用が安定し、旧サーバーへのアクセスがほぼなくなったことを確認してからにします。

章末サマリー：データの完全消去・廃棄証明書の取得・契約解除の3ステップで旧サーバーの処理を完了し、移設プロジェクトを締めくくります。

移設プロジェクトを成功させる自社対応チェックリスト

ここまでの各工程を「計画」「実施」「確認」「完了」の4フェーズに整理し、チェックリストとしてまとめました。社内での進捗管理にご活用ください。

【計画フェーズ】

【実施フェーズ】

【確認フェーズ】

【完了フェーズ】

章末サマリー：計画・実施・確認・完了の4フェーズごとにチェック項目を設け、各フェーズの完了を確認しながら進めることで、抜け漏れのない移設を実現できます。

外部委託先の選び方と依頼時に伝えるべき情報

外部に移設を依頼する場合、委託先の選び方次第でプロジェクトの成否が変わります。見積もり金額だけで判断せず、対応品質を見極めるための基準を持っておくことが欠かせません。

選定時に確認すべき点は、同規模・同業種の移設実績があるか、作業後のサポート体制は明確か、担当者に直接連絡できるかの3つです。実績確認の具体的な方法としては、「過去の移設案件の事例概要を1件見せてもらえますか」と問い合わせ段階で依頼することが有効です。回答が曖昧な場合は、実績が乏しいサインかもしれません。GXOへの相談案件の中でも、「以前の委託先が安価だったが、トラブル発生後に連絡が取れなくなった」という経緯で問い合わせをいただくケースが一定数あります。費用だけで判断するリスクは実際に発生しています。

見積もりを依頼する際は、以下の情報を事前にまとめておくと、比較検討がしやすくなります。

複数の委託先から見積もりを取り、作業範囲・サポート内容・費用の三要素を横並びで比較してから判断してください。

章末サマリー：実績・サポート体制・連絡の取りやすさを選定基準とし、サーバー構成・移行範囲・希望スケジュールをまとめて見積もりを依頼すると、委託先選びで失敗しにくくなります。

よくある質問（FAQ）

Q1. サーバー移設にはどのくらいの期間がかかりますか？

規模や移行内容によりますが、小規模なWebサーバー1台であれば計画から完了まで2〜4週間が目安です。複数台のサーバーやメール・データベースを含む場合は、1〜3ヶ月程度を見込んでおくと余裕を持って進められます。

Q2. 移設中にWebサイトが完全に止まる時間はありますか？

DNS切り替え方式を採用し、TTLの事前短縮と並行稼働を組み合わせれば、実質的なダウンタイムはほぼゼロに近づけられます。ただし、データベースの最終同期など一部の作業で数分〜数十分の停止が必要になることがあります。

Q3. DNS切り替え後、反映までどのくらいかかりますか？

TTLを事前に短縮していれば、多くの場合は数時間以内に反映されます。ただし、一部のISPやキャッシュサーバーではTTLを無視する場合があり、最大72時間かかる可能性も考慮してください。

Q4. 移設に失敗した場合、元に戻せますか？

旧サーバーを並行稼働させていれば、DNSを旧サーバーに戻すことでサービスを復旧できます。そのため、切り替え後も最低2週間は旧サーバーを維持しておくことを推奨します。

Q5. 自社に専門知識がなくても移設できますか？

基本的な手順を理解していれば、小規模な移設は自社対応も可能です。ただし、複数サービスが稼働する環境や、ダウンタイムが許容されない業務システムの場合は、専門の事業者への委託を検討してください。

安全なサーバー移設を実現するために今すぐできること

この記事では、サーバー移設の手順と注意点を計画段階から旧サーバーの廃棄までの全工程にわたって解説しました。

GXOの180社支援経験から見た、移設成功の3つの分岐点：

• 現状調査の精度が移設の成否を9割決める：調査漏れが多いプロジェクトは、切り替え当日のトラブル発生率が高い

• 「戻せる状態」を維持し続けること：バックアップ・並行稼働・切り戻し手順の3つが揃ってリスクゼロに近づく

• DNS切り替えはゴールではなくスタートライン：SSL・メール認証・旧サーバー維持の3点が完了して初めて移設が完了する

まず着手すべきは、現在のサーバー環境の棚卸しです。OS・ミドルウェアのバージョン、ネットワーク構成、SSL証明書の有効期限を一覧化するだけでも、移設の全体像が見えてきます。自社だけでの対応に不安がある場合は、早い段階で専門家に相談することで、手戻りのない計画を立てやすくなります。

GXOでは、180社以上のAI・DX支援実績（成功率92%）をもとに、東京都新宿区本社とベトナム開発拠点の体制で上流から下流まで伴走型支援を行っています。まずはお気軽にご相談ください。

→ お問い合わせはこちら

参考資料

• 総務省「令和7年版 情報通信白書 クラウドサービス」（2025年）https://www.soumu.go.jp/johotsusintokei/whitepaper/ja/r07/html/nd111210.html

• IDC Japan「国内パブリッククラウドサービス市場予測」（2022年3月発表）https://it.impress.co.jp/articles/-/22933