保守会社から、OSのサポート終了の知らせが届いた。
添えられた見積書には「バージョンアップ一式」とある。
社長は、情報システムの担当者に聞きます。「これを払えば、あと何年もつのか」。
基幹システムの更新（アップデート）とは、いまのシステムを使い続けながら、版を上げたり修正を当てたりすることです。
乗り換え（リプレイス）は、別のシステムに移ることを指します。
更新が必要かどうかは、保守期限と業務の安定度でおおむね決まります。
- 保守期限に余裕があり、業務も安定しているなら、更新で延命が合理的
- 保守期限が近い、属人化している、事業が変わるなら、乗り換えを前向きに検討する段階
ただ、延命を選んだ会社にも、乗り換えを選んだ会社にも、同じ落とし穴があります。
それは何か。
この記事で分かること
- 更新で何が変わり、先送りすると何が起きるか
- 更新と乗り換えを分ける6つの物差し
- 乗り換え先の選び方と、費用と期間を左右する4つの要因
- 乗り換えで変わること、よくある失敗3つ
- 自社で1時間でできる、システムの棚卸し
更新で何が変わるのか
更新は、主に次の5つの目的で行われます。
| 目的 | 中身 | 先送りすると |
|---|---|---|
| 安定性・セキュリティ | 不具合の修正、脆弱性（セキュリティの弱点）の修正 | 攻撃や情報漏えいのリスクが上がる |
| 新機能・効率化 | データ分析・自動化などの機能追加 | 手作業が残り、時間とミスが増える |
| 他システムとの連携 | 受発注・会計などとのデータのやり取りを保つ | 二重入力や手作業の突合が増える |
| 保守・サポート | メーカーの保守期限（面倒を見てくれる期間）内にとどまる | トラブルを自社だけで解くことになる |
| 法規制への対応 | 制度の変更に合わせる | 個別の改修が増え、対応が遅れる |
「まだ動いているから大丈夫」。
そう先送りするほど、リスクは少しずつ積み上がります。
古い仕組みをだましだまし使うのは、見えにくいコストを払い続けることでもあります。
関連する論点は、基幹システムのセキュリティと、基幹システムが遅い・重いと感じたらで扱っています。
見直しを考えるべき「サイン」
次のサインが出ていたら、検討のタイミングです。
- 保守期限が近い・過ぎている：トラブル時にサポートを受けられない
- 動作が遅い・止まる：業務の効率と現場の負担に直結する
- 法改正に追いつかない：制度が変わるたびに手作業や改修が増える
- 連携が不安定：二重入力や手作業の突合が起きている
- 担当者しか中身が分からない：仕様書がなく、特定の人に頼っている
なかでも「保守期限切れ」と「担当者への依存」は、いざという時に業務を止めます。
保守期限の詳しいリスクは、基幹システムの保守切れリスクをご覧ください。
判断の物差し｜更新で延命か、乗り換えか
これは、IT部門の作業ではなく経営の判断です。
「守り」だけでなく、会社をどう前に進めるかの視点で見ると、道が分かれて見えてきます。
| 判断の観点 | 更新で延命が向く | 乗り換えが向く |
|---|---|---|
| 保守期限 | まだ十分に残っている | 期限切れ、または近い |
| 法・制度対応 | 標準の機能で対応できている | 個別の改修を重ねないと対応できない |
| 拡張の余地 | 大きな機能追加は当面不要 | 事業拡大・海外展開で拡張が必要 |
| 業務の属人化 | 運用のノウハウが社内で共有されている | 担当者しか中身が分からない |
| 成長計画 | 現状維持で当面問題ない | データ活用や業務改革を進めたい |
| AIの活用 | 当面は使う予定がない | データを1か所にそろえ、AIで点検・予測したい |
左側が多ければ、当面は更新で延命する選択も合理的です。
右側が多ければ、乗り換えを前向きに検討する段階に入っています。
AIの行は、これから差が開く観点です。
部門ごとにデータが分かれた古い仕組みでは、AIに渡せるデータがそろいません。
更新を重ねても、この構造は変わりにくいままです。
図の3つの問いに、すべて「はい」なら更新で延命できます。
1つでも「いいえ」があれば、乗り換えを並べて比べる段階です。
乗り換え先の選び方｜NetSuite以外が合う場合も
乗り換えると決めても、行き先は1つではありません。
| 自社の状況 | 合いやすい選択肢 |
|---|---|
| 会計・販売・在庫を1つにし、海外や子会社も見たい | NetSuiteなど統合型クラウドERP |
| 小規模で、必要な機能から段階的に始めたい | Odoo |
| 業種特有の業務（製番・生産方式など）が中心 | 業種に特化した国産ERP |
| 独自の業務が強みで、パッケージに合わない | AIを使ったスクラッチ開発 |
クラウドERPなら、自社でサーバーを保守する必要がなくなります。
その分の人手を、本来の仕事に振り向けられます。
NetSuiteでは、すべての顧客が同じ版を使い、年2回の自動アップデートを受けます（出典：Oracle NetSuite公式サイト、2026年9月確認）。
大きなリリースは、数か月かけて段階的に適用されます。
事前に、自社のデータで新しい版を試すRelease Preview用の環境も依頼できます（出典：Oracle NetSuiteヘルプ、2026年9月確認）。
「更新の時期を自社で決める」悩みは、ほぼなくなります。
それでも、追加した機能や連携が新しい版で動くかの検証は、年2回残ります。
備え方は、NetSuiteのバージョンアップへの備え方で扱っています。
NetSuiteは、世界220地域・44,000社以上で使われています（出典：Oracle NetSuite公式サイト、2026年9月時点）。
概要はNetSuiteとは、OdooはOdooとはをご覧ください。
スクラッチ開発との比べ方は、AIでスクラッチ開発とERP、どちらを選ぶべきかにあります。
費用と期間を左右する4つの要因
乗り換えの費用と期間は、行き先の製品名より、導入の中身で動きます。
ベンチャーネットが導入を支援してきた中で、差を生む要因は4つです。
- 機能範囲：どの業務まで新しい仕組みに載せるか
- 開発：追加の開発、とくに外部システムとの連携
- 社内の体制：情報システムの担当が少ないと、支援を厚くし期間も延びやすい
- ユーザー数：受入テスト・教育の工数と、社内の調整
延命の見積もりと比べるときも、この4つを並べて数年分の総額で見ます。
一度に全部を替えない選び方
更新か乗り換えかは、全社で一律に決める必要はありません。
業務ごとに、保守期限と課題の大きさが違うからです。
| 進め方 | 中身 | 向く場面 |
|---|---|---|
| 会計から先に替える | 会計をクラウドに移し、販売・生産は当面いまの仕組みでつなぐ | 決算の早期化が最優先 |
| 拠点・子会社から先に替える | 本社は残し、子会社や海外拠点に新しいERPを入れる | 本社の仕組みが安定している |
| 周辺の手作業から減らす | 連携の仕組みで、二重入力と突合をなくす | 保守期限にまだ余裕がある |
段階的に進めると、1回あたりの負担とリスクは小さくなります。
ただし、つなぎ目が増えるほど連携の保守が要ります。
最後にどこまで1つにそろえるかは、最初に決めておきます。
本社を残して子会社側から整える考え方は、2層ERPとはで解説しています。
延命を選ぶ会社、乗り換える会社
乗り換える会社｜変えたいことと、変わること
最初に、「この乗り換えで何を変えたいか」を3つまで書きます。
数字が早く見える、現場の確認作業が減る、海外拠点も同じ数字で見る、などです。
あわせて、変わることも先に知っておきます。
- ライセンスの費用が、いまより上がることがある
- 帳票の形、締め処理の考え方、画面の操作感が変わる
- NetSuiteの場合、給与・人事は対象外で、別の仕組みが要る
そのうえで、保守期限から逆算して日程を引きます。
移行の判断軸は基幹システムとERPの違い（移行判断）、手順は基幹システムのリプレイスとはで扱っています。
延命する会社｜次の判断までの準備期間にする
更新で延命すると決めても、次の3つは今のうちに進めてください。
- 保守期限を一覧にする：OS・データベース・業務ソフトごとに
- 仕様を書き残す：担当者の頭の中にある例外処理を文書にする
- データを外に出せるか確かめる：将来の移行とAIの活用に備える
延命は、判断の先送りではありません。
次の判断までの準備期間として使えば、その後の乗り換えが軽くなります。
2つの道で、いまやることを並べると次のとおりです。
乗り換えでよくある失敗3つ
失敗1：社内の頑張りだけで乗り切ろうとする
起きること：通常業務と兼任で進め、途中で担当者が疲弊する。判断が遅れ、日程が延びる。
原因：要件定義・データ移行・テスト・切替判断に、一時的に高い専門性が要ることを見込んでいなかった。
避け方：判断の軸は社内で持ち、作業の専門部分を外部と分け合います。
失敗2：今の業務をそのまま移し替える
起きること：新しいシステムが前より複雑になり、本当の課題が残る。
原因：非効率なやり方や、担当者しか分からない運用まで持ち込んだ。
避け方：「本当に必要な業務」と「惰性で続けている業務」を仕分けてから、新しい仕組みに乗せます（第7章）。
失敗3：本番稼働をゴールにする
起きること：「前のやり方が早い」という声が出て、現場が元に戻る。
原因：稼働後の定着に、予算も人も割いていなかった。
避け方：稼働後の数か月を、最初から計画に入れます。
操作研修・マニュアル・運用ルールの明文化を、定着の工程として扱います。
ベンチャーネットならこう見る｜延命でも乗り換えでも、見える化から
冒頭の落とし穴は、失敗2と同じ根を持っています。
いまの業務の中身を知らないまま、仕組みだけを新しくすることです。
延命の見積書も、乗り換えの見積書も、いまの機能の一覧を前提に作られがちです。
NetSuite認定パートナー（Solution Provider）であるベンチャーネットは、NetSuite・Odoo・AIスクラッチ開発を扱います。
SAPからのリプレイスにも対応しています。
仕事は、ゼロからの導入より、他社のあとの引き継ぎや他システムとの連携が多くを占めます。
その経験から、どちらの道でも次の型で進めます。
型1：見える化→整理整頓→Fit&Gap
- 業務の見える化：いまの業務の流れを、現場に聞いて描く
- 整理整頓：やめる・まとめる・そろえる業務を決める
- Fit&Gap：残った業務を、行き先の標準機能と照らし合わせる
Fit&Gapは、業務と機能の合う・合わないを一つずつ見る作業のことです。
延命を選ぶ会社も、1と2までは進めておく価値があります。
第5章の「仕様を書き残す」は、見える化そのものだからです。
型2：標準に合わせる／開発する／残す
合わなかった業務は、3つのどれかに決めます。
- 標準に合わせる：業務のほうを、新しい仕組みの標準に寄せる
- 開発する：追加の開発や、外部の仕組みとの連携で補う
- 残す：新しい仕組みには載せず、いまの仕組みや運用で続ける
2つ目が増えるほど、第4章の「開発」が重くなります。
「残す」を選べる業務があれば、第4章の段階的な進め方とも組み合わせられます。
図の3段目はNetSuiteを例にしていますが、行き先が他の製品でも順番は変わりません。
最初の打ち合わせでは、主に次の3つを伺います。
- 保守期限は、OS・データベース・業務ソフトごとにいつか
- 担当者が1週間休んだら、何が止まるか
- 5年後の事業の形（海外・新事業・M&A・AIの活用）
今日できること｜システムの棚卸し表をつくる
いま使っている仕組みを、次の表に書き出してみてください。
| システム | 保守期限 | 詳しい人 | 手作業で補っていること |
|---|---|---|---|
| （例）販売管理（受注・出荷・請求） | 2028年3月 | 1人だけ | 会計への売上の転記 |
※表の内容は説明用の架空の例です。
1時間ほどで埋まるはずです。
「詳しい人が1人だけ」と「手作業で補っていること」が多い行が、最初に見直す場所です。
この表が、そのまま見える化の入口になります。
よくある質問
Q1. 基幹システムのアップデートは必要ですか
保守期限の内側にとどまるためには必要です。
更新を止めると、不具合や脆弱性の修正、法改正への対応を受けられなくなります。
ただし、保守期限が近い・属人化している場合は、乗り換えも並べて比べてください（第3章）。
Q2. 更新と乗り換え、どちらが費用を抑えられますか
短期は更新が安く長期は乗り換えが安いこともあります。
古いシステムは、更新を重ねるほど保守の費用が増える傾向があります。
乗り換えの費用は、機能範囲・開発・社内の体制・ユーザー数の4つで動きます（第4章）。
Q3. 保守期限が近いのですが、すぐに動くべきですか
早めの検討をおすすめします。
乗り換えには、要件の整理やデータ移行の時間が要ります。
期限ぎりぎりより、余裕を持って動く方が選択肢が広がります。
Q4. 社内に専任の担当がいなくても進められますか
進められます。
判断の軸を自社で持ち、専門的な部分を外部と一緒に進めれば足ります。
社内だけで抱え込む必要はありません。
Q5. クラウドERPにすると、今後の更新はどうなりますか
NetSuiteの場合は提供元が年2回自動で更新します。
事前に新しい版を試す環境を依頼でき、数か月かけて段階的に適用されます。
追加した機能や連携が動くかの確認は、自社とパートナーで行います。
Q6. NetSuiteの費用はどれくらいですか
ミニマム構成で月額20万円〜が出発点の目安です。
モジュール・ユーザー数・オプションで変わり、構成によっては数百万円規模になることもあります。
自社の場合の金額は、要件を整理したうえでお伝えします。
Q7. 乗り換えずに、いまのシステムを使い続けてもよいですか
条件がそろえば合理的な選択です。
保守期限に余裕があり、属人化がなく、事業も大きく変わらないなら、更新で延命できます。
その間に、仕様の文書化とデータの整理を進めてください。
まとめ
- 更新（アップデート）か乗り換えかに、唯一の正解はない
- 物差しは、保守期限・法対応・拡張・属人化・成長計画・AIの活用
- 乗り換えの費用と期間は、機能範囲・開発・社内の体制・ユーザー数で動く
- クラウドERPでも、年2回の検証は残る
- 延命でも乗り換えでも、見える化と整理整頓が次の判断を軽くする
「これを払えば、あと何年もつのか」。
その問いに答える前に、棚卸し表を1枚作ってください。
延命の見積書も、乗り換えの見積書も、その表があれば同じ土俵で読めます。
もう少し詳しく知りたい方へ
「うちはどちらを選ぶべきか」「何から手をつければよいか」と迷われたら、現状の整理からお手伝いします。
コメント
コメント一覧 （1件）
[…] 「更新か、乗り換えか」の考え方は、基幹システムは「更新」か「乗り換え」かでも扱っています。 […]