マイグレーションとは？リプレイス・モダナイゼーションとの違いと発注判断を解説

マイグレーションは、既存システムの中身を引き継いだまま、動く土台だけを入れ替える移行です。この記事では、リプレイス・コンバージョン・モダナイゼーションとの線引き、対象で分かれる5つの種類、リホスト・リライト・リビルドという改修度別の手法、費用を左右する4つの要因を、発注者が見積書を読み解ける粒度で整理します。あわせて、AWSが公開する7つの移行戦略との対応、Microsoftが公開するサポート終了日から着手時期を逆算する手順、並行稼働で新旧データを突き合わせる検証クエリまで扱います。

まとめ：マイグレーションの全体像と、違い・費用・発注判断の要点

マイグレーションは、動いているシステムの中身をできるだけ引き継ぎながら、稼働する土台だけを新しくする移行です。プログラムを一から書き直すリプレイスや作り直しと違い、既存資産を残す分だけ投資を抑えやすい一方、老朽化した設計思想までは刷新できないという性格を持ちます。まずこの「資産を残すか、作り替えるか」の軸を押さえると、見積書に並ぶ移行方式の意味を読み解けるようになります。

種類は移行の対象で分かれ、データ・サーバー・ライブ・レガシー・クラウドの5タイプが代表例です。手法は改修の深さで分かれ、環境だけ移すリホスト、同じ仕様のまま書き換えるリライト、設計から作り直すリビルドの順に費用と期間が増えます。対象と改修度の二軸で自社の移行がどこに位置するかを見定めると、相見積もりの妥当性を判断しやすくなります。

着手時期は感覚で決めず、現行製品のサポート終了日から逆算します。費用には定価がなく、移行対象の規模と改修度、データ量、並行稼働の期間でほぼ決まります。金額そのものより「なぜその金額になるのか」を分解できる状態が、発注者にとっての防御線です。レガシー刷新を見据えてマイグレーションとリプレイスのどちらから相談すべきか迷うときは、現行システムの要件整理から移行設計までを一緒に見立てるシステムマイグレーション・リプレイスの相談窓口を起点にすると、判断の材料をそろえやすくなります。

マイグレーションとは｜意味とリプレイス・コンバージョン・モダナイゼーションの違い

マイグレーション（migration）は「移住・移行」を意味する英語で、IT分野では稼働中のシステムやデータを別の基盤へ移すことを指します。ここを起点に、混同されがちな周辺用語との線引きを先に済ませておくと、以降の種類や手法の話が整理して読めます。

マイグレーションの定義と、既存資産をそのまま引き継ぐという性格

マイグレーションの核心は、既存の資産を極力そのまま次の環境へ持ち越す点にあります。たとえばサーバーのOSサポートが切れるとき、業務ロジックはそのままにハードウェアと基盤ソフトだけを新しくすれば、業務を止めずに寿命を延ばせます。作り直しのように機能を一から設計し直すわけではないため、投資と期間を抑えられるのが利点です。反面、古い設計や構造上の弱点は引き継いだままになり、根本的な作り替えにはつながりません。老朽化が進んだ基幹システムそのものの問題については、レガシーシステムが抱える課題を整理した解説が背景の理解に役立ちます。マイグレーションは、その課題への対処法のひとつという位置づけです。

リプレイス・コンバージョン・モダナイゼーションとの違いを一覧で整理

これらは「何を変え、何を残すか」で線引きできる言葉です。リプレイスは既存を捨てて新しいものに置き換える発想、コンバージョンはプログラムやデータの形式を別の形式へ変換する作業、モダナイゼーションは古い仕組みを最新の技術体系へ現代化する取り組みを指し、その手法と進め方はモダナイゼーションの実装解説で整理しています。マイグレーションは、この中で最も「残す」に寄った選択肢だと捉えると位置づけがはっきりします。

実務では、ひとつのプロジェクトの中でこれらが組み合わさります。サーバーをクラウドへ移すマイグレーションの過程で、一部の古いプログラムをコンバージョンで書き換える、といった具合です。用語を厳密に切り分けるより、「今回の移行はどこまで作り替えるのか」を発注時に握っておくことが、認識のずれを防ぎます。

マイグレーションの種類｜移行する対象で分かれる5つのタイプと選び方

マイグレーションは、何を移すのかによって呼び名が変わります。相見積もりを取ると各社が別々の用語を使うことがあるため、対象別の分類を知っておくと、同じ土俵で比較できます。

データ・サーバー・ライブ・レガシー・クラウドの対象別5タイプ

