一括切り替えか、段階移行か：業務を止めない移行計画の作り方
新システムが完成しても、そのまま業務を移せるとは限りません。旧システムで処理中の注文、締め前の残高、承認待ちの申請、送信済みか判別しにくい外部連携など、切り替え時点にはさまざまな途中状態が残っています。
一括切り替えか、段階移行かを選ぶ際には、画面やプログラムの完成度だけでなく、これらの状態をどこで引き継ぎ、どう検証するかを考える必要があります。
「業務を止めない」とは、必ずしも停止時間をゼロにすることではありません。許容できる停止時間と、守るべき取引・データを先に定め、その条件を満たす移行を設計することです。
一括と段階では、難しさが現れる場所が違う
観点 | 一括切り替え | 段階移行 |
切り替え単位 | 対象範囲を決めた時点でまとめて移す | 業務・拠点・利用者などの単位で順に移す |
主な負担 | 移行作業、データ検証、判断を短時間に集中させる | 新旧連携、同期、運用ルールを一定期間維持する |
業務への影響 | 失敗時の影響範囲が広くなりやすい | 影響を限定しやすいが、共通データから波及する場合がある |
データ上の課題 | 最終差分と処理中データを期限内に移す | どちらが更新権限を持つかを段階ごとに管理する |
利用者教育 | 対象者への教育を切り替え前にそろえる | 段階ごとの操作と新旧の使い分けを周知する |
終了条件 | 全体の受入と旧環境の扱いを確定する | 各段階の受入に加え、暫定連携を撤去する |
段階移行が常に安全とは限りません。処理を分けにくい共有データが多い場合、新旧を併存させること自体が複雑になります。一括切り替えも、対象が独立していて移行を繰り返し検証できるなら、有力な選択肢になります。
段階的な置き換えの代表的な考え方として、旧システムの機能を少しずつ新しい実装へ移すStrangler Figパターンがあります。ただし、途中で新旧の依存関係が残るため、境界の設計が必要です。
Microsoft「Strangler Figパターン」(https://learn.microsoft.com/en-us/azure/architecture/patterns/strangler-fig)
並行稼働は「両方で動かす」だけでは決まらない
並行稼働という言葉には、性質の異なる運用が含まれます。
一つは、旧システムを正式な処理系とし、新システムでは同じ入力を使って結果だけを比較する方法です。この場合、新システムから請求書や通知を実際に送ったり、在庫を確定したりしないよう、外部への作用を制御します。
もう一つは、移行済みの業務や利用者は新システムを正式に使い、残りは旧システムを使う方法です。こちらの方法では、結果の比較に加えて、取引やマスターが境界を越えるときの整合性も問題になります。
仮の例として、受注だけを先に新システムへ移し、出荷と請求を旧システムに残す場合を考えます。注文の作成は連携できても、出荷後の数量訂正、締め後の取消、返品による請求修正が正しく伝わるとは限りません。通常の登録処理よりも、状態が戻る操作や例外処理を先に確認する必要があります。
データ同期の前に、更新の責任を決める
同期方式を選ぶときは、まず業務データごとに「どちらを正本とするか」を決めます。両方から同じ情報を自由に更新できる状態を作ると、後から競合の解決が難しくなります。
決めること | 設計時の問い |
更新権限 | 顧客、注文、在庫などを、どちらのシステムが変更するか |
データ識別 | 新旧IDをどう対応させ、同じ取引を追跡するか |
同期の範囲 | 追加・変更だけでなく、取消・削除・状態変更をどう伝えるか |
順序と遅延 | 更新順が前後した場合、古い状態で上書きされないか |
再送と重複 | 同じ連携が再送されても、二重計上や二重通知を防げるか |
照合と補正 | 差分を誰が検出し、どの証跡に基づいて修正するか |
CDCのようにデータベースの変更を取得する仕組みを使っても、業務上の意味や処理順、複数データをまとめて確定する条件の問題までは、自動的に解決しません。構造の変換や再送時の扱いを含めて設計します。
また、件数が一致しても、内容が一致するとは限りません。キー単位の照合、金額・数量の集計、処理状態、参照関係、必要に応じたチェックサムなどを組み合わせて確認します。許容差がある場合は、その理由と承認者を先に決めておきます。
切り替え判定を、その場の雰囲気に任せない
本番当日に「おおむね問題なさそう」と判断すると、重要な未確認事項が残る可能性があります。実施可否を決めるGo／No-Go基準は、リハーサル前に具体化します。
確認するのは、移行データの照合結果、主要業務の受入、外部接続、処理時間、監視、当日の要員、問い合わせ窓口などです。重大な未解決障害の扱い、同期遅延の許容範囲、切り戻しを完了できる最終判断時刻も定めます。
AWSの切り替え準備ガイダンスでは、作業順序・担当者・所要時間を含む実行手順書と、リハーサル、切り戻し手順の準備が示されています。計画を文章にするだけでなく、当日に実行・記録できる形に整えるときの参考になります。
AWS「Pre-cutover stage」(https://docs.aws.amazon.com/prescriptive-guidance/latest/best-practices-migration-cutover/pre-cutover-stage.html)
リハーサルは、データを入れるところで終えません。最終差分の反映、利用者による代表業務の確認、通知・帳票・バッチの起動、監視開始まで通して行います。担当者が交代しても実行できるかを確かめると、手順の曖昧な点が見つかります。
切り戻しは、新しい取引が入った瞬間に難しくなる
切り替え前のバックアップがあれば、いつでも元に戻れるとは限りません。新システムで受注や入金を受け付けた後に旧環境へ戻すなら、その間の取引をどう引き継ぐかを決めておく必要があります。
さらに、メールの送信、商品の出荷、外部サービスへの依頼など、データベースを戻しても取り消せない処理があります。これらの処理は、実行済みの記録と照合して再送を防ぎ、必要な補償処理や手続きを行う設計にします。
AWSも、新しいデータが発生する前の切り戻しと、発生後の切り戻しを区別しています。後者では、データの扱いも論点に加わります。
AWS「Cutover stage」(https://docs.aws.amazon.com/prescriptive-guidance/latest/best-practices-migration-cutover/cutover-stage.html)
そのため、計画には「戻す手順」に加えて、「戻せる条件」と「戻すより新環境で修復すべき条件」を記載します。逆方向のデータ反映ができるか、変換で情報を失っていないか、外部処理を再実行せずに復旧できるかを検証し、判断責任者を決めます。双方向書き込みを追加するだけでは、途中失敗時の不一致を解決できません。
利用者教育と、併存を終える計画まで含める
教育では、新しい画面の使い方だけでなく、「どの日から、どの業務を、どちらで行うか」を具体的に伝えます。特に段階移行では、旧システムで受け付けた案件を新システムで訂正する場合など、境界をまたぐ操作が重要です。
担当業務ごとの演習、よくある例外への案内、切り替え直後の問い合わせ体制を用意します。初回の締め処理や繁忙期も、移行後の確認対象に含めます。
旧環境は、主要機能を切り替えただけで廃止できるとは限りません。保存すべき履歴、参照用の帳票、取り残された連携、監査上の確認を整理し、停止条件を明確にします。段階移行では、暫定同期や二重運用をいつ終えるかも決めておく必要があります。
株式会社Managetechが移行計画で重視するのは、機能を移す順序と、取引を守る手順を一体で考えることです。切り替え単位、データの更新責任、判定条件、復旧方法、利用者の行動がそろって、実行可能な計画になります。
一括か段階かを決める前に、業務上許容できる停止と損失、途中状態の引継ぎ、新旧の依存関係を整理してみてください。その条件が、適切な移行方式を選ぶ手掛かりになります。
コメント