最終更新日：2026年7月22日
fe fe-management system-development
まず結論
システム移行計画では、新システムへの切替え手順だけでなく、失敗した場合に旧システムへ戻す条件と手順まで決めておくことが重要です。
基本情報技術者試験では、次のように判断します。
移行失敗時の判断基準・復旧手順
→ 必要
大量データを切替え直前に一括移行
→ リスクが高い
新旧システムの一部環境を共有
→ 確認しにくくなる
新旧システムを並行運用
→ 安全性は高まるが、費用は増えやすい
直感的な説明
システム移行は、引っ越しに似ています。
新しい家へ荷物を運ぶだけでなく、次のことも考える必要があります。
- いつ引っ越すか
- 何を先に運ぶか
- 荷物が足りないときにどう確認するか
- 新居で生活できないときに元へ戻れるか
システム移行でも同じです。
旧システム
↓ データ・業務・設定を移す
新システム
ただし、切替え後に重大な障害が起きると、業務が止まる可能性があります。
そのため、移行計画では、
どの状態なら移行成功とするか
どの状態なら切り戻すか
誰が判断するか
どうやって旧システムへ戻すか
まで決めておきます。
定義・仕組み
システム移行計画とは、旧システムから新システムへ、業務、データ、プログラム、利用環境などを安全に移すための計画です。
主な検討事項は次のとおりです。
| 検討事項 | 内容 |
|---|---|
| 移行対象 | データ、プログラム、設定、端末、業務手順など |
| 移行方式 | 一括移行、段階移行、並行運用など |
| 移行手順 | 実施順序、担当者、日時、作業時間 |
| 確認方法 | 件数、金額、データ内容、処理結果の照合 |
| 切替え条件 | 新システムへ切り替えてよい判断基準 |
| 切り戻し条件 | 旧システムへ戻す判断基準 |
| 復旧手順 | 旧システムへ戻す具体的な方法 |
| 教育・周知 | 利用者への説明、操作教育、問い合わせ対応 |
切り戻しとは
切り戻しとは、移行に失敗した場合や重大な問題が発生した場合に、移行を中止して旧システムの状態へ戻すことです。
切り戻しでは、次を事前に決めておきます。
切り戻しを判断する基準
判断する責任者
切り戻しを開始する時刻
旧システムの再開手順
新旧データの整合方法
利用者への連絡方法
判断基準がないと、問題が起きたときに「このまま新システムを使うか」「旧システムへ戻すか」を決められません。
一括移行と段階移行
一括移行
旧システムから新システムへ、ある時点でまとめて切り替える方式です。
短期間で切替え可能
ただし失敗時の影響が大きい
段階移行
業務、拠点、機能、データなどを分けて、複数回に分けて移行する方式です。
影響範囲を小さくできる
ただし移行期間が長くなりやすい
大量のデータを扱う場合は、事前移行と差分移行を組み合わせることがあります。
事前に大部分を移行
↓
切替え直前に差分だけ移行
これにより、切替え時の作業時間と失敗時の影響を抑えられます。
並行運用とは
並行運用とは、一定期間、旧システムと新システムを同時に動かし、結果を比較しながら移行する方式です。
旧システムの結果
と比較
新システムの結果
確認しやすく、安全性は高まります。
一方で、二つのシステムを維持するため、次の負担が増えます。
- 運用費
- 入力作業
- データ管理
- 利用者の負担
したがって、並行運用は一般に「費用を低減する方式」ではありません。
公式の出題範囲やシラバスは、IPA：基本情報技術者試験から確認できます。
科目Aでどう出る？
科目Aでは、移行計画として適切な記述を選ぶ問題が出ます。
選択肢を切る判断基準
| 問題文の表現 | 判断 |
|---|---|
| 失敗時に旧システムへ戻す判断基準を決める | 適切 |
| 大量データを切替え直前にすべて一括移行する | リスクが高い |
| 新旧システムで環境の一部を共有する | 確認が難しくなる可能性 |
| 並行運用すると費用が低減する | 誤り |
切り戻しの判断
次の言葉があれば、切り戻しを考えます。
移行失敗
重大障害
旧システムへ戻す
中止基準
復旧手順
移行計画には、単に「問題が起きたら戻す」と書くだけでは不十分です。
どの問題なら戻すか
いつまでなら戻せるか
誰が判断するか
どうやって戻すか
を具体化します。
データ量が多い場合
データ量が多いほど、切替え直前の一括移行には次のリスクがあります。
- 作業時間が長くなる
- 切替え時間を超過する
- エラー発生時の再作業が大きい
- 検証に時間がかかる
そのため、一般には、
事前移行
段階移行
差分移行
移行リハーサル
などを検討します。
環境共有の注意
新旧システムが同じデータベースや一部の環境を共有すると、どちらの処理結果なのかを分けて確認しにくくなることがあります。
環境を分離する
→ 新旧の結果を比較しやすい
環境を共有する
→ 影響範囲や原因を切り分けにくい
「共有すれば移行確認が容易になる」とは限りません。
どんな場面で使う？
システム移行計画は、次のような場面で必要です。
- 基幹システムの刷新
- サーバやOSの更新
- オンプレミスからクラウドへの移行
- データベースの変更
- パッケージシステムの導入
- 拠点や子会社のシステム統合
実務では、本番移行前に移行リハーサルを行い、次を確認します。
手順どおりに作業できるか
予定時間内に完了するか
移行データが正しいか
切り戻しが実行できるか
移行リハーサルでは、成功手順だけでなく、失敗時の復旧手順も試すことが大切です。
よくある誤解・混同
並行運用なら費用が安くなる
誤りです。
並行運用では、新旧二つのシステムを動かすため、通常は費用や作業量が増えます。
安全性・確認性
→ 高まりやすい
費用・運用負担
→ 増えやすい
データ量が多いほど直前に一括移行する
誤りです。
データ量が多いほど、事前移行や段階移行を検討し、切替え時の負担を減らします。
旧システムへ戻す手順だけあればよい
切り戻し手順に加えて、いつ切り戻すのかという判断基準が必要です。
戻し方だけ決める
→ 判断が遅れる可能性
判断基準と戻し方を決める
→ 迅速に対応しやすい
新旧システムで環境を共有すれば確認しやすい
共有によって影響が混ざると、新旧の結果比較や原因切り分けが難しくなることがあります。
移行確認では、比較対象を明確にできる構成が重要です。
バックアップがあれば切り戻し計画は不要
バックアップはデータを復元する手段の一つです。
しかし、切り戻し計画では、業務再開、システム起動、データ整合、利用者連絡なども必要です。
バックアップ
→ データを戻す手段
切り戻し計画
→ 業務を旧環境で再開する全体手順
まとめ（試験直前用）
- 移行計画には、切替え手順と切り戻し計画の両方が必要
- 切り戻しでは、判断基準・責任者・復旧手順を決める
- データ量が多い場合は、事前移行・段階移行・差分移行を検討する
- 並行運用は安全性を高めやすいが、費用や作業量は増えやすい
- 新旧環境の共有は、結果比較や原因切り分けを難しくすることがある
- 「失敗時に旧システムへ戻す基準」が見えたら適切な選択肢を疑う