業務システムの保守を別の会社に引き継ぐには？費用相場と移管の進め方

保守を別の会社に引き継ぐ、いわゆる保守移管は、業界の慣行としては成立しています。けれど、経営者・情シス担当者の立場で見ると、判断材料がそろっていません。費用はいくらかかるのか、何か月かかるのか、仕様書が残っていなくても引き受けてもらえるのか、そもそも何から動き出せばよいのか。請求書の金額を眺めながら、動きたいのに動けない、という相談がよくあります。

保守を別の会社に引き継ぐとは何か

「保守を別の会社に引き継ぐ」と一口に言っても、現場で起きていることは1つではありません。次の3つが同時に入れ替わるのが一般的です。

契約: 今のベンダーとの保守契約を解約し、新しい会社と保守契約を結ぶ
主体: 改修・障害対応・問い合わせ窓口を引き受ける会社が変わる
体制: ソースコード・サーバー権限・運用ドキュメントの管理が、新しい体制に移る

このうち、契約だけを切り替えて主体と体制が残っていない、というケースが一番こじれます。たとえば「来月から新しい会社に保守をお願いします」と決めたものの、ソースコードがまだ前のベンダーの手元にあって受け渡しが進まない、サーバーの管理者権限が引き渡されていない、というパターンです。契約上は新会社に切り替わったのに、何かあったとき手が出せない期間ができてしまいます。

業界では、こうした引き継ぎ全体を保守移管と呼ぶことが多く、開発会社の解説記事でも「現状調査 → 提案・合意 → 並走 → 完全移管」といった4〜5段階で語られます（参考: NOVEL株式会社「保守移管とは？システムの運用・保守を引き継ぐ方法と費用をプロが解説」（2025年4月公表））。

つまり保守移管は、「契約書を書き換えれば終わり」ではなく、契約・主体・体制の3つを段階的に揃え直していく作業です。この前提を持っておくと、後の費用と期間の話がそのまま腹落ちします。

なぜ今、保守の引き継ぎを考える会社が増えているのか

ご相談いただく動機は、ざっくり3パターンに分かれます。

1つ目は、今のベンダーとの連絡が取りづらくなったケースです。電話やメールへの返信が以前より遅くなった、担当者が頻繁に替わるようになった、見積もりが返ってこない、といった兆候があります。ベンダー側の人員縮小や事業整理の初期信号であることも多く、放っておくと「気づいたら連絡先が変わっていて連絡が取れない」というところまで進みます。連絡が取りづらくなった段階での備えはベンダーと連絡が取りづらいときの3つの備えに書きました。

2つ目は、保守費の上昇と説明不足です。年に一度の更新ごとに月額が少しずつ上がっていく、内訳を聞いても「全部込みです」としか返ってこない、軽微な改修にも別途見積もりが必要になる。値上げ自体に必ずしも悪意はなく、技術者の単価上昇や、長く保守してきたシステム特有の事情が背景にあることも多いのですが、説明されないまま金額だけが動くと、発注者側は判断のしようがありません。

3つ目は、システムの寿命と新しい打ち手のずれです。保守の必要性そのものを再点検したくなる場面で、たとえば「いつまで現行システムを延命させるか、どこかでリプレースに踏み込むか」を考え直すフェーズです。ここはそもそも保守を放置すると何が起きるかを整理しておく必要のある領域になります。

これらは別々の動機に見えて、根っこは1つです。経済産業省が2018年に公表したDXレポートでも、ベンダーがいなければシステムの修正もデータの取り出しもできないベンダーロックインの構造が、日本企業の構造的な課題として指摘されています（出典: 経済産業省「DXレポート〜ITシステム『2025年の崖』克服とDXの本格的な展開〜」）。今のベンダーしか中身を知らない状態を放置したまま時間だけが経過すると、上の3つの動機はいずれも「引き継ぎたいのに引き継げない」という袋小路に変わります。引き継ぎを考えるタイミングは、困りごとが顕在化した「今」が早い、と言える理由がここにあります。

移管の費用相場――初期費用・月額・隠れコスト

保守移管の費用は、「初期費用」「月額の保守費」「隠れコスト」の3層に分けて見ると整理しやすくなります。1つの数字だけで語ろうとすると、必ずどこかがずれます。

初期費用（移行支援費）

新しい会社が現行システムを引き取るために最初にかかる費用です。ドキュメントの読み込み、ソースコードの解析、サーバー環境の確認、受け入れテスト、運用手順のすり合わせなど、引き取り側が「動かせる状態」を作るためのコストが入ります。