代表的なのは次の5タイプです。上から順に、日常の移行で登場する頻度が高いものを並べています。

• データマイグレーション：データベースやファイルを別のシステムへ移す。文字コードやデータ形式の変換を伴い、欠損や不整合が起きやすい要注意領域。AWSへ移す場合の実装手段はAWS Database Migration Serviceとはで解説しています。
• サーバーマイグレーション：稼働するサーバーを新しいハードウェアや仮想環境へ移す。OSやミドルウェアのサポート終了が主な動機。
• ライブマイグレーション：仮想マシンを停止させずに、別の物理サーバーへ移す。無停止での保守を可能にする仮想化基盤の機能。
• レガシーマイグレーション：老朽化した旧式システムを、新しい基盤へ移す。COBOLやメインフレームからの脱却が典型。
• クラウドマイグレーション：オンプレミスのシステムをAWSやAzureなどのクラウドへ移す。運用の外部化とコスト構造の見直しが目的で、工程ごとの手順はクラウド移行の進め方を発注者視点で整理した解説にまとめました。

この5つは排他的ではありません。クラウドマイグレーションの中でデータマイグレーションが発生し、その対象がレガシーシステムであることも珍しくありません。自社の案件が複数タイプにまたがると分かれば、見積もりの範囲を切り分けて依頼できます。

ライブマイグレーションが仮想マシンを無停止で移し替える仕組み

ライブマイグレーションは、仮想化基盤ならではの移行方式です。物理サーバーの保守や交換が必要になったとき、その上で動く仮想マシンをメモリの状態ごと別のサーバーへ移すことで、利用者にはサービスを止めずに切り替えられます。VMwareのvMotionやMicrosoft Hyper-Vのライブマイグレーション機能が代表的で、24時間稼働が求められるシステムの計画保守を支える機能です。

仕組みの粒度は、ベンダー公式の記述を読むとつかめます。vSphere 8.0系のドキュメントは、vSphere vMotionによる仮想マシンの移行として、メモリ・レジスタ・ネットワーク接続を含む状態情報が移行先ホストへコピーされること、途中でエラーが起きた場合は元のホストと元の状態へ戻ることを説明しています。Hyper-V側のライブ マイグレーションの概要は、Windowsフェールオーバークラスタリングと組み合わせて高可用性の構成を作れる機能という位置づけです（いずれも2026年9月時点）。移行後に止めず動かし続ける体制は、システム運用の業務範囲を整理した解説で確認できます。

マイグレーションの手法｜リホスト・リライト・リビルドと改修度による選び方

対象別の種類に対し、手法は「どこまで手を入れるか」という改修の深さで分かれます。ここが費用と期間を最も左右する軸で、発注前に必ず握っておきたいところです。

改修の深さで並ぶ3つの手法と、費用・期間・リスクが変わる関係

代表的な手法を、改修の浅い順に並べると次のようになります。浅いほど安く速く済み、深いほど作り替えの効果が大きくなる代わりに投資が膨らみます。

リホストは「持ち上げてそのまま置く（lift and shift）」とも呼ばれ、最短で移行を終えられます。ただし古い設計をそのまま持ち込むため、移行後に性能や保守性の問題が残る点は理解しておく必要があります。リビルドは実質的にシステム開発のやり直しに近く、進め方は新規開発と同じ工程をたどる作業です。作り直しまで踏み込む場合は、システム開発の工程と依頼方法を整理した解説が全体像の把握に役立ちます。

AWSが定義する7つのRとリホスト・リライト・リビルドの対応関係

クラウドへ移す案件では、提案書に「7つのR」という分類が出てきます。AWSの規範的ガイダンスは7 R の移行戦略選択として、リホスト（再ホスト）、リプラットフォーム、リファクタリング（再構築）、リパーチェス（再購入）、リロケート（再配置）、リタイア（廃棄）、リテイン（保持）の7つを挙げています（2026年9月時点）。国内で通りのよいリホスト・リライト・リビルドと重なるのは前半の3つで、リライトはリプラットフォームとリファクタリングの中間と読み替えられます。

この分類が効いてくるのは、残る4つがあるからです。リパーチェスはSaaSへの乗り換え、リロケートは仮想化基盤ごと持ち上げる方式、リタイアは使われていない機能を移さずに捨てる判断、リテインは今回は手を付けず据え置く判断を指します。移行対象を棚卸しすると、一定の割合がリタイアとリテインに落ちます。切り分けを先に済ませるほど移行対象そのものが減り、費用も下がる構造です。見積もりを依頼する前に、サーバーとアプリの一覧をこの7分類で仕分けしておくと、払わなくてよい移行費を削れます。

