「このOSのサポートは来年で終了します」という案内が、長年動いてきたAS/400やオフコンの保守会社から届く。使い慣れた画面はそのままでいいから、とにかく止まらないようにしたい。そう思う一方で、開発会社に相談すると「作り替えましょう」「ERPパッケージに寄せましょう」と、会社によって勧められる方向がまるで違う。どれが自社に合っているのか判断がつかないまま、時間だけが過ぎていく担当者は少なくありません。
結論から言うと、基幹システムの移行方式は「そのまま移す」「作り替える」「パッケージに寄せる」の3つに整理でき、どれを選ぶかで費用も期間も大きく変わります。そしてこの選択は、相談する開発会社によって答えが偏りやすい領域でもあります。移行サービスを持つ会社に聞けばそのまま移す提案が返り、ERPベンダーに聞けばパッケージ導入の提案が返るからです。この記事では、開発会社に相談する前に発注側で押さえておきたい、3方式の違いと選び方、費用の見方を整理します。
この記事のポイント
- 移行方式は「そのまま移す」「作り替える」「パッケージに寄せる」の3つに整理できる
- 選び分けの軸は業務ロジックの独自性と、止まったときの業務影響の大きさ
- AS/400やIBM iなど旧環境特有の事情（言語資産・接続機器）を先に洗い出しておく
- 方式ごとに費用と期間のレンジが大きく違うため、比較する前提を揃える必要がある
目次
基幹システムの移行方式は3つの選択肢から選ぶ
まず整理したいのは、「移行」という言葉が指す作業の幅の広さです。ハードウェアだけ新しくして中身は一切変えない作業も、業務プロセスごと作り直す作業も、同じ「移行」と呼ばれてしまいます。この幅を放置したまま相談に行くと、開発会社ごとに前提が違う見積もりが返ってきて、比較すること自体ができなくなります。
そのまま移す・作り替える・パッケージに寄せるの違い
実務で使う分け方はシンプルで、次の3つです。
| 方式 | やること | 向いている状態 | 費用と期間の重さ |
|---|---|---|---|
| そのまま移す | 既存の処理・画面をほぼ変えず、新しいサーバーやクラウド環境に載せ替える | 業務ロジックが複雑で独自性が高く、まず延命を優先したい | 軽い〜中程度 |
| 作り替える | 現行の業務ロジックを踏まえつつ、言語や構成を新しい技術基盤で再構築する | 今の業務の進め方は概ね維持したいが、技術的な老朽化を解消したい | 中程度〜重い |
| パッケージに寄せる | ERPパッケージやクラウドサービスを導入し、業務のほうを標準機能に合わせる | 業務プロセス自体を標準化・効率化したい、属人化を解消したい | 最も重い（ただし運用後の保守は軽くなりやすい） |
この3つは、専門的には「リホスト」「リビルド（リライトを含む）」「リプレース」と呼ばれることもありますが、発注側が覚える必要はありません。大事なのは、業務ロジックをどこまで手放せるかという1本の軸で並んでいるということです。そのまま移すが最も業務ロジックを維持し、パッケージに寄せるが最も業務ロジックを標準に合わせにいく、両端に位置しています。
どの方式が向いているかは業務ロジックの独自性と止まったときの影響で決まる
選び分けの実務的な軸は2つです。ひとつは、今の業務ロジックがどれだけ自社独自かということ。長年の商習慣や特殊な取引条件が複雑に組み込まれているシステムを無理にパッケージへ寄せると、標準機能でカバーできない部分が大量のアドオン開発を呼び、結局スクラッチ開発に近い費用になってしまうことがあります。こうした場合は、まず「そのまま移す」で延命し、業務の標準化は別のタイミングで検討するほうが現実的です。
もうひとつの軸は、止まったときの業務影響です。受注や出荷に直結する基幹システムを、検証が浅いまま一気に切り替えるのはリスクが高すぎます。影響が大きい業務ほど、段階的に検証しながら進められる「作り替える」を選び、旧システムと新システムを一定期間並行稼働させる計画を前提に組んだほうが安全です。逆に、比較的独立した業務領域から着手できるなら、パッケージ導入の対象を絞って先に効果を確かめるやり方も選べます。
この2軸で自社の状態を整理すると、開発会社に相談する前に「うちはこの方式が候補」という仮説を持てます。仮説を持たずに相談すると、最初に会った会社の得意分野に引っ張られやすくなる点には注意してください。
AS/400やIBM iなど旧環境特有の注意点
AS/400（現IBM i）やオフコン特有の事情として、業務ロジックがRPGやCOBOLといった言語で書かれ、しかも仕様書がほとんど残っていないケースが多くあります。この場合、「作り替える」を選んでも、まずソースコードを解析して業務ロジックを可視化する作業が必要になり、想定より前工程に時間がかかります。仕様書の有無は、方式を選ぶ前に必ず確認しておきたいポイントです。
また、旧環境には専用端末やバーコードリーダーなど、独自のインターフェースで接続している周辺機器が残っていることがあります。これらの機器がそのまま新環境で使えるのか、買い替えが必要なのかは、見落とされがちですが費用に直結する論点です。現場でどんな機器がシステムにぶら下がっているかを、早い段階で棚卸ししておいてください。
もうひとつ、金額には出にくいものの見過ごせないのが、対応できる技術者が年々減っているという事情です。RPGやCOBOLを読み書きできる技術者は現場の高齢化とともに減少しており、改修を頼める相手を探すこと自体が年々難しくなっています。今すぐ全面的に作り替える予定がなくても、いつまでなら延命できるのか、対応できる技術者や保守会社がいつまで確保できるのかは、方式を選ぶ前に開発会社へ率直に確認しておくべき論点です。
移行方式ごとの費用と期間の目安
費用は業務範囲と選ぶ方式で大きく変わるため一律には言えませんが、目安として、そのまま移す場合は数百万円から、作り替える場合は1,000万円台から、パッケージに寄せて業務も作り込む場合は数千万円以上を見ておくケースが多いです。期間は、そのまま移すなら3〜6か月、作り替えるなら要件定義から本稼働まで半年から1年、パッケージ導入で業務を大きく合わせる場合は1年以上を見込むと大きく外しません。
これらはあくまで一般的な目安であり、実際の判断は自社の業務範囲を前提にした個別の見積もりで確認してください。見積書を並べて比較するときは、初期費用だけでなく、データ移行費・並行稼働中の二重ライセンス費・稼働後の保守費まで含めた総額で見る必要があります。規模別のレンジと内訳の読み方は、基幹システム刷新の費用相場と見積もりの読み方で詳しく整理しています。全面刷新に踏み切るかどうかの判断基準そのものから確認したい場合は、基幹システムのリプレイスとは？進め方と発注側の判断基準もあわせて参考にしてください。
基幹システムの移行方式選びで失敗しない進め方
方式の見当がついたら、次は進め方です。移行プロジェクトの成否を分けるのは、技術力以上に発注側の準備であることがほとんどです。ここでは、相談前に決めておくこと、パートナー選びの観点、つまずきやすい落とし穴を順に見ていきます。
開発会社に相談する前に決めておくこと
相談前に固めておきたいのは、まず現行業務の棚卸しです。今どの業務が、どの機能で、どれくらいの頻度で使われているかを洗い出します。長年運用してきたシステムには、年に一度しか使わない機能や、実はもう誰も使っていない機能が紛れ込んでいます。これを移行対象にするかどうかの判断だけで、見積もりの規模は大きく変わります。
次に、先ほど整理した2軸をもとに、どの方式を軸に検討するかの仮説を持っておくことです。仮説がないまま相談すると、開発会社の提案をそのまま受け入れる形になり、あとから「本当にこの方式でよかったのか」を検証する材料がなくなります。仮説は最終決定である必要はなく、複数社に同じ前提で相談するための土台として持っておけば十分です。
開発会社に相談する前の確認リスト
- 現行業務の棚卸しを終え、移行対象と対象外の機能を仕分けられているか
- 現行システムの仕様書やソースコードがどこまで残っているか把握しているか
- 専用端末や周辺機器など、新環境への接続を検討すべき機器を洗い出せているか
- 3方式のうち、自社の仮説としてどれを軸に検討するか決まっているか
- 並行稼働できる期間と、動かせない業務上の締切を把握しているか
移行パートナー選びで見るべき実績
移行方式が決まっても、頼む相手を誤ると同じ失敗を繰り返します。特に旧環境からの移行は、その独自仕様を深く理解しているかどうかで難易度が大きく変わるため、パートナー選びが成否の生命線になります。
確認すべきは、自社と同じような規模・業種での移行実績があるか、移行元の言語や環境（RPG・COBOL・特定のオフコン機種など）への理解があるか、移行後の保守体制まで含めて提示できるかの3点です。移行だけを請け負って稼働後の保守は別会社という体制だと、切り替え直後のトラブル対応で責任の所在があいまいになりがちです。
特に業務ロジックの解析を任せる場合は、担当者が実際にどこまで旧言語を読み解いてきたのかを、事例ベースで具体的に聞いてください。「対応実績あり」という言葉だけでは、実際にどの範囲まで踏み込んで解析できるのかが分かりません。過去に担当した案件で、どんな業務ロジックをどう読み解き、どこでつまずいたのかを尋ねると、担当者の実力が見えてきます。
複数社に同じ条件で情報を集めたい場合は、いきなり提案依頼書（RFP）を出す前に、会社概要・実績・概算費用感を同じ質問でそろえて絞り込む段階を挟むと、比較がしやすくなります。RFI（情報提供依頼書）テンプレートを使えば、各社に同じ回答依頼シートを送って、移行実績や体制を横並びで確認できます。
また、旧環境の移行は対応できる会社が限られやすく、気づけば1社としか付き合えない状態になっていることがあります。今回の移行先を選ぶ際にも、将来また同じような状態に陥らないよう、契約やデータ形式の観点で選択肢を確保しておく視点が必要です。詳しくはベンダーロックインの対策で整理しています。
移行でつまずきやすい2つの落とし穴
ひとつ目の落とし穴は、要件定義の場で「今と同じ動きにしてほしい」とだけ伝えてしまう現行踏襲です。今と同じ、の中身を正確に説明できる担当者は多くありません。結果として開発が進んでから「この処理が抜けている」が次々に見つかり、追加費用と納期遅れが積み重なります。棚卸しの段階で、残す機能と手放す機能を先に決めておくことが、この落とし穴を避ける最善の方法です。
ふたつ目はデータ移行です。長年運用してきたシステムには、表記の揺れた取引先名や、桁数の合わない過去データが必ず溜まっています。これを検証なしに新環境へ流し込もうとして、本番直前に処理が止まるのが典型的な失敗パターンです。移行するデータの範囲、いつ時点のデータを持っていくか、リハーサルを何回行うかを、要件定義の段階で決めておいてください。切り替え当日にどの状態になったら旧システムに戻すかという撤退の基準も、事前に文書化しておくと、当日の混乱を防げます。