公表されている目安としては、たとえば名古屋・東京・福岡のシースリーインデックス株式会社は、新ベンダーへのドキュメント引き継ぎ・受け入れテスト費用について「通常1〜3か月分の保守費相当」を移行支援費の目安として示しています（出典: シースリーインデックス「システム保守費用の相場｜開発費の15〜20%・年50〜800万円が目安、妥当性5項目と削減策【2026年版】」（2024年2月公表・2026年5月更新））。また、秋霜堂株式会社は「外部委託への移管調査」の費用感として30〜100万円程度を示しています（出典: 秋霜堂「システム引き継ぎの方法・手順・費用ガイド｜他社開発システムの移管を成功させる」（2026年5月公表））。

幅があるのは、システムの規模、ドキュメントの残り具合、技術スタックの古さで必要な工数が大きく変わるためです。あくまで目安で、ドキュメントが残っていない・10年以上前の技術で書かれている、といった条件が重なると上限を超えることもあります。

月額の保守費

引き継ぎ後の継続料金になります。業界では年間保守費を「初期開発費の何%」で示す表現が一般的で、たとえば前掲のシースリーインデックスは「開発費の15〜20%」、ミンシスは「導入費用の10〜15%程度が年間の相場」と紹介しています（出典: ミンシス「システム保守費用が高すぎる?適正価格とコスト削減の実践ガイド」（2025年9月公表））。両者を合わせると、おおむね**年間保守費＝開発費の10〜20%**あたりが、業界で語られている参考線です。

ただし、この参考線は契約に含まれる範囲（24時間対応か業務時間内か、改修工数を月何時間まで含むかなど）で大きく振れます。月額の妥当性をどう判断するかは、保守費の内訳と打ち手の見直し方に書きました。

また料金モデル自体も、月額固定（定額制）と実働ベース（従量課金）の2系統に分かれます。年間の依頼量が読めない中小規模のシステムでは、固定費を背負わない実働ベースが合うこともあります。詳しい料金モデルの選び分けも参考になります。

隠れコスト

3層目は、見積書に並ばないが現実には発生する費用です。ここを甘く見ると、「思っていたより高くついた」になります。

現行ベンダーへの引き継ぎ協力費: ソースコード・設計書の引き渡し、技術的な質疑応答への対応料金。契約書に成果物の帰属が明記されていない場合、別途買い取り費用が発生することがあります。
並走期間中の二重保守費: 新旧両方のベンダーに料金を払う期間が、通常1〜2か月発生します。
解約予告期間内の保守費: 契約により異なりますが、解約予告から実際の解約までに3か月から6か月の期間を置く契約が一般的で、その間も保守費は払い続けることになります。
ドキュメント整備費: ドキュメントが揃っていない場合、新ベンダー側で動かしながら整備する工数が乗ります。

なお、保守移管を一気に切り替えるのではなく、まず限定的な改修案件をスポット（実働ベース）で別会社に依頼してみる、という慎重な進め方もあります。弊社のシステムレスキューでは保守料金を月額固定ではなく実働ベースとしており、移管に踏み切る前の「お試し依頼」も受け付けられる前提で設計しています。月額固定での全面切り替えにいきなり踏み込まずに済む、という観点で参考にしていただければと思います。

引き継ぎの流れと期間の目安

保守移管は、おおまかに次の4ステップで進みます。中小規模の業務システムなら、全体で2〜4か月が目安です（システムの複雑さやドキュメントの残り具合で前後します）。

ステップ1: 現状調査（2〜4週間）

新しい会社が、現行システムの状態を把握する段階です。ソースコードを読み、設計書があれば突き合わせ、サーバー構成を確認し、現行ベンダーが対応している作業の一覧を把握します。

ここでの目的は、「引き受けられるか」「引き受けるとして、どこに工数がかかるか」を判定することです。多くの場合、見積もりはこのステップの結果を踏まえて出てきます。逆に、現状調査をスキップして見積もりを出す会社は、後で追加費用が発生しやすいので注意します。仕様書が残っていないケースの対処は現場で使える4ステップで扱いました。

ステップ2: 契約・体制設計（2〜4週間）

調査結果を踏まえて、新しい契約を結びます。月額か実働ベースか、対応範囲はどこまでか、SLAはどの水準か、緊急時の連絡経路はどうするか。同時並行で、現行ベンダーへの解約予告も進めます。

ここで決めておきたいのは、「並走期間」をどう設計するかです。新旧両方のベンダーが動いている期間を1〜2か月設けて、その間に質疑応答とドキュメント引き渡しを進めます。並走期間をゼロにしてしまうと、いざ移管後に「これだけは前のベンダーに聞かないと分からない」が出てきたとき、もう聞けない状態になります。

