データをエクスポートできるか、古参ベンダーからの乗り換え前に確認すべきこと

結論から言う。古参ベンダーとの契約を見直す、あるいは乗り換えを検討するなら、最初に確認すべきは「値段」でも「機能」でもない。「今使っているシステムの中にあるデータを、自社の手で外に取り出せるかどうか」である。これができないと分かった時点で、乗り換えの選択肢は実質的に消える。値段交渉すら成立しなくなる。

こんな状態に思い当たる方に向けて書いている。先代の頃からの付き合いで、地元のIT会社や個人事業主に基幹システムや顧客管理を任せてきた。年間保守料は決して安くないが、「昔からのお付き合いだから」と払い続けてきた。最近になって、担当者の高齢化や会社の縮小、あるいは単に見積もりの高さが気になって、「そろそろ他も検討してみるか」と思い立った。ところが、いざ動こうとすると「データはどこにあるのか」「今の会社に何を聞けばいいのか」が分からず、身動きが取れずにいる。この記事は、まさにその段階にいる二代目・三代目の経営者のために、乗り換え検討の最初の一歩である「データエクスポート確認」の進め方をまとめたものである。

承継社長が直面する「相談先の空白」

事業承継では、株式の移転や登記の変更には税理士や司法書士という専門家が必ず付いている。先代からの引き継ぎ資料も整い、顧問弁護士がいれば契約書の見直しも進む。ところが、会社の日々の業務を回している基幹システムや顧客管理ソフト、受発注システムについては、相談できる専門家がいないことが多い。これは決して珍しいことではなく、多くの承継社長が同じ孤独感を抱えている。

先代が信頼していたベンダーの担当者は、先代の顔を立てて今も低姿勢で対応してくれる。しかし、その関係の内側で実際にどういうデータ形式でどこに情報が保存されているのか、契約上ベンダーにどこまでの義務があるのかは、誰も体系的に説明してくれない。結果として、「システムのことは長年やってもらっているベンダーに任せておけば大丈夫」という思考停止が続きやすい。

なぜ「エクスポートできるか」が最初の関門なのか

乗り換え検討というと、多くの経営者はまず新しいシステムの機能や価格を比較しようとする。しかし実務の順序としては逆である。今のシステムからデータを取り出せなければ、新しいシステムに何を入れても「顧客の来歴がない」「過去の受発注履歴が消える」という状態になり、業務が回らなくなる。

経済産業省が2025年5月にまとめた「レガシーシステムモダン化委員会総括レポート」では、既存システムからの移行にあたって事業に深刻な影響を及ぼす問題事例が近年も発生していると指摘されている。同レポートは、IT自律性の低下やベンダーロックインといった構造的な課題が、ユーザー企業とベンダーの双方で温存されやすいことを整理している（出典: IPA掲載 経済産業省レガシーシステムモダン化委員会総括レポート）。大企業のシステム刷新で起きている問題は、中小企業の受発注システムや顧客管理でも構造としては同じである。データが出せないシステムは、乗り換えの土台がないシステムということになる。

「移行の話をベンダーに切り出したら、急に見積もりが出てこなくなった」「データはうちの形式でしか出せません、と言われた」——このような相談は決して例外ではない。

ベンダーロックインが起きている兆候

まず自社が今どのくらいベンダーロックインの状態にあるかを確認する。以下のいずれかに当てはまるなら、その度合いは高い。

• 見積もりや契約書に「データ移行支援」や「データ抽出」という項目が一度も出てきたことがない
• 担当者に「他のシステムに移すとしたら」と聞くと、明確な回答が返ってこない、あるいは話をそらされる
• 顧客データや受発注データが、汎用的なCSVではなく、そのシステム専用の独自形式でしか保存されていないと言われている
• システムの操作方法や設定情報を記した資料が社内になく、すべてベンダーの頭の中にある
• 保守契約書に「データの提供」「引き渡し」に関する条文が存在しない

これらは一つでも当てはまれば、直ちに危険というわけではないが、乗り換えの交渉力が弱い状態にあることを意味する。

確認すべきこと1：エクスポート形式は「汎用」か「独自」か

最初に確認すべきは、データが標準的な形式で取り出せるかどうかである。具体的には次のような形式であれば、他システムへの移行がしやすい。

