新しいシステムを作り終えても、今動いているものから乗り換えるという難所が残ります。移行方式は3つに整理でき、それぞれ速さ・安全・費用のどれを取ってどれを諦めるかが違います。設問はほぼ必ず「戻せるか」を聞いてきます。
先に押さえる
移行で動かすものは2つ。利用者と業務（どの時点から新しい画面を使うか）と、データ（過去の実績をどこまで持っていくか）です。この2つは分けて考えます。データだけ先に移して、利用は後からという段取りもあり、そこが計画の腕の見せ所になります。
3つの方式
一斉に切り替える
- ある日を境に全部を新しい方へ
- 速く、費用も低い（二重運用が無い）
- 失敗したときの影響が全体に及ぶ。停止時間の見積りが命
少しずつ移す
- 部門や機能、拠点の単位で順番に
- 影響を小さく抑えられ、学習しながら進められる
- 移行期間中は新旧が混在し、その間のつなぎが要る
しばらく両方動かす
- 一定期間、新旧の両方に同じ入力をして結果を比べる
- いちばん安全。結果の突き合わせで移行前に誤りに気づける
- 現場の負担と費用が二重にかかる。長くは続けられない
共通して要るもの
- 戻す手順（どこまで進んだら戻せなくなるか）
- 判断の期限と基準（何時までに何が出来ていなければ中止か）
- 移行後の確認項目（何を見て成功と判断するか）
つまずきポイント
見落とされるのはデータの中身です。形式は変換できても、旧システムで許されていた不整合（必須のはずが空、コードの体系が違う、重複がある）は新システムで弾かれます。だから移行では事前にデータを調べて、直す・捨てる・そのまま持つを決める作業が要ります。当日に気づくと止まります。
切替え当日の組み立て
1止められる時間から逆算する
業務を止められる時間連休・夜間など。ここが上限
↓データ移行・確認・切替えが収まるか
中止を判断する時刻ここを過ぎたら戻す作業が間に合わない先に決めておく
↓収まらないなら方式を変える
段階移行・並行稼働へ一度に運ぶ量を減らす
見抜きどころ
問題文の「業務を止められる時間」と「移行するデータ量」が、方式選択の材料です。答案は「止められる時間に収まらないため、段階移行にする」のように制約から方式を導く形で書きます。加えて中止の判断時刻と戻し方に触れると、実務性のある解答になります。「慎重に移行する」では点になりません。
移行が終わってからが本番
切替え直後は問い合わせが増えるのが普通です。操作に不慣れな期間を見込んで、問い合わせ窓口を厚くする・旧画面の参照だけ残すといった手当てを計画に入れます。移行の成否は、切替え作業ではなくその後数日を業務が回ったかで判断されます。