ステップ3: 並走・引き渡し（1〜2か月）

実際の業務を回しながら、新ベンダーが対応を引き取っていきます。最初の数週間は、新ベンダーが質問する側、旧ベンダーが答える側になります。徐々に新ベンダーが一次対応を引き受けていき、旧ベンダーは後ろに下がります。

このステップで、ドキュメントが残っていなかった部分を新ベンダー側で整備していくのが一般的です。完璧な仕様書が出来上がるわけではありませんが、最低限の運用手順・障害時の対応フロー・主要モジュールの構造把握は、ここで形になります。

ステップ4: 完全移管（1〜2週間）

旧ベンダーが手を引き、新ベンダー単独の体制に切り替わります。サーバー権限の引き渡し、各種アカウントの整理、緊急連絡先の更新、利用者への周知。形式的な手続きが中心ですが、抜け漏れが起きやすいのもこの段階です。

完全移管後にすぐ大きな改修を予定している場合は、移管完了から1か月程度はクッションを置き、新ベンダーがシステムに馴染んでから改修に入るほうが安全です。なお、本格的な月額契約を結ぶ前に、まずは限定的な依頼で相性を確かめたい場合、スポット（実働ベース）で1件試すという順序も取れます。

引き取り先をどう見極めるか

引き継ぎ先の会社をどう選ぶかは、保守移管の成否を大きく左右します。判断軸は次のあたりに集約されます。

仕様書がなくても受けてくれるか

中小企業の業務システムでは、仕様書が残っていないか、残っていても更新されていないことがほとんどです。完璧なドキュメントを前提に話を進める会社は、引き取った後で「これでは引き受けられない」となるリスクがあります。実物のソースコードと動作するシステムから状態を把握できるかが、最初の関門になります。

古い技術スタックに対応できるか

10年以上前のPHP、サポート切れのフレームワーク、現役で使われなくなった言語。こうした技術への対応経験があるかどうかで、引き受け可否が分かれます。会社のサイトに「最新技術」しか書かれていない場合、レガシー対応は実は手薄、ということもあります。

リプレース一択で話を進めてこないか

引き取り相談に対して、現行の保守を引き取る選択肢を提示せず、最初から全面リプレース提案だけが返ってくる場合、判断を一度保留します。リプレースが本当に最善の選択肢になることもありますが、それは現状調査の結果として出てくるべきもので、入口の段階で一択になるのは不自然です。

料金モデルが実態に合っているか

月額固定が合うシステムもあれば、依頼量が少なくて実働ベースが合うシステムもあります。会社側が「うちは月額固定のみ」となっていると、自社の使い方に合わせた選択肢が初めから狭まります。料金モデルの観点での選び方は、社内SEが退職したときの選び方に書きました。

引き継ぎの実体制が示されているか

保守移管は数か月かけて進める作業になります。「引き受けます」と言いつつ、実際の担当者・体制・並走期間の設計が出てこない会社は、契約後に手戻りが多くなります。提案段階で、誰がいつ何をやるかの工程が示されているかを確認します。

相談前に手元で揃えたい資料

引き取り先の会社に相談する前に、自社で揃えておきたい資料があります。完全に揃っていなくても構いません。「揃っていない」という状態を把握しておくことが、相談を前に進めます。

1. 現行契約書

今のベンダーとの契約書を取り寄せます。確認したい箇所は次の3つです。

契約期間と解約予告期間（多くは3か月から6か月前の予告が必要）
開発成果物（ソースコード・設計書・データベース構造）の帰属
SLA（応答時間・復旧時間・稼働率）

成果物の帰属が「ベンダー」となっていると、新会社への引き渡しに別途費用が発生することがあります。解約予告期間は逆算して動かないと、引き継ぎ完了までの時間軸が伸びます。

2. 月次レポート・請求書（直近1年分）

毎月どんな対応を受けてきたかが分かる資料です。請求書だけでなく、対応一覧（チケット番号・内容・工数）が出ていればなお良いです。これがないと、新ベンダー側は「実際にどれくらいの依頼量があるシステムなのか」を読み切れず、見積もりが安全側に振れて高くなります。

3. システム構成情報

サーバー、ドメイン、SSL証明書、外部サービス（メール送信、決済、地図APIなど）、データベース、バックアップ先。何が、どこで、どんな契約で動いているかの一覧です。請求書を当たれば、何にいくら払っているかから逆算してリストを作れます。