「エクスポート機能はあります」と言われても、それが「印刷用のPDFしか出ない」のであれば、実質的にデータの持ち出しはゼロに近い。確認するときは「CSVで、全項目を、全件出せますか」と具体的に聞くことが重要である。

確認すべきこと2：出てくる項目は「全部」か「一部」か

エクスポートができても、出てくる項目が一部に限られているケースがある。たとえば顧客リストは出せても、取引履歴や商品ごとの単価変更履歴、担当者とのやり取りメモといった付随情報が出てこない、という事態はよくある。

以下は確認しておくべき項目のリストである。

• 顧客・取引先の基本情報（社名、担当者名、連絡先、取引開始日など）
• 過去の受発注履歴・売上履歴（できれば全期間分）
• 価格・単価の変更履歴
• 見積書・請求書のPDFまたは元データ
• 添付ファイル（図面、契約書スキャンなど）
• マスタ設定（商品コード、部門コード、権限設定など）

これらをリスト化した上で、ベンダーに「このうちどれが、どの形式で出せるか」を一つずつ質問する。曖昧な返答が返ってくる項目があれば、それが移行時のリスクになる。

確認すべきこと3：エクスポートに費用と期間がかかるか

データを出せると言われても、それが有償作業であったり、数ヶ月かかると言われたりすることがある。特に長年放置されてきたシステムでは、ベンダー側も「久しく誰もやっていない作業」であるため、見積もりが高額になりがちである。

この段階で聞くべき質問は次の3つである。

1. データ抽出作業に費用は発生するか。発生する場合、いくらか
2. 作業にどのくらいの期間がかかるか
3. 作業は保守契約の範囲内か、追加契約が必要か

契約書上、保守契約の範囲に「データ提供義務」が明記されていない場合、ベンダーは追加費用を請求する権利を持つ。ここで揉めるケースが実際に多い。IPAが公開している「情報システム・モデル取引・契約書」でも、契約終了時の扱いについて個別に取り決める規定が置かれており、事前に条文がなければ交渉の余地が限られることが分かる（出典: IPA 情報システム・モデル取引・契約書）。

確認すべきこと4：契約書に「データ引き渡し条項」があるか

先代の頃に結ばれた契約書を、今一度読み返してみることを勧める。多くの中小企業では、契約書は締結時にファイリングされて以来、一度も見返されていない。承継のタイミングは、これを読み直す絶好の機会である。

確認すべき条文は次の通りである。

• 契約終了時・解約時に、保有データを何らかの形式で引き渡す義務があるか
• 引き渡しの形式（CSV等）や期限が明記されているか
• 引き渡しに際して追加費用が発生する旨の規定があるか
• データの著作権・利用権がどちらに帰属すると書かれているか

これらが一切書かれていない契約書は、実務上「ベンダーの善意に頼るしかない」契約であると理解しておく必要がある。善意に頼る状態こそが、ベンダーロックインの実質的な正体である。

「角を立てずに」確認する話し方

古参ベンダーとの関係は、先代の代からの付き合いであることが多く、担当者と経営者自身も長年顔を合わせてきた間柄であることが少なくない。ここで唐突に「乗り換えを検討しています」と切り出すと、関係がこじれ、以後の保守対応が悪化するリスクがある。角を立てずに確認するための言い回しの例を挙げる。

• 「事業承継のタイミングで、システムの棚卸しをしています。念のため教えてください」
• 「もし将来システムを変えることになった場合、今のデータはどう移行できますか」
• 「BCP（事業継続計画）の観点で、データのバックアップと取り出し方法を確認しておきたいです」

いずれも「今すぐ乗り換える」という前提を出さず、「確認のための確認」という体裁を取ることで、相手も防御的にならずに答えやすくなる。事業承継は、こうした棚卸しを行う自然な理由になる。

古参ベンダーが答えを渋る場合に何が起きているか

質問をしても曖昧な返答しか得られない場合、考えられる背景はいくつかある。一つは、単純に技術的にエクスポート機能を作り込んでいない、古いレガシーシステムであるケース。もう一つは、ベンダー側が意図的にデータを出したくない、つまり顧客の引き止めの手段として情報を握っているケースである。

