レガシーシステム移行・マイグレーションの進め方：全体の構成と順序、方式選定・データ検証・切替の確認リスト

「古いから作り直す」という理由だけでは、移行先の選定や予算の判断があいまいになります。現在の問題を次のように分け、どの問題を今回の移行で解消するかを決めます。

たとえば、機器の保守期限とアプリの変更の難しさが重なっていても、一度の移行で両方を解決するとは限りません。期限に対応する作業と、業務を作り替える作業を分けて検討します。

経理、販売、購買、在庫、給与などの業務について、業務の担当者とシステムの担当者で一覧を作ります。サーバーに加えて、SaaS、Excel、ファイル転送、夜間バッチ、外部ベンダーの作業も対象に含めます。

一覧の各機能に「移す」「置き換える」「当面残す」「廃止を検討する」を付け、判断の理由と未確認事項を記録します。長期間使っていない機能でも、年次業務や過去の問い合わせで必要な場合があるため、利用部署の確認なしに廃止しません。現行機能をすべて再現することを要件にすると、不要な複雑さまで引き継ぎます。業務の流れから整理する場合は、プロセス指向アプローチ（POA）の進め方も参考になります。

AWSの移行ガイドが示す「7つのR」は、移行方式を比べる枠組みとして使えます。ただし、実際の選定ではアプリの対応状況、業務の変更、検証に使える期間を確認します。この記事では、主な選択肢を次のように整理します。

7つのRの残りの1つであるRelocateは、仮想化環境などを基盤の単位で移す選択肢です。方式の名前を選んだだけでは、計画は決まりません。システムの部分ごとに方式を組み合わせる場合もあります。

特にRehostは、原則としてアプリを変えずに移すため、現行のプラットフォームの問題を持ち越す場合があります。サポート終了への対応が目的なら、移行先での更新や互換性の確認を別に計画します。

費用は、移行作業に加えて、新旧の並行運用、ライセンス、データの検証、教育、保守、将来の解約・変更も含めて比べます。方式の名前だけで金額や期間の相場を決めないようにします。

前の節の方式は、システムの部分ごとの選択です。複数のシステムやSaaSが連携している会社では、部分ごとの方式を決めただけでは、移行の途中で業務が止まらないかを判断できません。移行の作業に入る前に、全体で目指す構成と、どの順に移すかを決めます。

• 目指す構成：移行の後に残るシステム・SaaSと、それぞれが担う業務
• 正とするデータ：顧客、商品、取引などのデータごとに、どのシステムの記録を正しいものとするか。移行の途中の段階ごとにも決める
• ID・権限の基盤：アカウントをどこで発行し、どの方法で認証し、権限をどこで付けるか
• 連携の方法：データをどのタイミングで、どの方法で受け渡すか。失敗したときの再処理と、重複の防止

全体の構成は、現行の構成を続ける、一部を置き換える、複数のシステムを統合する、などの選択肢を、業務への影響、費用と体制の前提、リスク、依存関係で比べます。比べた結果と、選んだ案の理由、会社が決める事項を記録に残します。

一斉に切り替えるか段階的に移すかは、業務とデータの依存関係で選びます。段階的な移行は影響を限定しやすい一方で、新旧の連携や二重の運用が増える場合があります。段階ごとに、次の表の内容を決めます。

たとえば、旧システムの手前で特定の機能へのリクエストだけを新システムへ振り分け、対象を少しずつ広げる方法（ストラングラー・フィグ・パターン）では、振り分けた機能のデータをどちらのシステムで更新するかを明確にします。

新旧の結果を比べる並行稼働を行う場合は、月次の締めなど確認すべき処理の周期と、二重入力の負荷を踏まえて期間を決めます。期間を短くすることだけを目的に、必要な確認を省きません。

新旧をつなぐ方法の一つがAPI連携の設計です。既存システムにAPIを追加できない場合もあるため、接続の条件は事前に確認します。

ここで決める構成・順序・受入の条件は、実装や移行の作業とは分けて検討でき、設計だけを先にご依頼いただくこともできます。設計の結果を、社内、既存のベンダー、新しい開発会社など、実装・移行・切替を担う先へ引き継ぎ、担う先と範囲、費用を決めてから作業に進みます。全体の構成と移行の順序の設計を外部に頼む場合の進め方は、ITアーキテクチャ設計の支援内容で紹介しています。

すべてのデータを新しいシステムへ載せる必要があるかは、業務での利用と保存・参照の条件で判断します。現役の取引、過去の照会に使う履歴、保存が必要な記録を分け、旧環境を止めた後も必要な情報を取り出せる方法を決めます。会計帳簿や取引の記録は、法人税法、会社法、電子帳簿保存法などで保存の期間や方法が定められているため、経理責任者や税理士に保存の要件を確認します。要件を確認しないまま、古いデータを一律に捨てたり、一定の年数分だけ移したりしません。

重要な金額や残高の差異など、許容しないものを事前に定めます。件数全体に占める割合が小さいという理由だけで、重要な差異を見逃さないようにします。業務責任者が差分を説明できない場合は、切替の判断に進みません。重複したマスタの統合や表記の統一は、移行前に行うか移行後に行うかを決め、新しいシステム側で例外処理を増やさないようにします。

切替の前に、担当者、予定時刻、確認結果、進めるか止めるかを判断する人を記載した計画を作ります。停止できる時間は、利用部署と取引先・連携先への影響を踏まえて合意します。

切り戻しでは、新しい環境で受け付けた取引を旧環境へどう戻すかを、先に決めておきます。バックアップがあるだけでは、切替後の更新を含めて戻せるとは限りません。戻せない操作がある場合は、その操作を始める前の判断点と、失敗したときの回復方法を決めます。

性能や処理時間の目標は、現行の測定結果と業務に必要な条件から定めます。すべてのシステムに同じ秒数や不整合率を当てはめず、条件を満たさないときの判断と対応をリハーサルで確認します。

新しいシステムのリリース後も、監視、権限の変更、バックアップ、障害対応、問い合わせが回るかを確認します。旧環境の停止は、残る参照業務、データの保持、連携、契約を確認してから行います。受入の際は、業務責任者と運用責任者で次の項目を確認します。保守費やライセンスの見直しを含む場合は、ITコスト適正化の実務もあわせて整理します。

資料を作り込む前に、不明な仕様、保存の条件、接続の制約を洗い出します。説明できない事項が多い場合は、移行の見積もりより先に、調査の対象と成果物を決めると、方式の選び直しを減らせます。