手法選びで迷ったときは移行の目的から逆算するという判断の起点

手法は「現行システムへの不満がどこにあるか」から逆算すると選びやすくなります。ハードやOSの寿命だけが問題ならリホストで十分です。動きは問題ないが言語が古くて人材を確保できないならリライト、業務のやり方自体を変えたいならリビルドに進みます。一度に全体を移し替えるのが難しい大規模システムでは、機能単位で少しずつ置き換えるストラングラーフィグパターンによる段階移行と切り戻し設計も選択肢に入ります。逆に、明確な不満がないのに「せっかくだから作り直す」と広げるのは、費用が跳ね上がる典型パターンです。移行の目的を1つに絞ることが、手法選びのぶれを防ぎます。

マイグレーションの進め方｜企画から並行稼働・切替までの工程と失敗パターン

マイグレーションは、移す作業そのものより、事前の調査と移行後の検証に労力がかかります。工程を把握しておくと、ベンダーの提案書に抜けている段階を見抜けます。

サポート終了日から逆算して移行の着手時期を決める工程表の引き方

着手時期は、現行製品のサポート終了日から逆算して決めます。Microsoftのライフサイクル情報では、Windows Server 2016の延長サポート終了が2027年1月13日（太平洋時間の表記）とされ、この日を過ぎると通常のセキュリティ更新は提供されません。SQL Server 2016はすでに2026年7月15日（同表記）で延長サポートが終わり、有償のExtended Security Updatesへ移った状態で、同ページの記載ではYear 1の提供期間が2027年7月13日までとなっています（いずれも2026年9月時点）。

この日付から工程を逆に並べると、着手の遅れがどこに効くかが見えます。企画と現行調査、移行設計、移行作業、並行稼働の順に積み上がるため、期限の半年前に相談を始めると現行調査の途中で終了日を迎えがちです。逃げ道は2つ。有償の延長サポートを買って時間を作るか、サポート終了の対象だけを先に移すかになります。どちらも追加費用は出ますが、期限に追われて現行調査を省き切替後に不整合を出すより、総額では安く収まります。

企画・現行調査・移行設計・移行作業・並行稼働・切替の6つの工程

一般的な流れは、次の6段階に整理できます。特に見落とされやすいのが、現行調査と並行稼働の期間です。

1. 企画：移行の目的と対象範囲、達成条件を決める。ここで手法（リホスト等）を仮決めする。
2. 現行調査：既存システムの仕様・データ構造・連携先を棚卸しする。ドキュメントが失われた旧システムほど時間がかかる。
3. 移行設計：移行後の構成と、データをどう移すかの手順・変換ルールを設計する。
4. 移行作業：実際にデータとプログラムを新環境へ移す。少量データで試すリハーサルを挟む。
5. 並行稼働：新旧を一定期間同時に動かし、結果が一致するかを突き合わせる。
6. 切替：問題がないと確認できたら本番を新環境へ切り替え、旧環境を停止する。

並行稼働を省いて一気に切り替えると、移行後に発覚した不整合を戻せなくなります。無停止が絶対条件のシステムほど、この期間を厚く取る前提で見積もりを読むのが安全です。

並行稼働で新旧データを全件突き合わせる検証クエリの組み立て方と注意点

並行稼働で突き合わせるべきは、画面の見た目ではなくデータそのものです。移行元と移行先の両方で同じ条件のクエリを流し、件数と行内容のチェックサムを比べれば、文字コード変換で落ちた文字や桁あふれを機械的に検出できます。テーブル単位で件数だけを比べる検証では、値が壊れた行は見つかりません。次の形が最小の型になります。

-- 移行元と移行先で同じクエリを流し、件数とチェックサムを突き合わせる（MySQL 8.0系）
SELECT COUNT(*) AS row_count,
       SUM(CRC32(CONCAT_WS('|', id, order_code, customer_id, amount, updated_at))) AS checksum
FROM orders
WHERE updated_at < '2026-09-01 00:00:00';

-- PostgreSQL 16系なら md5 と string_agg で同じ突き合わせができる
SELECT count(*) AS row_count,
       md5(string_agg(rec, '' ORDER BY rec)) AS checksum
FROM (SELECT concat_ws('|', id, order_code, customer_id, amount, updated_at) AS rec
      FROM orders) AS t;

