要件定義のデータ移行のテンプレ。随時加筆。
- 目的
データ移行の概要を載せる。例
本書の目的は2017年1月サービス開始予定のXXXシステムにおける移行に関する 作業・役割・期間を定義し、プロジェクトメンバー、関連部署間において、 共有することを目的とする。
- 前提条件
判明している前提条件を載せる。例
・サービス開始は2017年1月4日(月)である。 ・移行作業については、2016年12月29日(木)のオンライン終了後～ 2017年1月3日(火)までの間でシステムを停止させた状態で行う。 ・XXXシステムの切替は一括切替とし、一部切替は行わない。 ・XXXシステムの切り戻しは一括切り戻しとし、一部切り戻しは行わない。 ・セキュリティパッチの適用は2016年8月31日をもって凍結する。以降、 ・本番開始までのタスク・スケジュールは今後随時見直し行う。 ・移行の大まかな流れは以下の通りとする。 (ここで年、月のエクセル図があるとイメージがつきやすい)
- システム移行
IPやURLや製品情報を載せる。例
新システムのシステム構成
※仮想アプライアンスとは仮想マシン内にOS、ミドルウェア、アプリケーションといった 全ソフトウェア・コンポーネントを予め準備し、デプロイすると稼働状態となり、 利用可能になる。No 役割 分類 IPや製品名 1 WEBサーバ#１ Linux系サーバ XXXX 2 WEBサーバ#２ Linux系サーバ XXXX 3 APサーバ#１ Linux系サーバ XXXX 4 APサーバ#２ Linux系サーバ XXXX 5 DBサーバ Linux系サーバ XXXX 6 ロードバランサ#１ 仮想アプライアンス XXXX 7 ロードバランサ#２ 仮想アプライアンス XXXX 8 帳票サーバ Windows系サーバ XXXX アプリケーションの機能ごとに言語やバージョンの違いを載せる。
ライブラリの違いもあるとより良い。例
１．オンラインアプリケーション ２．クライアントアプリケーション ３．バッチアプリケーション
No 種別 名称 言語 Oracle C# Java Pro*C SQLローダ PLSQL 1 オンライン XXXマスタ登録 ● ● 2 クライアント XXXマスタ登録 ● ● 3 バッチ XXXマスタ取込 ● - データ移行
移行対象有無や移行方法を載せる。例
No 名称 移行有無 移行方法 スキーマ 表領域 1 テーブル ● SQL文 XXXX TBL 2 インデックス ● SQL文 XXXX IDX 3 プロシージャ - - - - 4 パッケージ - - - - 5 シーケンス ● SQL文 XXXX TBL 6 トリガー - - - - 7 シノニム - - - - オブジェクト構成があまり変わらない場合、新旧の比較を載せるのも良い。
例
No 旧オブジェクト名 新オブジェクト名 区分 概要 新規 変更 削除 1 Aテーブル Aテーブル ● カラム追加 2 Bテーブル ● テーブル追加 3 Cテーブル ● テーブル削除 テーブルのうち、データマッピング、初期データについて載せる。
詳細は外部設計にすることが多い。例
１．テーブルデータ
２．初期データNo 旧カラム名 新カラム名 区分 概要 新規 変更 削除 1 ID ID 変更なし 2 氏名漢字 ● カラム追加 3 氏名カナ ● カラム削除 No テーブル名 カラム名 設定値 1 URLマスタ ID 111 2 URLマスタ URL z-area.net - 業務移行
アプリケーションの機能ごとに稼働時間の違いや運用ルールの違いを載せる。例
１．オンラインアプリケーション ２．クライアントアプリケーション ３．バッチアプリケーション
No 種別 機能名 旧機能概要 新機能概要 1 オンライン XXXマスタ登録 300件まで登録 2000件まで登録 2 クライアント XXXマスタ登録 300件まで登録 2000件まで登録 3 バッチ XXXマスタ取込 2000件まで登録 5000件まで登録 - 依頼事項
事前に判明している依頼先と依頼内容があれば載せる。 - 移行リハーサル
移行リハーサルの概要を載せる。例
移行リハーサルについては3回実施する。 ＜1回目＞ データベースの移行検証 データベース以外の移行検証 ＜2回目＞ 1回目の検証結果を受けた見直し実施 ＜3回目＞ 最終的な手順確認
移行時に発生する作業 １．システム移行(システム構築) ２．リリース ３．現行サーバの停止 ４．データ移行(DB、ファイル) ５．検証
移行リハスケジュール (ここで年、月のエクセル図があるとイメージがつきやすい)
- 移行テスト
移行後の環境で行うテスト方針を載せる。 - 移行体制
移行時の体制や連絡先を載せる。
(ここで年、月のエクセル図があるとイメージがつきやすい) - 本番検証
移行の検証手段と移行判定方針を載せる。2017年1月1日(日)に運用にてURLを切り替えていただき、アプリチームにて
アプリケーション観点で動作確認を行う。
他システムとの連携確認は実施しない。
2017年1月2日(月)に顧客に動作確認を実施いただく。 - 切り戻し
本番検証で失敗した場合の切り戻し方針を載せる。本番検証で現行業務に支障を及ぼすと判断される場合、切り戻しを実施する。
切り戻しについては以下表のシステムを切り戻す。 - コンティンジェンシープラン
移行時の不測の事態が発生することを想定し、
その対策や行動手順として、再実行時の必要日数や候補日を載せる。現時点では移行期間は4日間必要と考える。
再移行期間の候補は以下の通り。
１．2017年1月7日(土)～2017年1月9日(月・祝)と前後1日
２．2017年3月18日(土)～2017年3月20日(月・祝)と前後1日