 |
||||||||||||||||
|
||||||||||||||||
| 1 2 3 次のページ | ||||||||||||||||
|
||||||||||||||||
| レガシーマイグレーションはなぜ必要か | ||||||||||||||||
|
ここ2〜3年前から「レガシーマイグレーション」という言葉を耳にするようになったが、「自社にはレガシーシステムは存在しないので関係ない」と思っている人は多いだろう。確かに、この言葉がではじめた頃の「レガシー」なシステムが意味する点では、関係がないケースが多かった。しかしレガシーの定義が変化しつつある今、無関係ではない人が増えているのもまた事実だ。 当初、レガシーマイグレーションにおけるシステムとは、メインフレームを基本とした中長期に渡って利用されていたものを指していた。しかし現在では、WindowsやUNIXを活用したシステムもまたレガシー化が進んでおり、マイグレーションの対象となりつつある。これはシステム上で利用されているミドルウェアやアプリケーションについても、同様だ。 これらのことから、一口にレガシーマイグレーションといった場合でも、以下のような切り口があるといえる。
表1：マイグレーションの区分 表1にあげた項目はお互いに関連しあっているため、マイグレーションを行う際には、「何を第一としてプランを立てるか」を明確にする必要がある。 |
||||||||||||||||
| マイグレーションの目的を明確化する | ||||||||||||||||
|
例えば、ビジネス上で必要なデータがあるとする。このデータが汎用的なものであれば、アプリケーションやOS、ハードウェアの選択は比較的自由であるといえる。しかしデータが個別のアプリケーションかつ特定のバージョンに依存したものであれば、必然的に動作するOSやハードウェアも限られてくるはずだ。 さらに、あるデータに対するアクセス／管理／変更などの処理が、従来とまったく同じ方法で行われるべきかどうかも選定のポイントとなる。例えば、移行するデータがある処理を行うために特定のアプリケーションに必要ものだとしても、その処理自体を変更してもよければ移行は容易になる。 つまり、マイグレーションを行う場合には単にデータやアプリケーションなどを新しいシステムに移行するだけでなく、自社のビジネスの流れを再確認し、場合によっては業務フローの刷新までをも視野に入れた作業が必要となる。 このような目的にあわせたシステム側のレガシーマイグレーションの手法は、以下の4つに大別できる。
表2：レガシーマイグレーションの手法 |
||||||||||||||||
|
1 2 3 次のページ |
||||||||||||||||
|
|
||||||||||||||||
|
||||||||||||||||
|
|
||||||||||||||||
|
||||||||||||||||
-
-
連載
