システムの乗り換え・引き継ぎガイド｜開発会社を変えるときの進め方と注意点【2026年最新】

システムの乗り換え・引き継ぎとは

「開発会社を変える」と聞くと、システムを一から作り直すイメージを持つ方が多いのですが、実務ではそうとは限りません。むしろ、既存のシステムをそのまま引き継いで改修していくケースのほうが、費用も期間も抑えられることがよくあります。

乗り換えには3つのパターンがある

どのパターンになるかは、乗り換えを検討し始めた時点では決められません。まず現状を調べてから決めるのが正しい順序です。「今すぐ全部作り直しましょう」と最初の面談で言ってくる会社があれば、その根拠を丁寧に聞いてみてください。中身を見ずに判断できることはほとんどありません。

「保守だけ」を引き継ぐケースも多い

新規開発の必要はないが、日々の障害対応や小さな修正を頼める先がない——という相談は非常に多くあります。この場合は開発ではなくシステム保守の引き継ぎになります。保守の引き継ぎは開発より軽く済むことが多い一方、「何をどこまで見るのか」の範囲定義があいまいだと後で揉めます。詳しくはシステム運用保守の役割も参考にしてください。

「そろそろ乗り換えどき」7つのサイン

不満があってもなかなか踏み切れないのが、開発会社の変更です。感情ではなく事実で判断できるよう、実際に相談が寄せられる典型的なサインを挙げます。

1. レスポンスが遅い——問い合わせから初回返信まで、常に1週間以上かかる
2. 見積もりがブラックボックス——「一式」表記のみで、工数の内訳を尋ねても説明がない
3. 担当者の交代・退職——引き継いだ担当者が中身を把握しておらず、毎回調査費が発生する
4. 小さな修正が異常に高い——文言1箇所の変更に数十万円の見積もりが出る
5. 提案がなくなった——数年間、言われたことしかやらない状態が続いている
6. 技術が止まっている——サポートの切れたバージョンのまま放置され、更新の提案もない
7. 連絡が取れない期間がある——障害時に半日以上つながらないことがある

「壊れていないのに変える」判断は慎重に

システムが安定して動いており、年間の保守費も相場から大きく外れていないなら、乗り換えのメリットは小さくなります。判断のとき、次の3点を数字で確認してみてください。

※ 上記は一般的なモデルケースであり、成果を保証するものではありません。

乗り換え前に確保すべき5つの資産

ここが本記事で最も重要な部分です。契約を切る前に、次の5つを手元に確保してください。順番も重要です。契約解除を先に伝えてしまうと、相手の協力が得にくくなり、回収が難しくなることがあります。

① ソースコード

システムの設計図そのものです。これがないと、新しい会社は動いているプログラムを外から推測するしかなく、改修費が数倍に膨らみます。確認すべきは次の点です。

• ソースコードの全量があるか（本番環境で動いている最新版と一致しているか）
• バージョン管理（Git等）のリポジトリごと引き渡せるか。履歴があると調査が大幅に楽になる
• ビルド・デプロイに必要な設定ファイルや手順が含まれているか
• 外部サービスの接続情報（APIキー等）が誰の管理下にあるか

ソースコードは「ZIPで一式もらう」より「リポジトリのアクセス権をもらう」ほうが圧倒的に価値があります。過去の変更履歴は、なぜその実装になっているかを推測する手がかりになります。

② ドキュメント

完璧なドキュメントが残っている中小企業向けシステムは、正直に言えば多くありません。それでも、次のうち1つでもあれば引き継ぎの負担は大きく変わります。

• 画面一覧・機能一覧（何ができるシステムなのかの目次）
• データベースの構造（テーブル定義、ER図）
• 外部連携の仕様（どのサービスと、どのタイミングで通信しているか）
• 環境構成図（サーバ、ドメイン、証明書、バッチ処理の一覧）
• 過去の障害対応記録・改修履歴

なお、ドキュメントが一切ない場合でも引き継ぎは可能です。その場合は新しい会社が調査しながら作り直すことになり、その分の工数が乗ります。要件定義の進め方で触れている「現状の可視化」に近い作業になります。

③ ドメイン

意外に多いのが、ドメインが開発会社名義で登録されているケースです。この状態だと、乗り換え時にドメイン移管の協力が必要になり、関係がこじれていると事実上のカードになってしまいます。

④ サーバ・各種アカウントの管理権限

ドメインと同じ構図です。次のアカウントについて、自社が管理者（オーナー）になっているかを洗い出してください。

