システム切り替えは一大プロジェクト

　これはまあ、移行元や移行先のシステムが何ものなのかによって難度は大分変わってきます。

　とありますが、確認するポイントは違ってきます。

自社から自社システムへの移行は、移行元のシステム調査にどれくらい手間をかけるかがポイント

　切り替えが成功するかどうかは、移行「元」のアプリの内容をどれくらい把握しているかによって難度が変わります。

　移行するようなアプリは、だいたい作った人いなかったりしますからね。そのためには大体システム調査をするんですけどね。

　このコストが問題。

　そこの調査をケチってわかる範囲でやると、大体ですねー。何か「もれ」
が出たりします。

　新システムを稼働させて、旧システムを停止したら、どこかで「ギャー」となるケースですね。

　大体は旧システムのフロントつかってなくて、裏側のどこかでつながっていたものが使えなくなったとかそんな感じであります。

　なのでこういったものは可能な範囲で調べて、切り戻しができるようにして一回落としてみて、問題が出たところでそこを時間をかけて対応するとかそんなことをやったりします。

自社からSaaSへの移行は、まったく別ものと思って考える

　まあこれは「移行」ってとらえないほうがよいと思います。

　いわゆる「移行」プロジェクトととして扱ったり、データ連携とかさせようとするとえらいお金かかりますので、まったくさらのものとして扱ってデータは新規で投入するようなイメージでやらないとうまくいかないです。

SaaSからSaaS移行は「対応しているか」を確認しよう

　これは記載した通りで、たとえば会計とか人事系とか、ソフト同士の対応ができていたりします。このパッケージがあればだいたいなんてことはないです。

　ご家庭の小規模移行なんかであるのは年賀状ソフトですけど、これは、大体移行手順が用意されていて、そのまま住所ファイルとかは読み込めたり書き出して取り込めたりしますよね。

　そんなイメージ。

　しかし、対応していないものを選んだ場合には、自社からSaaSといった形で考えた方がよいと思います。

移行するときは、移行計画書を作ろう

　あとはまあ、移行するときには移行計画を決めて、体制を取ってやることです。少なくとも移行前後の動きはしっかり固めておかないと、当日地獄を見るのであります。

　移行には「一括移行」「段階的移行」「並行運用」って三つがあります。弊社は以前は一括移行や並行運用が多かったのですが、一括移行はリスクが高いし、並行運用は運用コストがばかにならない(´;ω;｀)

　ということで、最近は段階移行をすることが多いです。
　それか、思いきって一括移行するけれど、移行範囲を狭めて、一定期間は機能が少なくなるのを我慢するとかね。

うまくいかないことも織り込んで計画を立てよう

　私が情シスの開発チームメンバーになって数年は、びっくりするような移行をやってました。

　情シス何やってんだって感じですね。

　さすがに今はそんなことはありませんが、しっかり計画を立ててやらないとうまくいきませんので、システム移行は手順をかけて、部内も含めてしっかり告知して、停止範囲をユーザと合意して、うまくいかないときの切り戻しなども事前に取り決めてやっております。

　ちなみに切り戻しの想定も工数かかるのですが、
　何日も業務が止まっちゃうよりましですよね。

　あとは「移行屋さん」的な人を育ててしまうのも手だと思います。とくにデータ移行はポイント決まってますからね。

　さらにクラウド移行。業務システムのクラウド移行はある程度、持っていくものや切るものが決まっていますから、ポイントを押さえて動くことが大切だと思います。

おしまい。