【要件定義】データ移行

要件定義のデータ移行のテンプレ。随時加筆。

  • 目的
    データ移行の概要を載せる。

    本書の目的は2017年1月サービス開始予定のXXXシステムにおける移行に関する
    作業・役割・期間を定義し、プロジェクトメンバー、関連部署間において、
    共有することを目的とする。
    
  • 前提条件
    判明している前提条件を載せる。

    ・サービス開始は2017年1月4日(月)である。
    ・移行作業については、2016年12月29日(木)のオンライン終了後~
     2017年1月3日(火)までの間でシステムを停止させた状態で行う。
    ・XXXシステムの切替は一括切替とし、一部切替は行わない。
    ・XXXシステムの切り戻しは一括切り戻しとし、一部切り戻しは行わない。
    ・セキュリティパッチの適用は2016年8月31日をもって凍結する。以降、
    ・本番開始までのタスク・スケジュールは今後随時見直し行う。
    ・移行の大まかな流れは以下の通りとする。
     (ここで年、月のエクセル図があるとイメージがつきやすい)
    
  • システム移行
    IPやURLや製品情報を載せる。

    新システムのシステム構成
    
    
    No役割分類IPや製品名
    1WEBサーバ#1Linux系サーバXXXX
    2WEBサーバ#2Linux系サーバXXXX
    3APサーバ#1Linux系サーバXXXX
    4APサーバ#2Linux系サーバXXXX
    5DBサーバLinux系サーバXXXX
    6ロードバランサ#1仮想アプライアンスXXXX
    7ロードバランサ#2仮想アプライアンスXXXX
    8帳票サーバWindows系サーバXXXX
    ※仮想アプライアンスとは仮想マシン内にOS、ミドルウェア、アプリケーションといった  全ソフトウェア・コンポーネントを予め準備し、デプロイすると稼働状態となり、  利用可能になる。

    アプリケーションの機能ごとに言語やバージョンの違いを載せる。
    ライブラリの違いもあるとより良い。

    1.オンラインアプリケーション
    2.クライアントアプリケーション
    3.バッチアプリケーション
    
    
    No種別名称言語
    OracleC#Java
    Pro*CSQLローダPLSQL
    1オンラインXXXマスタ登録
    2クライアントXXXマスタ登録
    3バッチXXXマスタ取込
  • データ移行
    移行対象有無や移行方法を載せる。

    No名称移行有無移行方法スキーマ表領域
    1テーブルSQL文XXXXTBL
    2インデックスSQL文XXXXIDX
    3プロシージャ----
    4パッケージ----
    5シーケンスSQL文XXXXTBL
    6トリガー----
    7シノニム----

    オブジェクト構成があまり変わらない場合、新旧の比較を載せるのも良い。

    No旧オブジェクト名新オブジェクト名区分概要
    新規変更削除
    1AテーブルAテーブルカラム追加
    2Bテーブルテーブル追加
    3Cテーブルテーブル削除

    テーブルのうち、データマッピング、初期データについて載せる。
    詳細は外部設計にすることが多い。

    1.テーブルデータ
    
    
    No旧カラム名新カラム名区分概要
    新規変更削除
    1IDID変更なし
    2氏名漢字カラム追加
    3氏名カナカラム削除
    2.初期データ
    Noテーブル名カラム名設定値
    1URLマスタID111
    2URLマスタURLz-area.net
  • 業務移行
    アプリケーションの機能ごとに稼働時間の違いや運用ルールの違いを載せる。

    1.オンラインアプリケーション
    2.クライアントアプリケーション
    3.バッチアプリケーション
    
    
    No種別機能名旧機能概要新機能概要
    1オンラインXXXマスタ登録300件まで登録2000件まで登録
    2クライアントXXXマスタ登録300件まで登録2000件まで登録
    3バッチXXXマスタ取込2000件まで登録5000件まで登録
  • 依頼事項
    事前に判明している依頼先と依頼内容があれば載せる。
  • 移行リハーサル
    移行リハーサルの概要を載せる。

    移行リハーサルについては3回実施する。
    
    <1回目>
    データベースの移行検証
    データベース以外の移行検証
    
    <2回目>
    1回目の検証結果を受けた見直し実施
    
    <3回目>
    最終的な手順確認
    
    移行時に発生する作業
    
    1.システム移行(システム構築)
    2.リリース
    3.現行サーバの停止
    4.データ移行(DB、ファイル)
    5.検証
    
    移行リハスケジュール
    (ここで年、月のエクセル図があるとイメージがつきやすい)
    
  • 移行テスト
    移行後の環境で行うテスト方針を載せる。
  • 移行体制
    移行時の体制や連絡先を載せる。
    (ここで年、月のエクセル図があるとイメージがつきやすい)
  • 本番検証
    移行の検証手段と移行判定方針を載せる。

    2017年1月1日(日)に運用にてURLを切り替えていただき、アプリチームにて
    アプリケーション観点で動作確認を行う。
    他システムとの連携確認は実施しない。
    2017年1月2日(月)に顧客に動作確認を実施いただく。

  • 切り戻し
    本番検証で失敗した場合の切り戻し方針を載せる。

    本番検証で現行業務に支障を及ぼすと判断される場合、切り戻しを実施する。
    切り戻しについては以下表のシステムを切り戻す。

  • コンティンジェンシープラン
    移行時の不測の事態が発生することを想定し、
    その対策や行動手順として、再実行時の必要日数や候補日を載せる。

    現時点では移行期間は4日間必要と考える。
    再移行期間の候補は以下の通り。
    1.2017年1月7日(土)~2017年1月9日(月・祝)と前後1日
    2.2017年3月18日(土)~2017年3月20日(月・祝)と前後1日