⑤ 著作権（利用・改変の権利）

開発したシステムのプログラム著作権が、発注側と開発側のどちらにあるかは契約書の定めによって変わります。何も書かれていない場合、一般的には制作した側に権利が残ると解釈されることが多く、「お金を払ったのだから当然こちらのもの」とは限りません。

ここで問題になるのは所有そのものより、「第三者に改変させてよいか」という点です。改変権について明記がないと、新しい会社が手を入れること自体に許諾が必要になる可能性があります。

※ 著作権に関する記述は2026年時点の一般的な情報です。個別の契約の解釈や最新の制度については、所管省庁の情報および弁護士等の専門家にご確認ください。

契約書で確認すべき4つの条項

資産の確認と並行して、現在の契約書を読み直します。中小企業のシステム開発契約では、そもそも契約書が存在しない、あるいは見積書と注文書だけというケースも珍しくありません。その場合は、次の内容をこれから合意し直すと考えてください。

解約通知期間の落とし穴

保守契約は年間自動更新になっていることが多く、「更新日の3か月前までに書面で通知」といった条件が入っている場合があります。気づいたときには次の1年が確定していた、というのはよくある話です。乗り換えを検討し始めた時点で、まず更新日と通知期限をカレンダーに書き込んでください。

「引き継ぎ協力義務」があるか

優れた契約書には、契約終了時にベンダーが引き継ぎに協力する旨（移行支援義務）が書かれています。これがあると、質疑応答や環境の引き渡しをスムーズに進められます。ない場合でも、多くの会社は良識的に対応してくれますが、協力は有償になる前提で費用を見ておくのが安全です。

ベンダーロックインの正体と回避策

ロックインが生まれる典型的な4つの経路

回避策は技術ではなく「運用ルール」で作る

ロックイン回避というと技術選定の話になりがちですが、中小企業が現実的にできる対策のほとんどは事務作業です。

• 名義は必ず自社——ドメイン、サーバ、外部サービスのオーナー権限は自社アカウントで取得し、開発会社は「招待して使ってもらう」形にする
• コードは自社リポジトリに置く——自社の組織アカウントを作り、そこに開発会社を招待する
• 納品時にドキュメントを条件にする——画面一覧・DB定義・環境構成図の3点セットを検収条件に入れる
• 年1回の棚卸し——契約更新のタイミングで、アカウント名義とドキュメントの最新性を点検する
• 一般的な技術を選ぶ——特別な理由がない限り、広く使われている言語・フレームワークを選定する

この5つを最初から守っていれば、乗り換えは「引っ越し」程度の作業になります。守っていなかった場合でも、今から整えれば次回以降のロックインは防げます。

引き継ぎ調査の進め方

資産と契約の状況が見えたら、次は引き継ぎ調査です。新しい会社に「このシステムを引き継げるか、いくらかかるか」を判断してもらう工程で、乗り換えの成否はほぼここで決まります。

調査を「先に、単独で」依頼する意味

いきなり「引き継いで改修してください」と依頼すると、相手はリスクを見積もりに載せざるを得ません。中身が分からないものを請ける以上、当然のことです。一方、調査だけを先に切り出せば、少額で現状を把握でき、その結果をもとに正確な見積もりを取れます。乗り換えを最終的にやめる判断をしても、損失は調査費だけで済みます。

※ 上記は一般的なモデルケースであり、成果を保証するものではありません。

調査で必ず確認しておきたい項目

• 使用している言語・フレームワークとそのバージョン、サポート期限
• 本番・検証環境の構成と、デプロイの手順が再現できるか
• データベースの規模とテーブル構造、命名の一貫性
• 外部サービス連携の一覧と、その認証情報の管理者
• バッチ処理・定期実行の存在（見落とされやすく、障害の温床になる）
• 個人情報を扱う箇所と、その保存・暗号化の状況
• テストコードの有無（あれば改修時の安全性が大きく変わる）

調査結果の3つの結論

調査が終わると、おおむね次の3つのいずれかの結論になります。

※ 上記は一般的なモデルケースであり、成果を保証するものではありません。実際の費用は規模・技術構成により大きく変動します。

改修で足りるか、作り直すべきか

調査結果を受けて判断するのがこの論点です。感覚ではなく、次の観点で切り分けます。

※ 上記は一般的なモデルケースであり、成果を保証するものではありません。

作り直しを選ぶべき明確なサイン

