LASSIC Media らしくメディア
サーバーリプレイス外注｜費用・進め方・依頼先の比較ガイド
LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託
この記事のポイント
- サーバーリプレイス外注の費用は機器調達・設計・移行工事・データ移行・検証の5フェーズに分解して把握することで、見積もり精度が高まります
- 外注先の種類（SIer・専門ベンダー・クラウドSI）によって得意な移行方式と費用感が異なるため、自社要件との照合が不可欠です
- 失敗の大半はEOL調査の甘さ・データ移行の検証不足・要件伝達の曖昧さから生じており、5ステップの進め方でこれらを事前に潰せます
目次
サーバーリプレイス外注とは — オンプレ継続・クラウド移行との違い
サーバーリプレイス外注とは、老朽化・EOL（End of Life）到来・EOS（End of Support）対応などを契機に既存サーバーを更新する作業を、専門ベンダーや SIer（システムインテグレーター）に委託することです。自社で設計・調達・データ移行・切替を行うリソースが確保できない場合や、ダウンタイムを極力抑えることが求められる場合に外注が選ばれます。
オンプレ→オンプレ型リプレイスの特徴
オンプレミスからオンプレミスへのリプレイスは、データセンターまたは自社サーバー室での機器交換が中心です。セキュリティポリシー・ネットワーク構成・既存アプリケーションとの依存関係を変えずに済むため、基幹系システムや高セキュリティ要件の環境でよく選ばれます。
一方で、機器調達コストと設置工事が発生するため、初期費用がクラウド移行よりも明確に見積もりやすい反面、期中のスケールアップには再投資が必要になります。
オンプレ→クラウド型への移行との分岐ポイント
クラウド移行は「リプレイスの代替手段」として検討されることがありますが、アプリケーション互換性の調査・ネットワーク設計の見直し・クラウド専任エンジニアの確保など、追加で必要な作業が増えます。費用感・リードタイム・内製スキル要件が大きく異なるため、本記事ではオンプレリプレイスを主軸に解説し、クラウド移行費用については別途ご確認ください。
サーバーリプレイスを外注すべき3つの判断基準
外注か内製かの判断は、コストだけでなく「リスク管理能力」と「スケジュール遵守の確実性」で考えることが大切です。
社内スキル・リソース不足で内製が困難なケース
サーバーリプレイスには、物理設置・OS設定・ミドルウェア再構築・アプリケーション移行・ネットワーク再設定など、複数の専門領域が絡みます。これらを一気通貫で担える社内エンジニアが不在の場合、外注が現実的な選択です。
特に情報システム担当が1〜2名規模の中堅企業では、本業の運用業務を抱えながらリプレイスを並走させるとどちらも品質が落ちるリスクがあります。
EOL・EOS対応で期限が定まっている場合
EOL（End of Life、製品の販売・サポート終了）やEOS（End of Support、OSベンダーのセキュリティパッチ提供終了）の期日が決まっている場合、逆算したスケジュールへの対応が求められます。期日を過ぎると脆弱性が放置されたシステムで業務継続するリスクが生じます。
外注ベンダーに依頼することで、他案件の施工実績を持つ専任チームがスケジュール管理を担い、社内工数を極力抑えた移行が期待できます。
ダウンタイム抑制・リスク管理が不可欠なケース
24時間365日稼働の基幹業務システムや顧客向けサービスでは、切替中の停止時間が直接的な損失に結びつきます。新旧環境を並行稼働させて瞬時に切り替える「並行稼働切替」やバックアップリストア検証など、専門ノウハウが必要な場面では、経験豊富な外注ベンダーを活用することでリスクを大きく低減できます。
サーバーリプレイス外注の費用目安と内訳
以下の費用情報は市場参考値であり、一次資料に基づく確定値ではありません。実際の費用はシステム規模・移行方式・対応ベンダーによって大きく異なります。正確な見積もりは複数ベンダーへのRFPで確認してください。
費用に影響する主な要因
費用を大きく左右するのは次の4要素です。
- サーバー台数と用途：ファイルサーバー・DBサーバー・Webサーバーなど役割が増えるほど工数が増加します
- データ量と移行方式：大容量DBのオンライン移行はオフライン移行より時間とテスト工数が多くなります
- アプリケーション依存性：独自開発アプリほど互換性確認・修正工数が増えます
- 作業環境（自社DC/外部DC/遠隔地）：現地作業が発生する場合は交通費・出張費が加わります
フェーズ別の費用内訳イメージ
| フェーズ | 主な作業内容 | 費用イメージ（市場参考値） | 留意点 |
|---|---|---|---|
| 機器調達 | サーバー本体・ラック・UPS等の購入またはリース | 機種・スペックによる | リース契約にするとキャッシュフローへの影響を平準化できます |
| 設計・構築 | OS設定・NW設計・ミドルウェア構築・セキュリティ設定 | 規模・台数次第 | 既存設計書の有無で工数が大きく変わります。 設計書がない場合は現状調査費が別途発生します |
| データ移行 | DB・ファイル・メール等のデータ移行と整合性確認 | データ量・方式次第 | オンライン移行はダウンタイムを抑えられますが工数は増加します |
| 動作テスト・検証 | アプリ動作確認・負荷テスト・セキュリティスキャン | アプリ数・複雑度次第 | テスト期間を短縮すると切替後の障害リスクが高まります |
| 本番切替・運用引継ぎ | DNS/IP切替・旧サーバー廃棄・ドキュメント整備 | 切替方式次第 | 廃棄時のデータ消去証明書発行が必要な場合は別途費用が発生します |
合計費用の目安は、小規模（サーバー1〜3台・既存設計書あり）と大規模（10台超・独自アプリ多数）では桁が変わることがあります。複数ベンダーから見積もりを取得し、工数根拠を項目ごとに確認することを強くおすすめします。
外注で失敗しない5ステップの進め方
外注を成功させるには、発注側も進め方の全体像を把握したうえでベンダーと協働することが大切です。以下の5ステップが標準的な進め方の型です。
ステップ1：現状調査とEOL・要件の洗い出し
まず自社環境の棚卸しをします。稼働中のサーバー台数・OS・ミドルウェア・EOL期日・依存するアプリケーションの一覧を作成します。この一覧の精度がそのまま後工程の見積もり精度に直結します。
EOL/EOSの期日はベンダーの公式ページで確認します。EOL後もサポート延長契約（Extended Security Update等）を利用している場合は、延長期日もあわせて把握しておきましょう。
ステップ2：移行方式と業者要件の定義（RFP作成）
オンプレ継続かクラウド移行かを決定し、希望するダウンタイム上限・セキュリティ要件・SLA（Service Level Agreement：サービスレベル合意書）を文書化します。この文書（RFP：提案依頼書）をベンダーに渡すことで、後の比較が横一線でできるようになります。
移行方式の選択肢（ライブマイグレーション・コールドマイグレーション・段階的並行稼働など）も事前に候補を絞っておくと、ベンダーからの提案品質が上がります。
ステップ3：ベンダー選定・見積もり比較
複数社（最低3社以上）に同一RFPを送付し、見積もりを比較します。金額だけでなく「工数の根拠」「担当エンジニアのスキルセット」「過去の類似案件実績」を確認します。
提示金額が低い提案だけで選定すると、後から追加費用が発生するケースがあります。総額での比較と、不明点の書面回答を求めることが大切です。
ステップ4：移行実施とデータ移行・テスト
発注後はプロジェクト管理の中心になる担当窓口を社内に置きます。週次の進捗報告・課題管理表の共有・変更管理プロセスを事前に合意しておくことで、手戻りが生じた際の対処が速くなります。
データ移行後は整合性チェック（レコード件数・ハッシュ値照合など）を実施します。移行後の検証なしで本番切替に進むと、データ欠損や不整合が本番環境に持ち込まれるリスクがあります。
ステップ5：本番切替・運用引き継ぎ・検証
本番切替は業務閑散時間（深夜・週末）を選び、切替直前に最新バックアップを取得します。切替後の監視期間（最低1〜2週間）はベンダーのサポート体制を手厚くしてもらうよう事前に契約に明記しておきます。
完了後は構成図・設定ドキュメント・緊急対応手順書の納品を求めます。これらがないと、次回のリプレイスや障害発生時に社内対応ができなくなります。
依頼先の選び方と比較観点 — SIer・専門ベンダー・クラウドSIの違い
外注先の形態によって得意領域・価格帯・対応速度が異なります。自社の規模・システム特性・予算に合わせた選定が重要です。
| 依頼先の種類 | 特徴・得意領域 | 向いているケース | 注意点 |
|---|---|---|---|
| 大手SIer | 上流設計から構築・運用保守まで一気通貫で対応可能。 認定資格・プロジェクト管理体制が充実 |
複数拠点・数十台規模・基幹系の大規模案件 | 費用は高めになりやすく、中小規模案件は対応優先度が下がることがあります |
| インフラ専門ベンダー | サーバー・NW構築に特化。工数単価が大手より抑えられる場合が多い | 10台以下・比較的シンプルな構成のオンプレリプレイス | アプリケーション層の対応は別会社との分業になることがあります |
| クラウドSI・MSP | AWS・Azure・GCPなどパブリッククラウドの設計・移行・運用管理に特化 | オンプレ→クラウド移行を同時に検討している場合 | オンプレ→オンプレの純粋なリプレイス案件は得意でない場合があります |
| 元請（プライムベンダー）型IT会社 | 設計から構築・運用保守まで一社完結で対応。 サブコン（下請け）管理も担い窓口を一本化できる |
社内リソースが少なく、外注管理工数も最小化したい場合 | 元請会社の実績・体制をRFP段階でしっかり確認することが大切です |
自社規模・システム特性に応じた選定基準
選定の第一基準は「類似案件の実績件数」です。自社と同規模・同業種のリプレイスを手がけた実績があるベンダーは、リスクとコストの見積もり精度が高い傾向があります。
提案書には「プロジェクト責任者とメンバーのスキルセット」も明記してもらいましょう。商談時に出てくる営業担当と実際の作業担当が異なることがあるため、実務担当者の確認が大切です。
見積もり時に確認すべき5つのポイント
- 工数の項目別内訳：「一式○円」ではなく、設計・構築・テスト・切替それぞれの工数根拠を確認します
- 追加費用の発生条件：スコープ外の作業が発生した場合の単価・対応フローを事前に確認します
- 保証期間とアフターサポート：切替後の障害対応範囲と対応時間（営業時間内のみか24時間対応か）を明確にします
- 成果物の定義：設計書・手順書・緊急対応マニュアルの納品が含まれるかを確認します
- データ廃棄証明：旧サーバーのデータ消去方式と証明書発行の有無を確認します
よくある失敗パターンと対策チェックリスト
外注リプレイスで問題が生じる場面は、大半が「事前準備の不足」に起因します。以下の失敗パターンを事前に把握することで、発注側の対策が立てやすくなります。
失敗1：EOL調査が甘く移行計画が遅延
OSやミドルウェアのEOL期日を直前まで把握しておらず、EOL後に移行作業をスタートするケースがあります。EOL後の環境ではセキュリティパッチが提供されないため、脆弱性が放置されたまま稼働を続けることになります。
対策は「年に1度のEOL棚卸し」をIT管理業務に組み込み、2年以上先の期日も早期に把握しておくことです。余裕を持ったスケジュールで複数社への相見積もりができ、費用交渉力も高まります。
失敗2：データ移行の検証不足で本番切替後に障害
「テスト環境では問題なかったが本番切替後にDBの一部データが欠損していた」というケースは、データ移行の検証が件数確認のみで整合性チェックをしていなかった場合に起こりやすいです。
対策として、移行後のデータは「件数」「チェックサム」「業務ロジック上の整合性」の3段階で検証することを推奨します。重要データは旧環境のバックアップを本番切替から一定期間保持し、問題発生時に切り戻せる体制を用意します。
失敗3：依頼先に丸投げして要件が伝わらず手戻り
「プロに任せればいい」という姿勢で詳細要件の伝達を省略すると、ベンダー側が推測で設計を進めます。その結果、完成物が自社業務フローと合わず、大規模な修正が発生するケースがあります。
発注側の担当者が週次でベンダーと進捗確認を行い、変更点や懸念事項を都度書面で共有することが大切です。コミュニケーション頻度が高いほど手戻りリスクは下がります。
以下の対策チェックリストを活用してください。
- 全サーバーのEOL/EOSを一覧化し、1年以上前から移行計画を開始している
- RFPに自社の要件（ダウンタイム上限・セキュリティ要件・SLA）を文書化している
- データ移行後の検証（件数・チェックサム・整合性）を工程計画に明記している
- 本番切替後の監視体制・切り戻し手順をベンダーと事前合意している
- 設計書・手順書・緊急対応マニュアルの納品を契約に明記している
- 旧サーバーのデータ廃棄証明書の取得を契約に含めている
まとめ：外注成功の3つの判断軸
本稿では、サーバーリプレイス外注の概念・費用内訳・5ステップの進め方・依頼先の比較観点・よくある失敗パターンを整理しました。要点を3つに集約すると次のとおりです。
第一に、外注判断の基準は「内製スキルの不足」「EOL期日のタイトなスケジュール」「ダウンタイム最小化の必要性」であり、1つでも該当すれば外注が有力な選択肢です。第二に、費用は機器調達・設計・データ移行・テスト・切替の5フェーズに分解して見積もることで、追加費用の発生条件を事前に把握できます。第三に、依頼先の選定は類似案件の実績件数・担当エンジニアのスキルセット・成果物の定義の3点を軸に複数社比較することが、コストと品質両面でのリスクを下げる近道です。
よくある質問
サーバーリプレイスの外注にかかる期間はどのくらいですか？
規模や移行方式によって異なりますが、小規模（サーバー1〜3台・既存設計書あり）では現状調査から本番切替完了まで3〜4か月程度が目安とされます。中規模以上（10台超・アプリ依存多数）では半年から1年以上かかることがあります。EOL対応など期日が定まっている場合は、1年以上前から計画を開始することが大切です。
リプレイス中の業務停止時間（ダウンタイム）はどう管理しますか？
ダウンタイムを最小化するには、新旧環境を一定期間並行稼働させてから切り替える「並行稼働切替方式」が有効です。業務閑散時間（深夜・週末）に本番切替を設定し、切替直前に最新バックアップを取得します。許容ダウンタイムの上限はRFP段階でベンダーに明示し、契約に盛り込むことで担保できます。
オンプレリプレイスとクラウド移行のどちらを選ぶべきですか？
判断基準はセキュリティ要件・スケールの変動幅・ランニングコストの試算の3点です。高セキュリティ要件・安定負荷・社内ネットワーク依存度が高い場合はオンプレ継続が合理的です。反対に負荷変動が大きく初期投資を抑えたい場合はクラウド移行が選ばれます。クラウド移行には追加の互換性調査やエンジニアスキル要件があるため、費用・工数・リスクを別途比較することをおすすめします。
複数のベンダーに見積もりを依頼する際の注意点はありますか？
同一のRFP（提案依頼書）を全社に送付することが大切です。要件がベンダーごとに異なると見積もりの前提条件がずれて金額比較ができなくなります。また「一式〇円」の提案は追加費用が発生しやすいため、工数の項目別内訳・追加費用の発生条件・保証期間・成果物の定義を確認することをおすすめします。最低3社からの見積もりを比較することが推奨されます。
旧サーバーの廃棄はどのように取り扱いますか？
旧サーバーのHDD/SSDには業務データが残っているため、適切なデータ消去が必要です。消去方法は「ソフトウェアによる上書き消去」「物理破壊」「専門業者への委託」が一般的です。個人情報保護法・社内情報管理規程に基づく廃棄証明書の取得が求められる場合は、ベンダーへの発注時に「データ消去証明書の発行」を契約に含めることを推奨します。
著者：テレリモ総研編集部 鈴木 亮佑
ご不明な点はお問い合わせフォームからもご連絡いただけます。
- *1 出典：総務省「令和6年版 情報通信白書」（2024年）― 企業のIT投資・クラウド利用状況
- *2 出典：IPA（情報処理推進機構）「DX動向2025」（2025年）― 企業のシステム刷新・インフラ更新に関する調査
