LASSIC Media らしくメディア
ベンダー移管・委託の進め方｜引き継ぎから費用相場まで解説
LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託
この記事のポイント
- ベンダー移管は「引き継ぎ計画→ドキュメント取得→並行稼働→切替完了」の段階的アプローチが障害リスクを抑えます
- 現行ベンダーから取得すべきドキュメントと、移管先に確認すべき5つのポイントを整理しています
- 費用相場（規模別の参考レンジ）と、コストを抑えるための交渉・設計のポイントも紹介します
目次
ベンダー移管委託とは：委託先の切替と保守引き継ぎの全体像
ベンダー移管委託とは、現在システムの保守・運用を任せている委託先（ベンダー）から、別の委託先へ業務を引き継いで移管することを指します。サーバーの物理移設やクラウドへの基盤移行とは異なり、あくまで「誰に委託するか」の切り替えです。システムそのものの構成変更を伴わないケースでも、移管先の選定・引き継ぎドキュメントの整備・並行稼働期間の設計が移管成否を大きく左右します。
なお、サーバー機器の更改（リプレイス）や基幹システムのクラウド移行は、それぞれ別のテーマです。サーバーリプレイスについてはサーバーリプレイス外注の進め方を、基幹システムのクラウド移行費用については基幹システムクラウド移行費用の解説記事をご参照ください。
ベンダー移管委託の定義と対象範囲
ベンダー移管委託の対象となる業務は、システムの保守・運用全般です。具体的には、障害対応・問い合わせ受付・定期メンテナンス・バッチ監視・バージョンアップ対応などが含まれます。
移管の形態は大きく2種類あります。第一は「保守委託先の切り替え」で、システムそのものは変えずに運用を担う会社だけを切り替えます。第二は「開発会社が持っている権利・資産の引き渡しを伴う移管」で、ソースコードの著作権や設計書の所有権を整理した上で移管するケースです。契約形態によって後者の手続きは複雑になるため、契約書の確認が欠かせません。
サーバーリプレイス・クラウド移行との違い
ベンダー移管委託はしばしばサーバーリプレイスやクラウド移行と混同されますが、目的が異なります。サーバーリプレイスは老朽化したハードウェアを新しい機器に更改する作業で、インフラ更改が主眼です。クラウド移行はオンプレミス環境をクラウド基盤に移転することです。
ベンダー移管委託はあくまで「誰がシステムを保守・運用するか」の変更です。インフラやアプリの構成をそのままにしたまま委託先だけを切り替えるため、適切な引き継ぎ計画と期間設計が成否を決定します。
ベンダー移管を検討するタイミングと主な理由
ベンダー移管の検討が生じる背景には、いくつかの典型的なきっかけがあります。自社の状況と照らし合わせて移管の必要性を判断する際の参考にしてください。
現行ベンダーのサービス終了・品質低下
現行ベンダーが事業撤退・縮小・廃業を予告した場合、移管は選択ではなく必須の対応になります。IPA（情報処理推進機構）の「DX動向2025」では、レガシーシステムを維持し続けるリスクとして保守人材の枯渇が指摘されており*1、IT業界全体で保守ベンダーの事業継続リスクは顕在化しています。
また、担当エンジニアの退職・異動により対応品質が低下したケース、SLA（サービスレベルアグリーメント）未達が続くケースも移管検討のきっかけになります。
技術スタックのミスマッチ
現行ベンダーがクラウドサービスやモダンな開発環境への対応を持っていない場合、システム改善・機能追加のたびに外部調達が必要になります。自社システムがクラウド化・API連携化を進める段階に入ったとき、それに対応できる別ベンダーへの移管を検討するケースが増えています。
コスト・体制の見直し
保守費用の見直しや、内製化推進・アウトソーシング戦略の変更といった経営判断が移管につながることもあります。現行ベンダーとの契約内容が実態と乖離している場合や、スコープの変更が必要な場合も、移管・再委託の契機です。
引き継ぎ計画の立て方：移管フェーズと必要ドキュメント
ベンダー移管の失敗の多くは、計画フェーズの設計不足から生じます。移管開始前に全体の工程と必要な成果物を確認しておくことが大切です。
移管フェーズの分解
移管は「移管計画→資料引き継ぎ→知識移転→並行稼働→切替完了」の5フェーズで進めます（図1参照）。各フェーズの完了条件を契約や合意書に明文化しておくと、現行ベンダーとのトラブルを防ぎやすくなります。
移管期間の目安はシステムの複雑度により大きく異なります。小規模なWebアプリケーションの保守移管では2〜3ヶ月程度が参考値ですが、複数システムが連携する基幹システムや24時間監視が必要なシステムでは6ヶ月以上の期間設計が望まれます（いずれも市場参考値・一次資料ではありません）。
現行ベンダーから取得すべきドキュメント
移管先が引き継ぎを完了させるために必要なドキュメントを、現行ベンダーから取得します。契約終了前に以下を確認してください。
| カテゴリ | 取得すべきドキュメント | 優先度 |
|---|---|---|
| 設計・仕様 | システム設計書（基本設計・詳細設計）、DB定義書、API仕様書、画面仕様書 | 高 |
| ソースコード・環境 | ソースコード一式（リポジトリ）、環境構築手順書、デプロイ手順書 | 高 |
| 運用・保守 | 運用手順書、障害対応手順書、バッチ管理表、監視設定一覧 | 高 |
| インフラ・ネットワーク | インフラ構成図、ネットワーク図、サーバー・クラウドのアカウント情報一覧 | 高 |
| 過去の変更履歴 | 変更管理台帳、インシデント記録、リリース履歴 | 中 |
| 契約・権利関係 | 著作権・ライセンス確認書、サードパーティ利用契約一覧 | 中 |
これらのドキュメントが現行ベンダー側に整備されていない場合、移管先が一から状況把握をする必要が生じます。その場合は移管期間の延長とコスト増加を想定した計画が必要です。
移管スケジュールの設計ポイント
移管スケジュールは、現行ベンダーとの契約終了日を起点に逆算して設計します。切替日から少なくとも並行稼働期間（最低1ヶ月、推奨2〜3ヶ月）を確保してください。並行稼働期間を設けずに契約を打ち切ると、移管先が障害対応ノウハウを習得する前に本番運用を引き受けることになり、障害時の対応遅延リスクが高まります。
また、現行ベンダーへの移管協力を依頼するタイミングは早いほど良いです。契約終了の告知後では、協力が得られにくくなる場合があります。
ベンダー移管のリスクと失敗パターン3つ
ベンダー移管の実務では、事前に手を打てば回避できるリスクが集中しています。過去の移管プロジェクトで繰り返し発生する失敗パターンを3つ整理します。
失敗1：ドキュメント未整備で移管先が全容把握できず運用が止まる
現行ベンダーの保守がノウハウの属人化で成立していた場合、引き継ぎに必要なドキュメントが存在しないことがあります。移管先が設計書や手順書なしで保守を始めると、障害発生時に原因特定に時間がかかり、復旧が大幅に遅延するリスクがあります。
対策としては、移管計画フェーズで「ドキュメント取得チェックリスト」を作成し、現行ベンダーの協力義務として契約書に盛り込んでおくことが大切です。ドキュメントが存在しない場合は、現行ベンダーに作成を依頼するか、移管先が現行ベンダーにヒアリングしながら整備する「ドキュメント化作業」を移管工程に含めます。
失敗2：並行稼働期間が短すぎて切替直後に障害が連発する
コスト削減を優先するあまり、並行稼働期間をゼロまたは極端に短く設定すると、切替直後に移管先が経験したことのない障害に直面します。特に月末・年度末などの業務ピーク時期を並行稼働中に経験させておくことが、切替後の品質安定につながります。
内製で移管を管理する場合、並行稼働期間の設計と日程調整に習熟したプロジェクトマネージャーが必要です。PM経験者がいない状態では、この期間の設計を見誤るリスクがあります。
失敗3：現行ベンダーの契約終了と移管完了のタイミングがずれて空白期間が生じる
現行ベンダーとの契約終了日が移管完了より先に来てしまうと、誰も正式に保守を担当しない「空白期間」が生じます。この状態でシステム障害が発生すると、責任の所在が曖昧なまま対応が遅れます。
移管完了の確認条件を契約で定め、「移管が完了するまで現行ベンダーとの契約を延長する」という取り決めを事前に行うことが大切です。
ベンダー移管の費用相場
ベンダー移管にかかる費用は、移管対象のシステム規模・ドキュメント整備状況・並行稼働期間の長さによって大きく異なります。以下は市場参考値であり、一次資料に基づく数値ではありません。個々の案件では見積もりを取得して確認してください。
費用を構成する要素
移管費用は大きく3つの要素から構成されます。第一は「移管作業費」で、資料整理・引き継ぎ対応・環境構築などの工数です。第二は「並行稼働費」で、旧ベンダーと新ベンダーが同時に稼働する期間のコストです。第三は「移管後の保守委託費」で、移管完了後の月次保守コストです。
一般に、移管元ベンダーが協力的でドキュメントが整備されている場合は移管作業費が抑えられます。一方、ドキュメントが未整備で現行ベンダーが協力に消極的な場合は、移管先が状況把握のために多くの工数をかける必要があり、費用が増加します。
規模別の費用参考レンジ（市場参考値）
| システム規模の目安 | 移管作業費の参考レンジ | 並行稼働期間の目安 |
|---|---|---|
| 小規模（Webアプリ・社内ツール単体） | 50万〜150万円程度 | 1〜2ヶ月 |
| 中規模（複数機能・連携APIあり） | 150万〜500万円程度 | 2〜4ヶ月 |
| 大規模（基幹システム・24時間監視） | 500万〜2,000万円以上 | 3〜6ヶ月以上 |
※上表の数値は市場参考値であり、一次資料に基づく統計値ではありません。実際の費用は案件の条件により大きく変動します。複数ベンダーに見積もりを依頼して比較することを推奨します。
費用を抑えるポイント
移管費用を適切に抑えるポイントは3点あります。まず、現行ベンダーとの契約にドキュメント整備義務を盛り込み、移管前に設計書・手順書を整備しておくことです。これにより移管先の状況把握コストを削減できます。
次に、移管範囲を段階的に設定して一度に移管するシステム数を絞ることです。全システムを同時に移管しようとすると、並行稼働期間の調整が複雑になり、工数が増加します。最後に、移管先に移管実績のあるベンダーを選ぶことです。移管経験が豊富なベンダーは引き継ぎのプロセスが確立されており、余分な工数が発生しにくくなります。
移管先ベンダーの選び方：確認すべき5つのポイント
移管先の選定は、移管の成否を左右する大切な判断です。保守・運用の技術力だけでなく、移管プロセスを支障なく進められる体制を持つかどうかを確認する必要があります。
確認ポイント1：移管実績と対応技術スタック
過去に類似システムの移管を担当した実績があるかを確認します。実績がある場合は、どのような規模・技術スタックのシステムを引き継いだかを具体的に聞いてください。自社システムの技術（言語・フレームワーク・インフラ）に対応できるエンジニアが在籍しているかは、移管後の運用品質に直結します。
確認ポイント2：ドキュメント作成・整備能力
移管元のドキュメントが不完全な場合、移管先がドキュメント化作業を担うケースがあります。引き継ぎ時の資料整備能力、および運用開始後の継続的なドキュメント更新体制があるかを確認してください。ドキュメントが整備されていると、将来さらに別のベンダーに移管する際のコストも削減できます。
確認ポイント3：並行稼働サポートの体制
並行稼働期間中に旧ベンダーとの調整窓口を担ってもらえるか、また並行稼働中に発生した問題を迅速にエスカレーションする体制があるかを確認します。並行稼働の経験が乏しいベンダーは、切替直後に問題が集中した際の対応が遅れるリスクがあります。
確認ポイント4：契約形態の柔軟性
移管作業費（初期費用）と移管後の保守委託費（月次費用）を分けて見積もれるかを確認します。移管作業の工数が変動した際に追加費用が発生する条件や、スコープ変更時の対応方針も事前に合意しておくことが大切です。
確認ポイント5：セキュリティ・情報管理の体制
移管作業中は、設計書・ソースコード・本番データへのアクセスが発生します。情報セキュリティ管理体制（ISMSや同等の管理基準）、NDA（秘密保持契約）の対応、アクセスログの管理方針を確認してください。移管プロセスが完了した後のデータの返却・廃棄手順についても事前に取り決めることを推奨します。
LASSICへの移管委託：元請としての対応体制
LASSICは、システムの保守・運用を元請（プライムベンダー）として受託し、移管プロジェクトの計画から切替完了まで一括でサポートします。移管作業に必要な引き継ぎ計画の策定、ドキュメント整備支援、並行稼働期間の管理、切替後の安定稼働体制の構築まで対応します。
移管に必要なエンジニアのスキルセット（インフラ・バックエンド・運用設計）を社内で調達できる体制を整えており、移管後の保守委託もそのまま継続できます。移管と保守を同一ベンダーが担うことで、引き継ぎ品質と運用品質の両方を一貫して管理できます。
必要スキルと工数の観点では、ベンダー移管を内製で進める場合、プロジェクトマネジメント・技術調査・引き継ぎ検証・セキュリティ管理・スケジュール管理のそれぞれに習熟した担当者が必要です。経験豊富な外部パートナーに委託することで、移管リスクを抑えながら情報システム部門の工数負担を軽減できます。
まとめ：ベンダー移管委託を成功させる3つの判断軸
本稿では、ベンダー移管委託の定義・フェーズ・リスク・費用相場・移管先選定のポイントを整理しました。要点を3つに集約すると次の通りです。
第一に、移管は「ドキュメント取得→知識移転→並行稼働→切替完了」の段階を省略しないことが基本です。特に並行稼働期間の確保が切替後の障害リスクを大きく左右します。第二に、移管費用はシステムの規模とドキュメント整備状況によって変動するため、移管前に現行ベンダーとのドキュメント整備合意を取っておくことがコスト管理に直結します。第三に、移管先の選定では技術適合性だけでなく、移管プロセスの実績・ドキュメント整備能力・並行稼働サポート体制を総合的に確認することが大切です。
よくある質問
ベンダー移管を進めるのに適した時期はいつですか？
システムの利用が比較的少ない閑散期が適しています。月末・年度末・繁忙期は業務量が増えるため、この時期に切替完了が重なると移管先の対応が追い付かないリスクがあります。移管開始から切替完了まで最低でも3〜6ヶ月のリードタイムを確保し、切替日は業務ピークを避けて設定することをおすすめします。
現行ベンダーが移管に協力してくれない場合はどうすればよいですか？
まず、現行ベンダーとの契約書にドキュメント提供義務や移管協力義務が記載されているかを確認します。契約書に明記されている場合は書面で協力を要請します。記載がない場合でも、合理的な範囲でのドキュメント提供を求めることができます。移管先ベンダーが独自にソースコードを解析してドキュメント化する「リバース調査」という方法もありますが、工数と費用が増加します。次回以降の保守委託契約では、移管協力義務と著作権の扱いをあらかじめ盛り込んでおくことが重要です。
ベンダー移管にかかる期間はどのくらいですか？
システムの規模や複雑度によって異なりますが、小規模システムで2〜3ヶ月、複数のシステムが連携する中規模以上では3〜6ヶ月以上が参考値です（市場参考値・一次資料ではありません）。ドキュメントが整備されていない場合や、現行ベンダーの協力が得にくい場合はさらに延長が必要になります。計画段階でバッファを設けた工程表を作成し、現行ベンダーとの契約終了日と切替予定日の両方を管理することが大切です。
ソースコードの著作権はどう扱えばよいですか？
一般に、受託開発で作成されたソフトウェアの著作権は、契約で明示的に移転を定めていない限り開発会社（受託側）に帰属することが多く、委託者（発注元）が当然に著作権を持つわけではありません。移管に際しては、現行ベンダーとの契約書で著作権の帰属と利用許諾の範囲を確認し、必要に応じて著作権譲渡の合意書を別途締結することをおすすめします。法的判断が必要な場合はIT専門の弁護士への相談も選択肢の一つです。
保守委託先の移管とシステムのクラウド移行は同時に進めても良いですか？
一般的には推奨されません。ベンダー移管とクラウド移行を同時に進めると、トラブル発生時の原因切り分けが困難になります。まずベンダー移管を完了させ、新しい保守体制が安定稼働してから、クラウド移行プロジェクトを別途立ち上げるアプローチが、リスク管理の観点から望まれます。クラウド移行の詳細については基幹システムのクラウド移行費用の解説もご参照ください。
著者：テレリモ総研編集部 鈴木 亮佑
ご不明な点はお問い合わせフォームからもご連絡いただけます。
- *1 出典：独立行政法人情報処理推進機構（IPA）「DX動向2025」（2025年）
