既存システムを段階移行する：データの正本・切り替え・戻す条件の設計

2026年10月25日 · 約9分で読めます

ストラングラーパターンで画面を切り替えても、データ移行は終わりません。受注システムの刷新を例に、既存挙動の記録、更新責任の移譲、業務単位の突合、書き込み後の復旧、旧系を廃止する条件まで整理します。

段階移行は、切り替えられる業務の境界を探すところから

受注システムを刷新するとき、全機能を作り直して最後の週末に一括で切り替える計画は、既存の隠れた仕様を終盤まで見つけにくくします。ストラングラーパターンでは、入口などで旧系と新系を振り分け、一部ずつ置き換えます。AWSの説明でも、振り分けを担う層を使って徐々に機能を移す構成を扱っています。

切り替え単位は、画面URLだけでなく、業務とデータの依存で決めます。同じ注文の作成・変更・取消が新旧を行き来すると、更新を見落とす原因になります。対象テナントや注文IDなどで安定して振り分け、複数テナントをまたぐ集計・バッチがあるなら、その依存も移行計画に含めます。

既存の挙動を記録し、残す仕様と変える仕様を分ける

画面とAPIだけを読むと、夜間バッチ、CSV連携、手作業の修正が抜けます。注文1件を、入力から在庫確保、出荷、取消、請求まで追い、読み書きする経路を洗い出します。仕様が不明な部分は、代表入力に対する出力とDB更新をテストとして記録します。

通常の注文に加え、取消済み、境界の日付、欠損した連携データ、重複した要求を含める。金額・状態・順序の意味を業務担当と確認する。
時刻や生成IDの揺れだけを必要な範囲で正規化する。重要な差分まで消さない。検証データは匿名化・合成し、必要な権限で扱う。
現行挙動を記録したことと、それが正しいことを区別する。不具合を変える場合は、変更理由と新しい期待値を合意する。

各段階の正本と更新できる側を表にする

段階	対象データの正本・書き込み	読み取りと確認
準備	旧系だけが更新	旧系で業務を続け、新系へ初期データと変更を転送
シャドー比較	旧系だけが更新	利用者には旧系の結果。新系の読み取りを別に比較
参照の試験公開	旧系だけが更新	対象の参照を新系へ。同期の遅れと業務への影響を測る
更新責任の切り替え	対象の書き込みを一時停止し、処理中の更新を完了させる	確定した位置まで同期・突合し、旧系の更新を封じる
新系での業務	対象は新系だけが更新	参照も新系へ。旧系への反映が必要なら用途と方式を限定

データ転送には変更データキャプチャ（CDC）やOutboxなどを検討します。CDCで行を複製しても、新系の業務上の意味が一致するとは限りません。状態の変換、削除、版の順序、重複、再開位置を決めます。「新旧に同じAPI要求を送る」だけの二重書き込みは、片方だけ成功する経路を残します。

旧系の書き込みを止める対象には、画面とAPIだけでなく、バッチ、管理ツール、遅れて届くジョブやWebhookも含めます。入口のフラグを変えても、すでに動いている処理は止まりません。旧系が対象を更新できないことを権限や所有状態の確認などで強制し、切り替え中の要求は明示的に待たせるか再試行可能な失敗として扱います。

シャドー比較と突合は、同じ対象・同じ時点で行う

シャドー検証では、利用者の要求に対する新系の結果を裏で比べます。通知・課金・在庫更新などの副作用は起こさない専用経路を使います。読み取りだけでも旧DBへの負荷が増えるため、対象数や頻度を制限します。

旧系も新系も10万件なら移行成功、とは言えません。注文Aの欠落と注文Bの混入で件数は一致します。AWS DMSのデータ検証も、対応する行の比較と不一致の報告を行い、検証自体に追加の資源が要ることを説明しています。スキーマの異なる移行では、その上に業務の変換規則の検証が必要です。

突合するもの	比較の条件	不一致の扱い
注文ID・状態・金額・通貨	同じ対象範囲、同じ変換規則	欠落、余分、値の差を別に記録
更新の版・削除状態	同期の確定位置や比較用のスナップショットをそろえる	同期中、本当の不一致、確認不能を区別
出荷・取消・通知などの業務結果	同じ業務IDと処理段階	外部の結果を照会し、再実行の要否を判断

常に更新されるデータを別の時点で読むと、正常な同期遅延も差分になります。比較の基準となる位置を明示し、未比較の件数と本当の不一致を分けて追います。同期の遅延メトリクスが0に見えるだけで、全対象の反映を確認済みにしないようにします。

切り替えは、書き込み停止から再開まで予行する

対象を短時間停止できる場合の更新責任の移譲。各工程の失敗・再開も予行する

対象の新規書き込みを止め、処理中の旧系更新を完了 → 最後の更新位置を確定し、その位置まで新系へ反映 → 業務ID・状態を突合し、未確認と不一致を解消 → 旧系の対象更新を封じ、経路と所有状態を新系へ変更 → 新系の書き込みを再開し、業務結果と滞留を確認

予行には、本番に近いデータ量と偏り、ロック待ち、同期の滞留、途中停止と再開を含めます。所要時間を測り、停止可能な時間内に収まらない場合は方式を見直します。切り替えを担う入口自体の容量、可用性、設定変更の伝播も確認します。

互換性を壊すスキーマ変更は、追加して新旧両方を使えるようにし、利用側を移してから旧形式を削除するexpand-contractで段階化できます。ただし、使える列を残すだけではデータの意味や値の互換性は保証されません。旧系が読む形式への変換と、並行して動く版も検証します。

新系で書いた後は、経路だけ戻しても復旧しない

戻したい時点	確認する条件	復旧の考え方
新系は参照だけ	旧系が正本のまま更新されている	参照を旧系へ戻し、キャッシュや経路の状態を確認
新系で更新を受けた後	新系の更新・削除を旧系で表現でき、欠落なく反映できる	対象の更新を止め、逆変換・突合後に更新責任を旧系へ戻す
旧系で表せない状態や外部の副作用がある	経路変更だけでは安全な復旧条件を満たさない	影響を抑え、新系の修正や業務上の補償を含む手順で復旧

新系でしか表せない注文状態を作った後に旧系へ戻すと、データを失ったり誤った処理をしたりします。ロールバック可能な期間は、旧系と互換な更新に制限する案もあります。逆方向の反映を行うなら、両側が同時に正本にならないように更新責任を切り替えます。課金や送信済み通知はDBを戻しても取り消されないため、結果確認と業務上の補償を分けて扱います。

旧系の廃止条件まで、移行の完了に含める

対象の参照・更新・バッチ・外部連携が新系へ移り、残る旧系利用者がいないことを利用状況で確認する。
合意した観測期間で品質と業務結果を確認し、未処理・不一致・確認不能を解消する。
復旧手順、バックアップ、運用権限、担当の引き継ぎを試し、暫定の同期や振り分けの撤去を担当付きで計画する。
必要な履歴の保存条件を満たしたうえで、旧系のアクセス権限と認証情報を失効し、不要な資源を廃止する。

段階移行では、共存のためだけの仕組みも必要になります。その維持費を見積もり、撤去の条件を設計時点で決めます。新しい画面が動いたことに加えて、業務結果と更新責任の移譲を確認できて初めて、次の移行単位へ進めます。