前者であれば、ベンダー自身も困っている可能性が高く、協力的に代替策（データベースへの直接アクセス権限の一時提供など）を提案してくれることもある。後者であれば、今後の関係そのものを見直す材料になる。いずれにしても、この時点で「エクスポートできない」という事実そのものが、次にとるべき行動の判断材料になる。

エクスポートできないと分かったときの3つの選択肢

確認の結果、「今のシステムからはまとまった形でデータを出せない」と分かった場合、取れる選択肢は大きく3つに絞られる。

1. 現状維持を選び、対策を先送りする：ベンダーが稼働している限りは業務が回るため、当面はこのままでも良い。ただし担当者の高齢化や廃業のリスクは残る。
2. 手作業でのデータ移行を行う：画面の表示内容を目視で新システムに入力し直す、あるいは印刷したものをスキャンして保存する、という力仕事での移行。件数が少なければ現実的な選択肢になる。
3. 専門家を入れてデータベースから直接抽出する：システムの裏側にあるデータベースに直接アクセスし、技術者の手でデータを吸い出す方法。件数が多い場合や、業務上データの欠落が許容できない場合はこの方法が必要になる。

いずれを選ぶにしても、「エクスポートできない」という事実を先延ばしにせず、選択肢として認識しておくことが重要である。

EOL（サポート終了）が迫っているなら猶予はさらに短い

今使っているシステムが、OSやハードウェアのサポート終了時期が近い場合、猶予はさらに短くなる。サポートが切れたシステムは、故障時に修理する部品や技術者が確保できなくなり、最悪の場合はデータそのものにアクセスできなくなるリスクがある。

先に触れた経産省のレガシーシステムモダン化委員会のレポートでも、老朽化した既存システムの維持がDXを阻む要因として指摘されている。サポート終了が近いと分かっているなら、データエクスポートの確認は「いつかやること」ではなく「今すぐ確認すること」に位置づけを変える必要がある。

契約更新のタイミングは交渉の好機

保守契約の更新月が近づいているなら、それは交渉の好機である。更新の話し合いの中で、「今後の契約には、データ引き渡しに関する条項を追加してほしい」と申し出ることができる。これは乗り換えを前提とした要求ではなく、リスク管理として自然な要求であるため、多くのベンダーは受け入れやすい。

具体的には、次のような一文を保守契約に追加してもらうよう依頼するとよい。

「乙（ベンダー）は、本契約終了時または甲（発注者）の求めに応じ、甲が保有するデータを合理的な期間内に、CSV等の汎用形式で甲に提供するものとする」

このような条文が一つ入るだけで、将来の交渉力は大きく変わる。

社内に残すべき記録：システム管理台帳の第一歩

エクスポートの確認と並行して、今使っているシステムの情報を一枚の表にまとめておくことを勧める。これはシステム管理台帳の最も簡易な出発点になる。担当者が変わっても、次の代の経営者が同じ苦労をしないための備えである。

最低限、次の項目を記録しておく。

この表を作るだけで、複数のシステムを抱える会社であれば、どこから手を付けるべきかの優先順位が見えてくる。

乗り換え先を決める前に見積もりを取るべき理由

データエクスポートの確認が済んだら、次にすべきは「乗り換え先の見積もりを先に取る」ことである。多くの経営者は、乗り換え先の候補を決めてから移行を検討しようとするが、実際には移行コストが乗り換え先の選定を左右する。

移行にかかる費用や期間が明確になれば、それを踏まえて複数のベンダーから見積もりを取り、比較することができる。逆に、移行コストを見積もらずに新システムだけを比較すると、導入後に想定外の追加費用が発生し、結局は当初の予算を大きく超えることになる。

古いベンダーと決別するのではなく「共存」する選択も

ここまで乗り換えを前提とした話を進めてきたが、必ずしも古参ベンダーと完全に決別する必要はない。データのエクスポートが可能で、契約条件も明確であるなら、既存のシステムを維持しながら、新しい領域だけを別のベンダーやSaaSに任せる「共存」という選択も十分にありうる。

たとえば、基幹の在庫管理は今のベンダーに任せたまま、営業のメール配信やスケジュール管理だけを別のクラウドサービスに切り替える、といった形である。この場合でも、既存システムからのデータの出し入れができることが前提になる点は変わらない。