4. 利用者からの問い合わせ履歴

社内の利用者から、過去にどんな問い合わせ・要望が出ているか。エクセル1枚でも構いません。これがあると、新ベンダー側は「実際にユーザーが困っているポイント」を引き取り直後に把握できます。

この4点は、保守費の妥当性を見るときにも同じ材料が使えます。完璧に揃わなくても問題ありません。「契約書はあるが月次レポートは出ていない」「サーバー情報の一部が分からない」といった現状を、そのまま新ベンダーに見せるところから始められます。

保守移管でつまずきやすい場面

解約予告のタイミングを間違える

「新しい会社が見つかったので、来月から切り替えたい」という相談で一番多いのが、現行契約の解約予告期間を見落としているケースです。3か月前予告の契約なら、今日決めても解約は3か月後。その間も今のベンダーに保守費を払い続けることになります。

新旧の並走期間と解約予告期間を重ねて設計すると、二重保守費を最小限に抑えられます。逆に、解約予告だけ先に出してしまって新ベンダーが決まらない、というのは最も避けたい順序になります。動き出すなら、引き取り先の目処をつけてから解約予告を出す、が原則です。

ソースコードの引き渡しが滞る

契約上は新会社に切り替わったのに、ソースコードが現行ベンダーから渡されない、というケースです。背景は様々で、契約書に成果物の帰属が明記されていない、過去の改修分の納品書が散逸している、現行ベンダー側の人員都合で渡す作業に手が回らない、など。

対策は2つです。1つは、解約予告と同時に「成果物の引き渡し期日」を文書で確認すること。もう1つは、ソースコードだけでなく、サーバー上の動いている資産（実行環境・データベース・各種アカウント）も引き渡し対象に含めることです。

「引き継いだら全部直せる」と期待しすぎる

新しい会社に引き継いだ瞬間に、長年の不満が全部解消すると期待してしまうケースです。実際には、新ベンダーは引き取り直後はシステムを把握しきれていません。最初の1〜2か月は、対応速度がむしろ一時的に落ちることもあります。

これは新ベンダーの力量の問題ではなく、保守移管の構造上やむを得ない期間になります。期待値を「引き継いだ直後はゆっくり、3か月目から普段の速度、半年後から改善提案が出てくる」くらいに置いておくと、関係がこじれずに済みます。引き継いだ後に「やっぱりリプレースしたい」と考えるなら、それは半年ほど経って新ベンダーがシステムを把握してから判断するほうが、見積もりも提案も筋が良くなります。リプレース提案の妥当性をどう見るかは、リプレース見積もりの3つの基準に整理しました。

なお、月額固定契約をいきなり結ぶことに不安が残るなら、まずスポット（実働ベース）で1件依頼してから、相性を見て月額契約に進む、という段階を踏むこともできます。保守移管そのものに踏み込む前の選択肢として、頭の片隅に置いておくと選択肢が広がります。

まとめ

業務システムの保守を別の会社に引き継ぐとき、押さえておきたいのは次の3点です。

保守移管は契約・主体・体制の3つが入れ替わる作業で、契約だけを切り替えても主体と体制が伴わなければ機能しません。
費用は初期費用・月額・隠れコストの3層で見ます。初期費用は1〜3か月分の保守費相当〜数十〜数百万円、月額は開発費の10〜20%、隠れコストとして並走期間中の二重保守費と解約予告期間の保守費が乗ります。
期間は中小規模で2〜4か月が目安です。現状調査・契約・並走・完全移管の4ステップで、解約予告期間と並走期間を重ねて設計します。

引き取り先を選ぶときは、仕様書がなくても受けてくれるか、古い技術に対応できるか、リプレース一択で話を進めてこないか、料金モデルが実態に合っているか、引き継ぎの実体制が示されているか、で見ると判断がぶれにくくなります。手元では契約書・月次レポート・システム構成情報・問い合わせ履歴を揃えて、完璧でなくても現状を見せられる状態にしておく。

保守移管は、決して特別な手続きではありません。早めに動き出して、解約予告期間と並走期間を逆算して設計すれば、無理なく進められる作業です。動きたいのに動けない、という状態が続いているなら、最初の現状調査だけでも、第三者の目を入れるところから始めてみてください。

業務システムの保守を別会社に引き継ぎたい、引き取り先の見当をつけたい、という方は、弊社の以下のサービスもご検討ください。

システムレスキュー

開発会社が廃業した、担当者が退職した、仕様書が残っていない。そんな業務システムを引き取り、保守・改修を継続します

/service/system-rescue/