豚吐露@wiki

問56回答

最終更新:

Bot(ページ名リンク)

- view
管理者のみ編集可



システムの移行方式

機能的に閉じたサブシステム単位に、短期間で順次移行していくので、運用部門の負荷が少なく、問題が発生しても当該サブシステム内に抑えることができる。
【段階移行】
拠点別移行とも呼ぶ。
システム移行の区域を限定し、残りの区域は従来のシステムを用いるという方式。
新旧システムを共存を図るようにする。
また、拠点別に行う段階移行とは別に、業務別に行う段階移行も存在する。

段階移行方式は、『業務』『機能』『拠点』といった、ひとまとまりの単位ごとに現行システムを休止し、順次、新システムに切り替えていく方法だ。
機能単位で移行する場合、ある機能は現行システムで稼働し、別の機能は新システムで稼働する形になる。
そのため、移行過程では両システムの連携が必須となる。
一般的には、専用のインタフェースを開発して相互にデータを参照・更新したり、EAI(Enterprise Application Integration)ソフトを使いデータを同期させたりすることになる。
こうしたデータ移行ツールの設計と実装に多少の手間がかかる。
だが、一括移行方式よりも切り替えの単位が小さい分だけ、数時間から1日程度の短いシステム停止を繰り返せば移行できる。
最近では、大規模システムの移行で、一括移行方式のリスクを負えないときに段階移行方式を選択することが多い。

限定した部門で新システムを導入・観察した後にほかの全部門を移行するので、移行に関する問題が発生しても影響範囲を局所化できる。
【パイロット移行】
順次移行方式とも呼ぶ。
旧システムから新システムに段階的に移行する方式。
新旧システムを比較しながら運用し、問題がなくなった時点で、新システムに移行する。
経済的負担は若干あるが、新システムの完成度が高いというメリットがある。

新・旧両システム分のリソースを用意し、並行稼働させるので、新システムで間題が発生しても業務への影響を最小にできる。
【並行移行】
現行システムと新システムを同時並行で稼働させ、結果を比較検証しながら移行する方式である。
サービス開始後しばらくは現行システムと新システムを二重運用し、新システムに問題がないと分かった時点で現行システムを停止する。
このため移行のリスクは小さい。
業務担当者がデータの二重入力などに協力してくれれば別だが、通常は両システム間でデータを同期させるEAIソフトなどが必要になる。
結果を常に比較検証できるので互換性を高められるが、チェックを繰り返す業務担当者の手間が増える。
両システムの監視・管理が必要な運用担当者の作業負担も倍増する。

ほかの移行方式に比べると移行期間は短くできるが、事前に全部門との間で詳細な計画を立てるとともに、新システムに高い信頼性が要求される。
【一括移行】
ある時点で旧システムから新システムへ一斉に切り替える方式。
新旧両方のシステムを同時に稼働することがないので、経済的な負担が軽くなる。

一括移行方式は、ある時点で現行システムを休止して切り離し、全機能を新システムへと一気に切り替える方法である。
現行システムとのデータ連携などを考える必要がなく、移行のコストを最小化したいときに向いている。
また、現行システムをそのまま温存するので、万一新システムでトラブルが生じても、現行システムに切り替えて業務をすぐに再開できる。
つまり、移行失敗に伴う回復は容易なのだ。
半面、数日程度のまとまった時間のシステム停止ができないと、データ移行やシステム切り替えが難しい。
全機能が一気に切り替わるために、移行自体のリスクは大きくなる。




更新日: 2010年07月13日 (火) 01時16分07秒
記事メニュー
ウィキ募集バナー