古参ベンダーへの敬意と、経営判断は別のもの

先代が長年築いてきた関係を、いきなり切ることに抵抗を感じる経営者は多い。その気持ち自体は自然なものであり、否定する必要はない。しかし、経営判断としてのシステムの選定と、人間関係としての敬意は、分けて考えることができる。

データのエクスポートを確認する行為は、ベンダーへの不信の表明ではなく、会社としての当然のリスク管理である。この視点を持つことで、担当者との関係を損なわずに、必要な確認を進めることができる。

確認作業は誰がやるべきか

社内にITに詳しい社員がいない場合、この確認作業を経営者自身が行う必要が出てくる。難しく感じるかもしれないが、聞くべき質問はここまで挙げてきたように具体的なものばかりであり、専門的な技術知識は必須ではない。

一方で、実際にデータベースから抽出する作業や、抽出したデータの中身を検証する作業は、技術的な知見が必要になる。この部分だけを外部の技術者やコンサルタントに依頼する、という切り分けも現実的な選択肢である。すべてを自分でやろうとせず、質問と交渉は自分で、技術的な実務は専門家に、という分担を意識するとよい。

エクスポート確認をきっかけに社内の情報共有を進める

データエクスポートの確認作業は、経営者一人で完結させるのではなく、実際にそのシステムを日常的に使っている社員を巻き込むことをすすめる。現場の社員は、経営者が気づかない使い方の癖や、システムのどの部分が実際に重要なデータを持っているかを把握している場合が多い。

たとえば、受発注システムを使っている営業担当者に「このシステムで一番困っていることは何か」と聞くと、「取引先ごとの過去のクレーム履歴が検索しにくい」といった具体的な課題が出てくることがある。こうした声は、エクスポートの優先順位を決める上でも重要な材料になる。経営者だけの視点で確認を進めると、実務上あまり使われていない項目にばかり注意が向き、本当に重要なデータの確認が漏れてしまうことがある。

見積もりを取る際に併せて確認しておきたいこと

乗り換え先の候補から見積もりを取る際は、価格だけでなく、次の点も併せて確認しておくと、移行後のトラブルを減らせる。

• 移行作業のうち、どこまでを新しいベンダーが担い、どこからが自社の作業になるか
• 移行期間中、旧システムと新システムを並行稼働できるか、それとも一気に切り替える必要があるか
• 移行後、旧システムのデータに不備が見つかった場合、どちらの責任で対応するか
• 契約書に、今回問題になったのと同じ「データ引き渡し条項」が、新しい契約にも入っているか

特に最後の点は見落とされがちである。今回苦労してデータを取り出せたとしても、次に乗り換える新しいベンダーとの契約に同じ条項がなければ、数年後に同じ問題を繰り返すことになる。乗り換えは、契約の書き方そのものを見直す機会でもある。

承継のタイミングだからこそできる整理

事業承継の直後は、経営者にとって業務量が最も多い時期の一つである。それでもこのタイミングでシステムの契約を見直すことには意味がある。先代から社長交代を機に「代替わりに伴う確認です」と切り出せば、ベンダー側も自然な手続きとして受け止めやすい。数年後に唐突に同じ質問をするより、承継直後の今が、実は最も角を立てずに動ける時期だとも言える。

また、承継直後は経営者自身が会社のあらゆる契約を洗い直している時期でもある。取引先との契約、リース契約、保険契約などを見直す作業の一部として、システムの契約も同じリストに加えてしまえば、特別なことをしているという印象を社内外に与えずに進められる。

複数ベンダーに分散させておくという発想

今回の確認作業を通じて、特定のベンダー1社にすべての基幹システムを委ねている状態のリスクを実感した経営者もいるかもしれない。乗り換え先を決める際に、あえて1社だけに全機能を任せるのではなく、業務ごとに複数のベンダーやサービスを併用するという発想を取り入れることも検討したい。

複数のベンダーに分散させることには、1社が経営不振や廃業に陥っても業務全体が止まらないという利点がある一方、管理する契約や窓口が増えるという負担も伴う。どちらが自社に合うかは、社内でシステムの管理に割ける人員や時間によって変わる。今回のようにデータエクスポートの確認を通じて「1社依存のリスク」を把握したことは、こうした選択を考える上での貴重な材料になる。

