システム移行の歩き方（２）

第2回目も概要ですが、もう少し掘り下げてみます。
今回も加筆修正を加えながら完成させていきたいと思います。

■結局システム移行は大事と言いながら概要しかない。

ネットで見ているシステム移行について解説している記事は、
失敗した場合の惨事の話や抽象的な大項目に終始して、成功するための細かい手法については書いてありません。

移行を行う際、参考になるものがなくて私もかなり参りました。
プログラムや設計にはデザインパターンなるものがありますが移行設計には
結局そこまで型にはまったパターンはないので、おそらく表現する側もそれ以上は書けなかったのかもしれません。

本稿についてはどんな移行にも使えるわけではありませんが、こうして
移行を乗り越えた、という参考になるような事を書いていきたいと思います。
結果的に前述の概要のみ記載している文献と同じく、全く役に立たなかった、という場合もあり得るとは思いますが。

■移行対象の選定

え？ってなると思いますが大規模になればなるほど、範囲を明確にしておく必要があります。

実は大規模になればなるほど、自分が思っている移行対象以外にも並行して移行されたりするシステムが複数あったりします。
実は接続先の○○も移行本番当日には別に移っている、という事もありえます。
いかに現行の接続先とテストをしても当日その「接続先」が「移行先」に移ってしまっていた、計画通りにいかないなんて事も十分考えられます。

他にも携わっているシステムの中でも管理系などの移行が起きないサーバーやインフラ設備もあります。例えば、管理画面だけは移行しない、という場合、NASはそのまま利用する、など、こういう場合は意外とあります。

もちろんネットワークも本番当日と現在計画しようとしている状態が違う物の場合もあります。今ではなく、移行当日の環境がどうなっているかを調べる必要があるという事です。”移行しないシステム”、”すでに変化のあったシステム”といった観点の影響度を調べる必要があるという事です。

そのためには、移行対象をサーバー単位、ネットワーク単位で明確にしておく必要があります。

■移行要件について

一番重要な事はシステムを移行する際に、移行している間、現行システムがどのような状態が許されるのか、という点にあります。

つまりどういう事かというと、

・システムを止めていいのか。
・止めれるとしたらどの期間まで許されるのか。
・過去のログやデータはどの程度新システムに移送すべきか。
・止めれないのならばどの部分が止めてはならないのか。

システムは複雑に業務が絡んでいるため、一見止めれないと言えば全て止めれないんでしょうけど、見た目は止まっていなくても止めることのできる箇所はあります。それは例えば、夜間バッチ処理など、見えない裏で動いている物達です。
どの業務が止めてはいけないかという部分を明確にする事で、後々の移行設計の自由度を作れるタイミングでもあります。

つまり、ここでどの程度許されて許されないかを明確にしておけば移行設計がしやすいだけでなく、そんな事はだめだ！ここは止めないで！とかこの過去ログは検索できないとダメだ！というトラブルを、このタイミングでかなり抑える事ができます。

つまり、移行設計初期の腕の見せ所になります。

今回はここまで。また次回に続きます。