長年使ってきた基幹システムの老朽化や保守終了が近づき、「そろそろ刷新を」と検討を始めると、必ず出てくるのが「マイグレーション」という言葉です。ただ、調べてみると「リホスト」「リライト」「リビルド」など種類が複数あり、呼び方や数の整理がつきにくく、結局どれを指すのか掴みにくいと感じる方も多いのではないでしょうか。
本記事では、基幹システムのマイグレーションにどのような種類・手法があるのかを、名前と中身をセットで整理します。手法ごとの作り替える範囲・コスト感・向くケースは、比較表で一覧にします。あわせて、「対象別の種類」と「手法別の種類」という2つの切り口の違い、リプレースやモダナイゼーションといった似た用語との違い、自社のレガシー基幹に合う手法の選び方までを解説します。
刷新の選択肢を整理するための材料としてご活用ください。
目次
一括ダウンロードする
マイグレーションとは
マイグレーション（migration）とは、システムやデータ、アプリケーションを、今動いている環境から別の新しい環境へ移し替えることを指します。「移行」と訳されることが多く、基幹システムの文脈では、老朽化したハードウェアやOS、古いプログラムを新しい基盤へ載せ替える取り組み全般を意味します。
ひとくちにマイグレーションといっても、「何を移すのか（対象）」と「どう作り替えるのか（手法）」という2つの切り口があり、これが呼び名の混乱を生んでいます。検討の土俵に乗るために多くの方がまず知りたいのは、後者の「どう作り替えるのか」という手法の選択肢です。ここから、その手法別の種類を先に整理していきます。
マイグレーションの手法別の種類（リホスト・リライト・リビルドなど）
ここからは、マイグレーションの「手法別の種類」を解説します。手法の呼び方は文脈によって整理の仕方が異なります。国内では「リホスト・リライト・リビルド」の3分類が広く使われ、クラウド移行の文脈では、アマゾン ウェブ サービス（AWS）が移行戦略を体系化した「7R」で、より細かく手法が分かれます。
AWSの7Rは、リホスト（Rehost）／リプラットフォーム（Replatform）／リファクタリング・リアーキテクト（Refactor/Re-architect）／リパーチェース（Repurchase）／リロケート（Relocate）／リテイン（Retain＝現状維持）／リタイア（Retire＝廃止）の7つです。
このうち後述する「リライト」「リビルド」は7Rには含まれない、国内で広く使われてきた呼び方で、7Rでいえばリファクタリング・リアーキテクトやリパーチェースに近い方向にあたります。
ここからは、国内3分類とAWSの7Rを横断して、基幹システムの刷新で判断材料になる代表的な手法を、名前と「何を作り替えるか」をセットにして順に見ていきます。
先に全体像を掴んでおきましょう。下の図は、これから見ていく代表的な手法を、作り替える範囲の小さい順に並べたものです。左へ行くほど作り替えは小さくコスト・期間も小さく、右へ行くほど大きくなります。
リホスト（リフト＆シフト）
リホストは、アプリケーションのプログラムには手を加えず、稼働する基盤（サーバーやOS）だけを新しい環境へそのまま移す手法です。「リフト＆シフト」とも呼ばれ、オンプレミスのサーバーをクラウドの仮想サーバーへ載せ替えるケースが代表例にあたります。作り替える範囲が最も小さいため、コストと期間を抑えやすく、短期間でハードウェアの老朽化やサポート終了を回避したい場合に選ばれます。
一方で、古いプログラムの構造はそのまま残るため、根本的な使いにくさや複雑さは解消されません。あくまで「基盤の延命」に近い手法である点は押さえておく必要があります。
リプラットフォーム
リプラットフォームは、アプリケーションの主要な構造は保ちつつ、一部を新しい環境に最適化して移す手法です。たとえば、自社で管理していたデータベースをクラウド事業者が提供するマネージドサービスに置き換えるように、動きは変えずに運用負荷を下げる調整を加えます。リホストと、より深く作り替える手法との中間に位置づけられ、移行の効果と負担のバランスを取りたい場合に用いられます。
リライト
リライトは、既存の機能や仕様は維持したまま、プログラムを新しい言語や開発基盤で書き換える手法です。COBOLなどで書かれた古い基幹システムを、JavaやモダンなWeb技術へ書き換えるケースが典型例にあたります。機能を大きく変えずに、保守できる技術者が減った古い言語から脱却できる点が利点です。
ただし、既存プログラムの仕様を正確に読み解く必要があり、後述するドキュメント不備の影響を受けやすい手法でもあります。
リファクタリング・リアーキテクト
リファクタリング（リアーキテクト）は、業務としての役割は引き継ぎつつ、内部の設計や構造を新しい方式に作り替える手法です。AWSの7Rでは、クラウドの利点を最大限に生かすための戦略に位置づけられ、単なる内部改善にとどまらず、機能の拡張や拡張性の獲得を狙って設計を大きく変えることも含みます。マイクロサービス化のように構成そのものを刷新するため効果は大きい一方、難易度と費用は高くなります。
リビルド
リビルドは、既存システムを土台にせず、業務要件を捉え直してゼロから作り直す手法です。内部の設計だけを作り替えるリファクタリングと違い、業務のあり方そのものから設計し直す点が特徴で、作り替える範囲は最も広く、コストも期間も大きくなります。長年の改修で複雑になった構造をリセットでき、現行の仕組みが事業の足かせになっている場合に選択されます。
このほか、パッケージ製品やクラウドサービスへ乗り換える「リパーチェース」、既存システムをそのまま別のクラウドへ移す「リロケート」も、広い意味では移行の選択肢に含まれます。基幹システムの刷新では、後述するERP（統合基幹業務システム）への切り替えが、このリパーチェースに近い考え方にあたります。
【比較表】主なマイグレーション手法の比較
以下は、ここまで紹介した主な手法を、作り替える範囲・コストと期間の目安・向くケースで並べた比較表です。コストと期間は案件の規模や現行システムの状態で大きく変わるため、手法どうしの相対的な傾向として捉えてください。
| 手法 | リホスト（リフト＆シフト） | リプラットフォーム | リライト | リファクタリング・リアーキテクト | リビルド |
|---|---|---|---|---|---|
| 作り替える範囲 | 基盤のみ（プログラムは変えない） | 基盤＋一部を最適化 | プログラム（言語・基盤を書き換え） | 内部設計・構造 | 全体（要件から作り直し） |
| コスト・期間の目安 | 小さい・短い | 中程度 | 中〜大 | 大きい | 最も大きい・長い |
| 向くケース | 老朽化・保守終了を短期で回避したい | 運用負荷を下げつつ効果とのバランスを取りたい | 機能は保ちつつ古い言語から脱却したい | クラウドの利点を生かし設計から刷新したい | 複雑化した現行を捨て業務ごと見直したい |
※作り替える範囲・コスト・期間は一般的な傾向です。実際の費用や期間は現行システムの規模・状態や移行範囲によって大きく異なります。
「対象別の種類」と「手法別の種類」はどう違うか
マイグレーションの「種類」を調べると、ここまで見た手法とは別に、「データマイグレーション」「サーバーマイグレーション」「レガシーマイグレーション」といった言葉も出てきます。これらは手法とは切り口が異なり、「何を移すのか（対象・範囲）」で分けた種類です。手法別の種類とレイヤーが違うため、同じ並びで比べると混乱しやすくなります。
下の表は、2つの切り口を整理したものです。「対象別」は移す対象を、「手法別」は作り替え方を表しており、実際の移行では「レガシーマイグレーションを、リホストという手法で進める」のように、両者を組み合わせて計画します。
| 切り口 | 対象別の種類（何を移すか） | 手法別の種類（どう作り替えるか） |
|---|---|---|
| 分け方の観点 | 移行する対象・範囲 | プログラムをどこまで作り替えるか |
| 代表的な呼び名 | データ／サーバー／クラウド／レガシー／ライブ の各マイグレーション | リホスト／リプラットフォーム／リライト／リファクタリング／リビルド |
対象別の主な呼び名も、あわせて押さえておきましょう。データマイグレーションはデータベースやファイルなどのデータを、サーバーマイグレーションはサーバーの基盤環境を、クラウドマイグレーションはオンプレミスの資産をクラウドへ移すことを指します。
ライブマイグレーションは、システムを稼働させたまま止めずに移す方式です。これらはいずれも「何を移すか」の区分であり、実際にはここに手法別の種類を組み合わせて計画します。
「対象別」のうち、老朽化した古い基幹システム（レガシーシステム）を新環境へ移すことを特に「レガシーマイグレーション」と呼びます。基幹システムの刷新を検討している場合、狙っているのはこのレガシーマイグレーションであり、それを「どの手法で進めるか」を先ほどの手法別の種類から選ぶ、という関係になります。
リプレース・コンバージョン・モダナイゼーションとの違い
マイグレーションの周辺には、意味の近い用語がいくつもあり、これも混乱のもとになります。ここでは、特に混同されやすい3つの用語との違いを整理します。
リプレースとの違い
リプレース（replace）は「置き換え」を意味し、既存のシステムを別の新しいシステムに丸ごと入れ替えることを指します。マイグレーションが既存の資産（データやプログラム）を新環境へ「移す」ことに主眼を置くのに対し、リプレースは既存を捨てて新しいものに「置き換える」点が異なります。
ただし両者の線引きは記事や場面によって揺れがあり、リビルドやパッケージへの乗り換えを広義のリプレースと呼ぶこともあります。
コンバージョンとの違い
コンバージョン（conversion）は「変換」を意味し、プログラムやデータの形式を、機能や仕様を変えずに機械的に別の形式へ変換することを指します。たとえば古い言語のソースコードを自動変換ツールで新しい言語へ置き換える作業がこれにあたります。マイグレーション（移行）を実現するための手段の一つがコンバージョン（変換）、という関係で捉えると整理しやすくなります。
モダナイゼーションとの違い
モダナイゼーション（modernization）は「近代化」を意味し、古いシステムを最新の技術や設計に合わせて刷新し、価値を高めていく取り組み全体を指す、より広い概念です。マイグレーションはこのモダナイゼーションを実現するための代表的な手段の一つと位置づけられます。単に環境を移すだけでなく、業務のあり方まで見直していく文脈では、モダナイゼーションという言葉が使われます。
基幹システム刷新が迫られる背景と2つの崖（2025年・2027年）
そもそも、なぜ今マイグレーションが基幹システムの課題として注目されているのでしょうか。背景には、古い基幹システムを刷新できないことへの危機感があります。ここでは、その原因と、刷新を迫る2つの「崖」を整理します。
レガシー資産のブラックボックス化
長年運用してきた基幹システムには、メインフレームやオフィスコンピューター（オフコン）上でCOBOLなどの古い言語で作られたものが少なくありません。改修を重ねるうちに内部構造が複雑になり、どこを変えると何に影響するのかを把握しづらい「ブラックボックス化」が進みます。
現行システムの問題点そのものが見えにくくなると、刷新の計画すら立てにくく、投資判断が先送りされがちです（移行を進める段階で顕在化する具体的な障害は後半のリスク節で扱います）。
「2025年の崖」（経済産業省DXレポート）
この課題に警鐘を鳴らしたのが、経済産業省が2018年に公表した「DXレポート」です。同レポートは、複雑化・老朽化・ブラックボックス化した既存システムが残存した場合、2025年以降に年間最大12兆円（同レポート公表時点の約3倍）の経済損失が生じる可能性があると指摘しました。これが「2025年の崖」と呼ばれる問題提起です。
この「12兆円」は確定した損失額ではなく、既存システムが残存した場合の警告としての試算である点も押さえておくと、数値を正しく捉えられます。
「2025年の崖」がその後どう受け止められ、警告された2025年以降に実際に何が起きたのか、企業がとるべき対策までを詳しく知りたい方は、以下の記事で掘り下げています。
「2027年の崖」（SAP ERPの保守終了）
基幹システムの刷新で、より具体的な期限として意識されているのが「2027年の崖」です。これは、世界各国で基幹システムとして採用されている統合ERP「SAP ERP（ECC 6.0）」に関わる期限です。これを含む「SAP Business Suite 7」の標準保守（メインストリームメンテナンス）が2027年末に終了し、延長保守も2030年末までとされています。
保守が終了すると、法制度の変更への対応やセキュリティ更新が受けられなくなるため、SAPを利用する多くの企業が、後継の「SAP S/4HANA」への移行という形で刷新のタイミングを迎えます。
2025年の崖がレガシー基幹システム全般への警告だったのに対し、2027年の崖は特定製品の保守期限に関する課題です。両者は「サポート終了を機に刷新を迫られる」という点で地続きであり、SAPを使う企業にとっては2027年が崖への具体的な対応時期として重なります。
マイグレーションの主なリスクと注意点
手法を選ぶ前に、基幹システムのマイグレーションで直面しやすいリスクも押さえておきましょう。とくに古い基幹システムでは、次のような点が計画の遅れやコスト増につながります。
仕様のブラックボックス化とドキュメント不備
長く使われた基幹システムは、改修の積み重ねで仕様が複雑になり、設計書やマニュアルが最新の状態に保たれていないことがよくあります。現行の仕様が正確に分からないまま移行に着手すると、移行範囲や費用の見積もりが狂い、リライトのように既存仕様の読み解きを前提とする手法では特に影響が大きくなります。
開発当事者の不在と技術者の高齢化
開発や初期設定に関わった担当者がすでに退職していると、仕様を知る人がいなくなり、障害対応も改修も外部に依存せざるを得なくなります。COBOLや古いミドルウェアを扱える技術者自体が減っているため、対応できる人材の確保も難しくなっています。
テストコストの肥大化
基幹システムは会計や販売など事業の根幹を担うため、移行後に想定どおり動くかを丁寧に検証する必要があります。移行前と移行後で処理結果が一致するかを突き合わせるテストには手間がかかり、確認範囲が広いほどコストも膨らみます。この検証を軽視すると、本番移行後に業務が止まるリスクが高まります。
データ移行と互換性のリスク
古いシステムから新環境へデータを移す際、文字コードやデータ形式の違いによって、移行時に欠損や不整合が生じることがあります。移行中の業務停止（ダウンタイム）をどこまで許容できるかもあわせて計画し、事前のテスト移行で整合性を確認しておくことが欠かせません。
自社に合う手法の選び方
ここまで見てきた手法のうち、自社のレガシー基幹にはどれが現実的なのでしょうか。決まった正解はありませんが、次の条件で候補を絞り込むと判断しやすくなります。
- 期限とコストを最優先するなら：保守終了が目前で、まず延命したい場合はリホストが候補になります。作り替えは最小限に留まります。
- 古い言語からの脱却が目的なら：機能は保ちつつ保守できる技術者を確保したい場合は、リライトやリプラットフォームが候補です。
- クラウド活用を前提に設計から刷新するなら：拡張性やクラウドの利点を得たい場合は、リファクタリング・リアーキテクトが候補になります。
- 複雑化した業務ごと見直すなら：現行システムが事業の足かせになっている場合は、リビルドや、パッケージ製品・ERPへの乗り換えが候補になります。
手法を作り替える範囲だけで選ぶと、費用と期間が想定を超えてしまうことがあります。現行システムの仕様がどこまで把握できているか、いつまでに移行を終える必要があるか、確保できる予算と人材はどれくらいか、という自社の条件と照らし合わせて絞り込むことが大切です。
また、既存の仕組みを移すか、いっそ新しい仕組みに置き換えるかで迷う場合は、「マイグレーション（移行）」か「リプレース・刷新」かという判断になります。前章で触れた2027年の崖のように、保守終了を機に刷新を迫られているのであれば、既存を延命するよりも、後継の統合ERPへ切り替えて業務プロセスごと標準化する選択肢が現実的なこともあります。
手法の方向性が定まったら、次は実際にどう移行を進めるかを見ていきます。
マイグレーションの進め方
手法の方向性が定まったら、実際の移行は大きく次の流れで進みます。全体像を掴んでおくと、どの手法でも見積もりや計画の精度を上げやすくなります。
- 現状の棚卸し・可視化：どの業務がどのシステムで動き、どこにデータが分散し、どこが老朽化しているのかを洗い出します。ここが曖昧だと、以降の見積もりが狂います。
- 移行方針・計画の策定：可視化の結果をもとに、どの手法で、どの範囲から、どのくらいの期間で進めるかを決めます。
- データ変換・テスト計画の立案：移行するデータの変換ルールと、移行前後で結果が一致するかを確認するテストの計画を立てます。
- 本番移行と切り替え：計画に沿って本番環境へ移行し、旧システムから新システムへ切り替えます。ダウンタイムを想定した手順と予備時間を確保します。
- 運用・監視・最適化：移行後の稼働を監視し、問題があれば調整しながら、新環境での運用を安定させます。
基幹システムのように影響範囲が広い場合は、一度にすべてを移すのではなく、影響の小さい領域から段階的に移行していくほうが、失敗したときのリスクを抑えられます。会計や人事給与など標準化しやすい領域から着手し、成果を確認しながら販売・生産へ広げていく進め方が現実的です。
一括ダウンロードする
基幹システムのマイグレーション・ERP刷新を支援するサービス
レガシー基幹システムの刷新先として有力な選択肢が、ERP（統合基幹業務システム）です。ERPは、会計・販売・在庫・人事といった基幹業務を1つのシステムとデータベースで統合的に扱う仕組みで、部門ごとに分断されていたデータを一元管理できます。
とくにクラウド型のERPは、運用・保守や法制度改正への対応を提供側が担うため、サポート終了に追われる構造から抜け出しやすい点でも、レガシー刷新と相性のよい受け皿になります。
ここで紹介するのは、抜本的な刷新にあたるERPへの切り替えの選択肢です。リホストによる延命やリライトによる書き換えを選ぶ場合は、クラウド移行支援やシステム開発を手がけるベンダー・SIerが実際の担い手になります。
ここでは、刷新のアプローチや対象規模が異なる代表的なサービスを紹介します。すべての製品を網羅する比較ではなく、移行先の選択肢にどのような幅があるかを掴むための例としてご覧ください。以下は、紹介するサービスの比較表です。
| サービス名 | Oracle NetSuite | Odoo導入・開発・業務統合支援 | SAP S/4HANA Cloud | PROACTIVE |
|---|---|---|---|---|
| 提供会社 | 日本オラクル株式会社 | 株式会社マルウェブ | SAPジャパン株式会社 | SCSK株式会社 |
| 提供形態 | クラウドERP（SaaS） | クラウドERP（SaaS）／セルフホスト（OSS版） | クラウドERP（SaaS）／オンプレミス | クラウドERP（SaaS）／オンプレミス／IaaS（ハイブリッド導入可） |
| 対象企業規模 | スタートアップ〜上場企業 | 中小・中堅企業 | 中堅〜大企業 | 中堅〜大企業 |
| 得意な移行・刷新アプローチ | 必要な業務から段階的に移行（標準機能で短期に統合） | 着手しやすい領域から段階導入（OSSで柔軟にカスタマイズ） | 全社標準化を伴う大規模刷新（Fit to Standard） | 会計・人事給与から段階移行（ハイブリッド導入） |
| 詳細情報 | 公式資料を見る | 公式資料を見る | サービス詳細を見る | サービス詳細を見る |
※2026年9月時点の各社公開情報にもとづく、代表的な選択肢の比較です。提供形態・対象規模・料金は変動するため、最新の詳細は各サービスの公式情報をご確認ください。
1. Oracle NetSuite（日本オラクル株式会社）
クラウドを前提に設計された統合ERPで、会計・販売・在庫・購買などの基幹業務を1つのシステムでカバーします。オンプレミスの古い基幹システムを刷新するきっかけで導入されることが多く、成長中のスタートアップから上場企業まで、規模の拡大に合わせて利用範囲を広げられる点が特徴です。
グループ会社や海外拠点を含めた会計・業績の一元管理に対応し、M&Aで増えた拠点の業務統合にも使われています。必要な業務から順に載せ替えられるため、レガシー刷新を一度に行わず、段階的に移行していく進め方とも相性のよい選択肢です。
レガシー基幹の刷新でERPが選ばれる根っこには、部門ごとにデータが分断されるという課題があります。開発元である日本オラクルは、クラウドERPが生まれた背景を独自インタビューでこう語っています。
会計は会計のシステム、在庫は在庫のシステム、というように業務ごとにシステムが分かれていると、データが分断されてしまって、経営者が全体を見ようとしてもなかなか正確な数字がつかめません。そこで、あらゆる業務を一つの基盤で一元管理して、経営者がどこからでもリアルタイムにデータを確認できるようにしたい、という発想からクラウドERPという形にたどり着きました。
2. Odoo導入・開発・業務統合支援（株式会社マルウェブ）
オープンソース（OSS）のERP「Odoo」を基盤に、導入から開発、業務統合までを支援するサービスです。会計・在庫・販売・人事など80を超える業務アプリがモジュールとして用意されており、必要な領域だけを選んで導入し、後から段階的に追加していけます。
会計や人事といった着手しやすい領域から始めて統合範囲を広げる進め方を取りやすいため、一括刷新の負担を避けたい中小・中堅企業のレガシー移行に向いています。オープンソースならではの柔軟なカスタマイズと、自社の業務に合わせた作り込みを支援してもらえる点も選択のポイントです。
3. SAP S/4HANA Cloud（SAPジャパン株式会社）
SAPは、中堅企業から大企業、グローバルに拠点を持つ企業まで、世界各国で基幹システムとして採用されている統合ERPです。多数の拠点・通貨・言語をまたいだ会計や業務の統合に対応し、大規模で複雑な基幹業務の刷新先として参照される製品です。
本記事で触れた「2027年の崖」の当事者となる製品でもあります。旧世代のSAP ERP（ECC 6.0）の標準保守が2027年末に終了予定のため、その受け皿となる後継が、S/4HANAをクラウドで利用するこのSAP S/4HANA Cloudです。全社的な標準化を伴う大掛かりな刷新を検討する際の、代表的な比較対象になります。
4. PROACTIVE（SCSK株式会社）
住友商事グループのSCSK株式会社が提供する、国産の統合型ERPです。1993年からERPパッケージとして販売され、会計・人事給与・販売・生産管理まで基幹業務全般を1系統でカバーします。累計7,500社超の導入実績を持ち、SaaS・オンプレミス・IaaS（クラウド上のサーバー基盤）を業務領域ごとに使い分ける「ハイブリッド導入」に対応する点も特徴です。
長く使った基幹システムのリプレース先としても選ばれており、公式の事例では、約18年使用した基幹システムをPROACTIVEに刷新した企業が紹介されています。国産ならではの法改正対応や、会計・人事給与といった標準化しやすい領域から段階的に移行できる点は、レガシー刷新を検討する国内企業にとって現実的な選択肢といえます。
ここで取り上げたのは、移行先の選択肢の幅を掴むための代表例です。ERP（統合基幹業務システム）を対象規模や機能で広く比較し、自社に合う製品の選び方まで確認したい場合は、以下のまとめ記事もあわせてご覧ください。
ERP比較20選｜統合基幹業務システムを企業規模・提供形態・費用で徹底比較
会計や販売、在庫、人事給与を別々のシステムやExcelで管理していて、部門をまたぐたびにデータを入力し直している——そんな基幹業務の分断に限界を感じていませんか。老朽化した基幹システムの保守切れや、グループ経営・海外拠点の管理を機に、ERP…
まとめ
基幹システムのマイグレーションには、「何を移すか（対象別の種類）」と「どう作り替えるか（手法別の種類）」という2つの切り口があります。手法別では、基盤だけを移すリホストから、要件ごと作り直すリビルドまで、作り替える範囲に応じて複数の選択肢があり、コストや期間、向くケースが異なります。
自社に合う手法は、現行システムの把握状況・期限・予算・人材といった条件から絞り込むのが現実的です。とくに2027年の崖のように保守終了が迫っているケースでは、既存を延命するだけでなく、統合ERPへの刷新も有力な選択肢になります。移行先を具体的に検討する段階では、各サービスの資料を取り寄せ、対象規模・提供形態・費用を並べて比較することから始めると確実です。
一括ダウンロードする
よくある質問（FAQ）
Q. マイグレーションとは何ですか？
マイグレーションとは、システムやデータ、アプリケーションを今の環境から新しい環境へ移し替えることで、日本語では「移行」と訳されます。基幹システムの文脈では、老朽化したハードウェアやOS、古いプログラムを新しい基盤へ載せ替える取り組み全般を指します。
ひとくちにマイグレーションといっても「何を移すか（対象別の種類）」と「どう作り替えるか（手法別の種類＝リホスト・リライト・リビルドなど）」の2つの切り口があり、これが呼び名の混乱を生んでいます。
Q. マイグレーションとリプレース・コンバージョンの違いは何ですか？
3つの違いは、マイグレーションが既存の資産を新環境へ「移す」のに対し、リプレースは既存を捨てて新しいシステムに「置き換える」、コンバージョンはプログラムやデータの形式を「変換する」点にあります。コンバージョン（変換）は、古い言語のソースコードを自動変換ツールで新しい言語へ置き換えるように、マイグレーション（移行）を実現するための手段の一つと捉えると整理しやすくなります。
リプレースとの線引きは記事や場面によって揺れがあり、リビルドやパッケージへの乗り換えを広義のリプレースと呼ぶこともあります。
Q. リホスト・リライト・リビルドの違いを簡単に教えてください。
3つの違いは作り替える範囲の広さにあります。リホストは基盤（サーバー・OS）だけを移してプログラムは変えず、リライトは機能を保ったままプログラムを新しい言語で書き換え、リビルドは業務要件から見直してゼロから作り直します。作り替える範囲が広くなるほど刷新の効果は大きくなる一方、コストと期間も大きくなります。
老朽化や保守終了を短期で回避したいならリホスト、複雑化した業務ごと見直したいならリビルドが目安になります。
Q. 基幹システムのマイグレーションにはどのくらいの費用・期間がかかりますか？
基幹システムのマイグレーションの費用・期間は、選ぶ手法と現行システムの規模・状態によって大きく変わるため、一律の相場を示すことは困難です。一般的な傾向としては、基盤だけを移すリホストはコストも期間も小さく、要件から作り直すリビルドが最も大きくなります。見積もりの精度を上げるには、まずどの業務がどのシステムで動き、どこが老朽化しているかを洗い出す「現状の棚卸し」が前提になります。
手法どうしの相対的な傾向は本記事の比較表を、正確な費用は各サービスの資料や見積もりをご確認ください。
Q. 「2027年の崖」とは何ですか？基幹システムとどう関係しますか？
「2027年の崖」とは、統合ERP「SAP ERP（ECC 6.0）」を含む「SAP Business Suite 7」の標準保守が2027年末に終了する（延長保守も2030年末まで）ことで、SAPを利用する企業が刷新を迫られる問題を指します。
保守が終了すると、法制度の変更への対応やセキュリティ更新が受けられなくなるため、多くの企業が後継の「SAP S/4HANA」への移行というかたちで刷新のタイミングを迎えます。経済産業省が警鐘を鳴らした「2025年の崖」がレガシー基幹システム全般への警告だったのに対し、2027年の崖は特定製品の保守期限に関する課題である点が異なります。
Q. 基幹システムは一度にすべて移行しないといけませんか？
いいえ、基幹システムは一度に全体を移す必要はなく、影響の小さい領域から段階的に移行するほうが、失敗したときのリスクを抑えられます。会計や人事給与など標準化しやすい領域から着手し、成果を確認しながら販売・生産へ広げていく進め方が現実的です。必要な業務から順に載せ替えられるクラウド型のERPを受け皿にすれば、一括刷新の負担を避けつつ段階的に移行を進めることもできます。
Q. マイグレーションが必要になるのはどんなときですか？
マイグレーションが必要になるのは、ハードウェアの老朽化やOS・製品の保守終了、性能の限界、古い技術を扱える技術者の減少、運用コストの増大など、現行システムを使い続けるリスクが高まったときです。とくに基幹システムでは、開発当事者の退職や仕様のブラックボックス化が進むと刷新の判断そのものが難しくなるため、保守終了などの明確な期限を機に検討を始めるケースが多く見られます。
ERPの料金・資料を一括チェック
MCB FinTechカタログでは、掲載中のERP（統合基幹業務システム）の資料をまとめてダウンロードできます。提供形態・対象規模・費用など、基幹システムの刷新先を比較検討するのに必要な情報を、各社からまとめて取り寄せる材料としてご活用ください。
一括ダウンロードする
MCB FinTechカタログに掲載しませんか？
MCB FinTechカタログでは、掲載企業様を募集しています。マネックスグループの金融実務ノウハウを活かした独自の評価軸と検索設計により、導入検討者が最適なサービスを効率的に発見できる法人向け比較プラットフォームです。掲載後は管理画面から料金表や導入事例を随時更新でき、常に最新の情報を訴求可能。まずは下記フォームより、お気軽にお問い合わせください。
マネックス証券 フィナンシャル・インテリジェンス部 暗号資産アナリスト
松嶋真倫
監修の範囲は記事の一般的な解説部分であり、比較表および各製品・サービスの紹介内容は監修の対象外です。