先代への説明の仕方

乗り換えや契約見直しを進める過程で、まだ会長職などで会社に関わっている先代に、どう説明するかを考えておく必要がある場合もある。先代が長年築いてきたベンダーとの関係に手を入れることに、先代自身が抵抗を感じることは十分にありうる。

この場合、「関係を切る」という表現ではなく、「会社を守るための確認をした結果、今後のリスクに備える必要が分かった」という説明の仕方をすすめる。先代自身も、会社が特定の相手に依存しすぎることのリスクは、経営者としての経験の中で理解しているはずである。感情的な対立を避け、事実に基づいた説明をすることで、先代の理解を得やすくなる。

見積もりの高さだけで判断しない

古参ベンダーからの乗り換えを考えるきっかけの多くは、単純に「保守料が高いと感じたから」であることが多い。しかし、見積もりの高さだけを理由に乗り換えを決めると、思わぬ落とし穴にはまることがある。

長年の付き合いがあるベンダーの保守料には、これまでの積み重ねてきた業務知識や、トラブル時の即応性といった、見積もり書には表れにくい価値が含まれていることがある。乗り換え先の新しいベンダーは、価格は安くても、自社の業務の細部を理解するまでに時間がかかり、当初は対応が遅くなる可能性がある。

だからこそ、価格の比較だけでなく、今回述べてきたデータエクスポートの可否や契約条件の確認をあわせて行い、「今のベンダーとの関係を維持したまま料金交渉をする」という選択肢も並べて検討することをすすめる。乗り換えの検討自体が、今のベンダーとの価格交渉における材料になることもある。データを出せるかどうかを聞かれた時点で、ベンダー側も「本気で他社を検討している」と理解し、これまで動かなかった価格や条件が動き出すことは実際にある。

今日からできる最初の一歩

ここまで多くの確認事項を挙げてきたが、すべてを一度に進める必要はない。今日、あるいは今週中にできる最初の一歩として、次のことから始めるとよい。

• 今使っている基幹システムのベンダーの担当者に連絡を取り、「事業承継に伴うシステムの棚卸しをしています」と伝える
• 「データをCSV形式で全件出せますか」という一問だけをまず聞いてみる
• 契約書のファイルを探し出し、更新月と解約通知の期限を確認する

この3つさえ済ませれば、自社が今どのくらいベンダーロックインの状態にあるかの見立てがつく。そこから先の判断は、見立てがついた後でゆっくり考えても遅くはない。焦って結論を出す必要はなく、まず現状を正確に知ることが、承継社長にとって最も価値のある投資になる。

複数のシステムがある場合はどれから確認すべきか

会社によっては、顧客管理、受発注、会計、勤怠管理など、複数のシステムがそれぞれ別のベンダーから提供されていることがある。すべてを同時に確認するのは現実的ではないため、優先順位をつける必要がある。

優先すべきは、次の条件に当てはまるシステムである。

• 契約更新月が近い（更新の交渉タイミングと重なるため効率がよい）
• 担当者が高齢、あるいは会社の規模が縮小している（サービス継続のリスクが高い）
• 導入から10年以上経過している（老朽化したシステムほど、サポート終了のリスクも高い）
• 会社の売上や顧客対応に直結する、最も重要なデータを持っている

複数のシステムを一枚の表にして、この4条件のうち当てはまる数が多いものから着手すると、限られた時間の中でも効率的にリスクを減らせる。逆に、どのシステムも同じ優先度で扱おうとすると、結局どれも手つかずのまま数年が過ぎてしまう。

データを取り出した後の保管方法

首尾よくデータをエクスポートできたとしても、それをどこに保管するかを決めておかなければ、せっかくの作業が無駄になる。多くの場合、エクスポートしたデータはCSVファイルとして担当者のパソコンに置かれたままになり、その担当者が異動や退職をした時点で行方が分からなくなる。

保管にあたっては、次の点を決めておくとよい。

1. 保管場所を個人のパソコンではなく、会社として管理するクラウドストレージやサーバーに統一する
2. ファイル名に取得日を入れ、いつの時点のデータかが分かるようにする
3. アクセス権限を持つ人を最低2名以上にし、1人しか開けない状態を避ける
4. 定期的に（半年〜1年に一度など）再度エクスポートを行い、データを更新する

