サービスの設計
ITサービスの設計は、ユーザニーズを満たし、SLAをクリアするにはどんな技術を持つサービスが適切かを検討する。また、サービスに用いるシステムの技術や必要な人材・機材、さらに新サービスへの移行計画や運用の引継方法なども検討し、サービス設計書を作成する。
そのほか、
構築した新サービスの評価基準となるSAC（Service Acceptance Criteria: サービス受入基準)や運用開始後の評価に用いる運用サービス基準なども用意しておく。移行前には受入テストを行い、機能や品質が基準を満たすかを確認する。
システムの移行手順
新システムに不具合があると、業務に大きな影響を与えるため、システムの性質により適切な移行方法を選択する。また、移行作業は運用部門が主体となって行う。
移行対象データの決定
現行システムの中の新システムで使用するデータを決める。
データ移行方法の検討
新システムで使用するデータをどのようにして使用するかを検討する。
そのまま使える場合もあるし、データ変換が必要な場合もある。
移行計画書の作成
移行の日時や移行手順など、移行の計画書を作る。一気に新システムに移行することもあるし、並行運営しながら数ヶ月かけて移行することもある。
移行の実施
移行計画書に従って、移行作業を行う。
移行方法によって、必要な要員が変わってくる。
システムの移行方法
一斉移行方式
休日などを利用し、一気に新システムに切り替える方法。移行期間が短くコストが安い。
反面、システム障害時に業務に与える影響が大きい.
パイロット移行方式
一部の拠点や部門に限定して新システムを導入し、動作を観察``した後で全体を移行する方式。 移行時の問題による影響範囲を局所化```でき、リスクが少ない。
順次移行方式
サブシステム単位で、順次新システムに切り替える方法。
システム障害をサブシステムに限定でき、運用部門の負荷も少ないが、移行手順は複雑になる。
並行移行方式
新旧システムを同時稼働させ、安全が確認できるまで運用した上で、切り替える方式。
最も安全な方法。
しかし
移行期間が長く、運用部門の負担は大きい。
出典