システム構築プロジェクトにとって 、 「 最後にして最大の難関 」 、 それが システム移行 です 。
　 システム移行の目的自体は 、 非常にシンプルで 、
「 旧システムの中から必要なものを取り出し 、 新システムに組み込む 」 事 であるが 、
その為には 膨大かつ複雑な作業 が必要になります 。

この 「 システム移行 」 の為の設計 が 「 移行設計 」 です 。

[1]. [  移行概要  ]

　　 [2]～[6]の前提事項で、 移行の前提となる制約条件を要件として洗い出し、
　　　　　　　　 移行の全体的な方針や方式、 業務への影響などを記述する。

     [2].[移行対象]      [6].[移行体制]

[2]. [  移行対象  ]

　　　 移行する対象物を明記する 。 対象物毎の移行方法をできるだけ具体的に記述する 。

[3]. [  移行中の影響  ]

　　　 移行期間中の影響と、 影響をどう吸収・調整するのかを具体的に記述する。

[4]. [  移行テスト  ]

　　　 移行テストの方法、 実施範囲、 実施環境などを記述する。
　　　 関連ツールのテスト、 移行作業のリハーサルを含む。

[5]. [  移行スケジュール  ]

　　　 移行完了までの大工程、タスクを細分化したWBS、相互関連（作業工程のクリティカルパス）を記述する。

     [2].[移行対象]      [6].[移行体制]

[6]. [  移行体制  ]

　　　 新システムの設計・開発とは別に、 移行専任(※)のチームを編成し、 役割分担を記述する。
　　　 ※（大規模システムでは、 システム開発チームとは別にシステム移行チームの編成が必要な場合もある）

　　　 移行が大規模な場合は、 システム面での移行計画と業務面での移行計画を併せて書くと分かりにくくなる。
　　　　　 [1] の 「 移行概要」 の共通事項だけを「 移行基本計画書」 に記述し、
　　　　　 「 システム移行計画書 」 と 「 業務移行計画書」 に分けて文書化する。

　　　 ※ 「 移行設計 」 は 、 遅くとも内部設計の前までに最初のバージョンを用意する必要があります 。
　　　　 「 その理由としては以下のものがあげられます 」
　　　 ◎ 移行には、 思いのほか利害関係者（ステークホルダ）が多い。

　　　 ⇒ 　 「 移行ツールの開発 」 「 リハーサル 」 「 運用担当者への移管 」 「 業務担当者 への 教育 」
　　　　　 など 、 システム開発者以外の人たちとの協力関係 がなければ 実施できないタスク がいくつもある 。
　　　 ⇒ 　プロジェクトの 初期段階から段取りを踏まないと 、 必要な要員や資材を確保できない 。
　　　　　 各 ステークホルダーとの調整 がつかなければ 、 一歩も先に進めないという事態に陥りやすい 。

　　　 ⇒ 　 移行作業の本番はプ ロジェクトの終盤 に行う為 、
　　　　　 ここで 手戻りが発生すると遅れを取り戻せる余地はほとんどない 。