1. 言語・フレームワーク・OSのサポートが終了しており、セキュリティ更新が受けられない
2. 改修のたびに別の場所が壊れる（変更の影響範囲が読めない構造になっている）
3. そもそも今の業務と機能が合っておらず、手作業での補完が常態化している
4. データが壊れており、修正よりも設計し直すほうが早い
5. 利用者が増え、性能面で限界に達している

1つも当てはまらないなら、まずは引き継いで改修する方向で検討したほうが合理的です。判断の詳細はシステムリプレイスの考え方とスクラッチ・パッケージ・SaaSの比較もあわせてご覧ください。

既製サービスへの乗り換えという選択肢も検討する

正直にお伝えすると、独自開発したシステムの機能が、いまや既製のクラウドサービスで十分にまかなえるようになっているケースがあります。既製で足りるなら、既製を使うほうが安く確実です。次の場合は既製サービスへの移行を先に検討してください。

• やっていることが一般的な業務（勤怠・経費・請求・顧客管理など）で、自社独自の運用がほとんどない
• 利用人数が少なく、月額課金のほうが総額を抑えられる
• 法改正への対応を自社で追いたくない

逆に、自社独自の業務フローが競争力そのものになっている場合や、既製サービスに合わせて業務を変えると現場が回らない場合は、カスタム開発で引き継ぐ判断になります。この線引きは内製化と外注の判断基準の考え方とも重なります。

乗り換えの費用相場とスケジュール

乗り換えにかかる費用は「調査」「移行作業」「改修」「保守」の4つに分けて考えると見通しが立ちます。

※ 上記は一般的なモデルケースであり、成果を保証するものではありません。規模・技術構成・引き継ぎ資料の有無で大きく変わります。

より一般的な開発費の考え方はシステム開発の費用相場を、投資判断の組み立て方はシステム化の費用対効果（ROI）を参考にしてください。

費用を左右する4つの要因

スケジュールの標準的な流れ

1. 0〜2週目：現状の棚卸し（資産・契約・アカウント名義の確認）
2. 2〜4週目：新しい会社の選定、調査の依頼
3. 1〜2か月目：引き継ぎ調査の実施と方針決定
4. 2〜3か月目：現ベンダーへの通知、引き継ぎ日程の調整
5. 3〜5か月目：環境移行・並行稼働・初期改修
6. 5か月目以降：新体制での保守開始

解約通知期間が3か月の契約なら、通知のタイミングを逆算する必要があります。「調査結果が出るまで通知しない」のが原則ですが、更新日が迫っている場合は先に通知だけ出して期間を確保する判断もあり得ます。

事業を止めない段階移行の設計

乗り換えで最も怖いのは、切り替えの瞬間に業務が止まることです。これを避けるのが段階移行の考え方です。

3つの移行方式

移行当日までに決めておくこと

• 切り戻し条件——何が起きたら旧環境に戻すのかを、事前に文章で決めておく
• 連絡体制——移行当日、誰が誰に何分以内に連絡するか
• データの基準時刻——どの時点のデータを移すか、その間の入力をどう扱うか
• 現場への周知——ログイン方法やURLが変わる場合、事前に案内する
• 旧環境の保持期間——すぐに消さず、最低でも数か月は参照できる状態で残す

現ベンダーへの伝え方と失敗6パターン

技術より難しいのが、今の開発会社への伝え方です。感情的なやりとりになると、引き継ぎ協力が得られず、結局困るのは自社です。

伝えるときの3原則

1. 資産の確保を先に済ませる——ソースコード、ドキュメント、アカウント名義の確認を終えてから通知する
2. 理由は事実ベースで、責める言い方をしない——「対応が遅い」ではなく「社内の体制変更に伴い」で足りる場面は多い
3. 引き継ぎ協力を有償で正式に依頼する——タダで頼まない。見積もりを取り、作業として発注するほうが確実に進む

よくある失敗6パターン

次の開発会社を選ぶときの見極めポイント

• 他社が開発したシステムの引き継ぎ実績や、その進め方を説明できるか
• 調査だけを単独で請けてくれるか（いきなり全面作り直しを勧めてこないか）
• 見積もりの内訳を工数レベルで示せるか
• ドキュメントを納品物に含める提案をしてくるか
• アカウント名義を自社にする運用を勧めてくれるか
• 既製サービスで足りる場合に、そう言ってくれるか

会社選びの一般的な観点はシステム開発会社の選び方にまとめています。