 |
||||||||||||||||
|
||||||||||||||||
| 前のページ 1 2 3 | ||||||||||||||||
|
||||||||||||||||
| 個々の手法のリスクとは | ||||||||||||||||
|
実際にレガシーマイグレーションを検討する場合、自社ビジネスに対して最適なものを選択することとなる。個々の方式にはそれぞれメリット／デメリット、それに付随するリスクなどがあり、以下のようにまとめることができる。  図2：マイグレーション方式の特徴 また、業務の状況によっては一足飛びに全体の構成を見直すことをせず、複数の方式を組み合わせた段階的な移行も視野に入れるべきだろう。 |
||||||||||||||||
| ニアレガシー環境のマイグレーション | ||||||||||||||||
|
メインフレームに代表されるレガシーなシステムだけでなく、WindowsやUNIXという比較的新しい技術を利用したシステムも、そのバージョンによってはレガシーなものに分類されつつある。例えば、サポートが終了したWindows NT上に構築されたシステムなどがこれにあたる。 もちろん前述の4つの方式でマイグレーションを行うことも可能だが、もう1つの解として仮想環境への移行という選択肢が注目されつつある。この方式の最大のメリットは、耐用年数的に問題のあるサーバのハードウェアを仮想環境に置き換え、システムそのものにほとんど手を入れることなくマイグレーションが可能な点だ。 ただしこの方式で行うマイグレーションは、ハードウェア（仮想環境）の延命は行えるもののOSなどのサポートは終了していることに変わりはなく、あくまでも「現状のシステムに手を加えたくないが環境はリプレースしたい」という用途に限られるだろう。またOSそのもののライセンスの問題があるため、場合によってはライセンス違反となる可能性もある。これらの課題を認識したうえで選択してもらいたい。 |
||||||||||||||||
| データ面でのマイグレーション | ||||||||||||||||
|
システム面でのマイグレーションと同時に必要となるのが、ビジネス上のデータのマイグレーションである。商用データベースからオープンソースデータベースへの移行はもちろん、商用システムのバージョンアップ時にもデータベースアプリケーションの仕様の違いによって、問題が発生するケースがある。 この点については、マイグレーションを行う段階でデータベースの基本仕様をチェックし、対応を行っておく必要があるだろう。 |
||||||||||||||||
| マイグレーションは自社ビジネスを見つめ直す機会 | ||||||||||||||||
|
駆け足でレガシーマイグレーションについて解説してきた。マイグレーションの目的の1つはシステムの移行だが、実際には自社がこれまで行ってきたビジネスを見直し、今後の方向性を含めた展開を再確認する機会であるともいえる。 この作業を単なる環境の「再」構築にとどめるか、「新しいビジネスプロセスの創出」を行うことができるかが、企業の今後を決定づけるだろう。よりよいマイグレーションを実現するために、全社が一丸となって挑戦してもらいたい。 |
||||||||||||||||
|
前のページ 1 2 3 |
||||||||||||||||
|
|
||||||||||||||||
|
||||||||||||||||
|
|
||||||||||||||||
|
||||||||||||||||
-
-
連載