エクスポートは一度やれば終わりというものではない。特に乗り換えを先送りにして現状維持を選ぶ場合は、定期的なエクスポートそのものが、いざという時のための保険になる。

経営者自身が全項目を理解する必要はない

ここまで多くの確認項目を挙げてきたが、経営者自身がシステムの技術的な詳細をすべて理解する必要はない。重要なのは、「何を確認すべきか」というチェックリストを持ち、それをベンダーや技術者に投げかけられる状態になることである。

株式や登記の承継であれば、経営者は税理士や司法書士に「何が必要か」を聞き、実務は専門家に任せる。システムについても同じ構造で考えればよい。経営者の役割は、確認すべき論点を把握し、交渉の場に立つことであり、データベースの構造を理解することではない。この線引きを持つだけで、システムに対する漠然とした不安は大きく軽減される。

乗り換えを決めた後、旧ベンダーとの契約終了はどう進めるか

データのエクスポートが確認でき、実際に乗り換えを決断した後は、旧ベンダーとの契約終了の手続きに入る。ここでも段取りを誤ると、思わぬトラブルにつながる。

まず、契約書に記載されている解約通知の期限を必ず確認する。多くの保守契約は自動更新の形を取っており、「契約終了の何ヶ月前までに通知しなければ、自動的にもう1年継続される」という条項が入っている。この期限を過ぎてから解約を申し出ると、望まない期間の費用を支払うことになる。承継後にまず契約書を読み直しておくべき理由の一つはここにもある。

次に、旧システムと新システムを同時に稼働させる「並行稼働期間」を設けるかどうかを決める。多くの場合、いきなり旧システムを止めて新システムに完全移行するのはリスクが高い。一定期間、両方を並行して動かし、データの整合性やオペレーションの慣れを確認してから旧システムを止める方が安全である。この並行稼働期間中の保守費用がどうなるかも、旧ベンダーとの契約終了の交渉に含めておく必要がある。

最後に、旧システムを完全に停止させる前に、念のため最終版のデータをもう一度エクスポートし、保管しておくことをすすめる。移行作業中に想定していなかった項目の必要性に気づくことは珍しくなく、旧システムを停止した後では手も足も出なくなる。

相談先がない孤独感への向き合い方

この記事の冒頭でも触れたように、承継社長の多くは「株式や登記には専門家がいるが、システムには相談先がいない」という孤独感を抱えている。この孤独感は、実は多くの承継社長が共有している感覚であり、決して自分だけが特別に知識不足だから生じているわけではない。

先代の時代は、システムのことをベンダーに一任し、経営者自身が中身を把握する必要がなかった。それが承継のタイミングで急に「自分で判断しなければならない」立場に置かれることで、この孤独感が生まれる。しかし、ここまで挙げてきた確認項目は、いずれも専門的な技術知識を必要とせず、「聞くべきことを知っている」だけで対応できるものばかりである。

もし社内や身近な相談先がどうしても見つからない場合は、地域の商工会議所や商工会が実施している経営相談窓口を利用することも一つの方法である。ITに関する相談を専門としているわけではなくとも、契約書の読み方や、次にどこへ相談すべきかの案内を受けられることがある。専門家が「いない」わけではなく、探し方が知られていないだけの場合が多い。

まとめ：最初の一歩は「聞くこと」

古参ベンダーからの乗り換えを検討する際、最初にすべきことは複雑な技術検証ではない。今のベンダーに対して、「データをCSV等の汎用形式で、全項目・全件、どのくらいの費用と期間で出せるか」を具体的に聞くことである。この一問への答えが明確に返ってくるかどうかで、その後の選択肢の幅がまったく変わってくる。

先代が築いた関係への敬意を保ちながらも、会社の将来を守るための確認は、承継した経営者自身の責任である。株や登記に専門家がいるのと同じように、システムについても「まず何を確認すべきか」を知っておくことが、孤独な判断を減らす一歩になる。

この記事の次に読みたい記事

• 高くなった先代契約のSaaSを乗り換え・縮小する選択肢
• 先代から引き継いだ基幹システムをリプレイスするときのデータ移行の落とし穴
• 脱ロックインの第一歩、承継後に自社で管理すべきアカウント一覧