全テーブルをこの形で回し、チェックサムが食い違ったテーブルだけを目視で追うと、検証の工数を絞れます。注意点は3つ。ひとつはタイムスタンプの丸め方で、移行先の型が秒未満を切り捨てると、値は正しいのに数値だけがずれます。ふたつめはNULLと空文字の扱いで、連結関数の仕様差がそのまま差分として現れる点です。3つめは移行中も更新が走るテーブルで、AWS DMSの継続的レプリケーション（CDC）のようにフルロード後の変更を追いかける方式を併用する場合、突き合わせの基準時刻を固定しないと永久に一致しません。

外注でのマイグレーションで失敗する典型パターンと避けるための条件

マイグレーションの失敗は、技術より段取りで起きます。最も多いのが、現行システムの仕様が誰にも分からないまま移行を始め、動かして初めて仕様漏れが露呈するパターンです。旧システムの担当者が退職済みで、設計書も古いまま——この状態で「とりあえず移してから直す」と進めると、テスト工程で想定外の手戻りが連鎖します。防ぐ条件は明快で、企画段階で現行調査に予算と期間を割り当て、仕様が判明するまで移行設計に進まないことです。金融機関の合併に伴う統合では検証の水準がさらに上がるため、金融機関のシステム統合における方式選択と移行検証の進め方で個別に整理しました。安さだけで現行調査を省く提案を選ばないことが、結果的に総額を抑えます。移行の検証を軽視した結果として切替直後に出荷が止まった実例は、基幹システム刷新の失敗事例と回避策で確認できます。

マイグレーションの費用｜金額を左右する要因と、見積もりの読み方

マイグレーションには保守費のような相場比率がなく、案件ごとに金額が大きく振れます。だからこそ、金額の絶対値ではなく「何が費用を押し上げているか」を分解して読む力が、発注者の武器になります。

移行の規模・改修度・データ量・並行稼働が費用を左右する4つの要因

費用は、いくつかの要因の掛け算で決まります。第一に移行対象の規模で、サーバー台数やプログラム本数、連携する外部システムの数が多いほど調査と検証の工数が増える要因です。第二に改修度で、前述のとおりリホスト・リライト・リビルドの順に費用が上がります。第三にデータ量と複雑さで、大量データの変換や、形式がばらばらな旧データの整備には相応の工数が必要です。第四に並行稼働の期間で、新旧を同時に動かす分だけ運用コストが二重に発生します。見積書を受け取ったら、この4要因のどれで金額が積み上がっているかを質問すると、水増しや過剰なスコープを見抜けます。

移行後にかかり続ける費用まで含めて総額で見積もりを比べる視点

マイグレーションの費用を初期の移行費だけで比べると、判断を誤ります。クラウドへ移せば月額の利用料が新たに発生し、新環境の保守運用にも継続的な費用がかかります。移行によって保守費がどう変わるかは、移行前後で並べて総額を見るのが確実です。移行後の保守にどの費用が含まれるかは、システム保守の費用相場と契約形態を整理した解説で分解しておくと、移行費との合算で予算を組めます。サポート終了後の延長サポートを買う場合、その費用も同じ表に並べてください。初期費用の安さに引かれて、月額と保守費が割高な提案を選ぶと、数年で逆転することもあります。

マイグレーション・リプレイス・作り直しの判断軸｜発注者が投資先を決める基準

ここが発注者にとっての本題です。移行が必要だと分かっても、資産を残すマイグレーションで済ませるか、思い切って作り替えるかで、投資額も得られる効果もまったく変わります。条件を示したうえで言い切ります。

現行システムへの満足度と、この機会に業務を変えたいかどうかで選ぶ

判断は2つの問いに絞れます。ひとつは「今のシステムの業務ロジックに満足しているか」、もうひとつは「この機会に業務のやり方を変えたいか」です。業務ロジックに不満がなく、単に基盤の老朽化だけが問題なら、資産を残すマイグレーション（リホスト中心）が最も費用対効果に優れる選択です。そもそも今このシステムに着手すべきかという前段の判断は、レガシーシステム脱却の判断基準と進め方で据え置きとの5年総額比較まで含めて扱っています。一方、業務のやり方そのものを変えたい、あるいは現行の設計が事業の足かせになっているなら、資産を捨てて作り直すリプレイス・リビルドに投資する価値があります。判断がつかないまま「安いから」でマイグレーションを選ぶと、古い業務フローごと新環境に固定してしまい、数年後に結局作り直す羽目になりがちです。まず業務を変えたいかを決め、そのうえで技術的な移行方式を選ぶ順序が失敗を防ぎます。

マイグレーションを見送るべき場面と、作り直しに振り替えるべき条件

マイグレーションが適さない場面もはっきりしています。第一に、現行システムの仕様がブラックボックス化し、資産を引き継ぐ価値より解読コストが上回る場合です。この状態で無理に資産を残すと、正体不明のプログラムを新環境で延命するだけになります。第二に、事業の方向転換で必要な機能が大きく変わる場合で、古い機能を移しても使われません。購買や販売のように業務パッケージが成熟している領域では、資産を移すよりリプレイスで刷新する条件とデータ移行の進め方を先に検討したほうが、投資の回収が早くなります。この条件のどれかに当てはまるなら、マイグレーションではなく要件定義からの作り直しに振るべきです。逆に、仕様が明確で業務も安定しているなら、作り直しは過剰投資になります。自社がどちらに該当するか判断しきれないときは、現行システムの調査と移行方式の見立てを含めて、システムマイグレーション・リプレイスの相談窓口で現行分析から相談すると、投資判断の根拠をそろえられます。

マイグレーションの違い・費用・進め方に関するよくある質問と回答

マイグレーションの検討でよく挙がる疑問を、発注者の視点でまとめました。

マイグレーションとリプレイスの違いは何ですか？

既存の資産を残すか、捨てるかが最大の違いです。マイグレーションは現行のデータやプログラムを引き継いだまま稼働環境を移すため、投資を抑えやすい反面、古い設計は残ったままです。リプレイスは既存を捨てて新しいシステムに置き換えるため、費用と期間はかかりますが、設計から刷新できます。基盤の老朽化だけが問題ならマイグレーション、業務や設計ごと変えたいならリプレイスが向きます。

マイグレーションの費用相場はどれくらいですか？

定価はなく、移行対象の規模、改修度（リホスト・リライト・リビルド）、データ量、並行稼働の期間で決まります。環境だけ移すリホストが最も安く、設計から作り直すリビルドに近づくほど高くなる関係です。見積もりを受け取ったら、この4つの要因のどれで金額が積み上がっているかを確認すると、妥当性を判断できます。クラウド移行の場合は、移行後の月額料金も総額に含めて比べてください。

ライブマイグレーションとは何ですか？

稼働中の仮想マシンを停止せずに、別の物理サーバーへ移す仮想化基盤の機能です。物理サーバーの保守や障害対応が必要になったとき、その上の仮想マシンをメモリの状態ごと移すことで、利用者にサービスを止めずに切り替えられます。VMwareのvMotionやHyper-Vのライブマイグレーションが代表例で、無停止が求められるシステムの計画保守に使われる機能です。vMotionの公式ドキュメントには、移行中にエラーが起きた場合は元のホストと元の状態へ戻ると記載されています。

マイグレーションはいつ着手すればよいですか？

現行製品のサポート終了日から逆算して決めます。Microsoftのライフサイクル情報では、Windows Server 2016の延長サポート終了は2027年1月13日（太平洋時間の表記）、SQL Server 2016は2026年7月15日で延長サポートを終えて有償のExtended Security Updatesに移っています（2026年9月時点）。企画と現行調査、移行設計、移行作業、並行稼働を順に積み上げると相応の期間になるため、期限の半年前では現行調査で時間切れになりがちです。間に合わないと分かった時点で、延長サポートの購入か対象の絞り込みを検討してください。

マイグレーションとモダナイゼーションはどう違いますか？

マイグレーションは資産を残して環境を移すこと、モダナイゼーションは古い技術体系や設計を最新の形へ作り替えることを指します。マイグレーションは「残す」に、モダナイゼーションは「作り替える」に重心があるという違いです。実務では、クラウドへのマイグレーションを機にアーキテクチャを現代化する、といった形で両者が組み合わさることも多くあります。開発現場で使うデータベースのマイグレーション（テーブル定義をバージョン管理しながら変更する作業）は、これらとは別の意味なので混同しないでください。

関連記事

• レガシーシステムとは何か、その意味・定義や歴史的背景、企業経営への影響を現代ビジネスの視点から詳しく解説：マイグレーションを検討する動機となる、老朽化システムの課題を整理できます。
• クラウド移行の進め方｜計画から移行方式・費用・切り替えまでの手順を発注者視点で解説：移行先をクラウドに定めた場合の工程と切り替え手順を確認できます。
• システム保守とは？運用との違い・費用相場・契約形態を発注者視点で解説：移行後にかかり続ける保守費を、移行費と合算して予算を組むための解説です。
• システム運用とは？保守との違い・業務一覧から委託判断まで発注者視点で解説：移行後にシステムを止めず動かし続ける運用体制を確認できます。
• システム開発とは？種類・工程・依頼方法までの全体像をわかりやすく解説：作り直し（リビルド）まで踏み込む場合の開発工程を確認できます。