マイグレーションの注意点

マイグレーションの作業に際して注意すべきポイントとその対策を以下に整理してみましょう。

リビルド

スクラッチでの要件定義や設計は必要ありませんが、プラットフォームが変わるのでシステムの必要な部分、不要になる部分、設計変更が必要な部分を洗い出し、移行のための戦略を立てる必要があります。「とりあえずそのまま移行したい」「移行したほうが簡単だ」と考えがちですが、リビルドによる移行後も長期で運用する計画があるなら、業務プロセスも含めて見直しについても検討した方が良いでしょう。これを怠ると、テストや運用が始まってからのトラブル、改修につながりやすくなります。無駄なコストを抑える意味でも欠かせない作業です。

テスト

通常の開発案件と同様に、テストは網羅的に実施することが重要です。開発中、移行中のデバッグテストはもちろんですが、本番環境に移行するためのテスト運用期間も考慮しなければなりません。本番運用で初めて表面化する不具合もあるので、検収後のサポートやメンテナンスについても考えておきます。ツールを使ったリホスト作業でも、コードが意図したとおり動作をしない場合は手作業による修正が必要となります。古いデータベースシステムや特殊なデバイスの処理部分は、移行ツールでは対応しきれないことがあります。

パフォーマンス

マイグレーションしたシステムのパフォーマンスが十分でないこともあります。CPU性能など格段に進化しているはずなのに、処理が遅くなる問題もしばしば発生します。原因はケースバイケースのため、原因を特定し、解決するノウハウが必要となります。

セキュリティー

オープンシステムの場合、セキュリティー対策は最優先事項のひとつです。メインフレームやレガシーシステムの時代にはなかった概念なので、マイグレーションでは、移行したあとのシステムに必要なセキュリティー機能を実装するか、プラットフォームごとに外部との接点を厳重に管理しなければなりません。具体的には新しいプラットフォームをルーターやファイアウォールで切り離し、他のサーバーと同様なセキュリティー対策を実施します。セキュリティー面を考えると、新プラットフォームは、一般的にはオンプレミスサーバーよりIaaS、PaaSの利用が望ましいでしょう。

成功に導くためのポイント

マイグレーションで失敗しないためには、まず事前の戦略をしっかり立てることです。レガシーシステムのどの部分が必要で、どのような改善が必要なのか、そしてどの部分が要らないのか。課題を明確化し、その上でマイグレーションのスキームを決定します。

そのためには、他社事例や使えるソリューションの精査が不可欠となります。SIerやシステムベンダーに依頼するなら、よく相談し、自社の要求を満たせるかどうか見極める必要があります。過去にどのような業界、どのようなシステムのマイグレーションを手掛けた実績があるのか。規模や移行後のサポート、メンテナンスの条件などもチェックしておくと良いでしょう。

レガシーシステムとはいえ、一時しのぎのマイグレーションでなければ今後も長期的に使い続けることになります。きっかけはリース契約終了やハードウェア維持コストの削減かもしれません。しかしそのような場合でも、システムを戦略的に活用していくため、マイグレーションをアップグレードの一つのスキームと捉えておく姿勢が重要となります。

例えば、乱立したサイロシステムの統廃合、IaaSやPaaSなどクラウド活用によるリソースの最適化、ハードウェア資産の陳腐化リスクの軽減、システムの可用性やスケーラビリティの向上など、マイグレーションは、そんな改善策を実施するチャンスでもあります。
リホストは単なるハードウェアのリプレースではありません。仮想化やクラウドといった新しい技術を活用することで、「攻めの経営」につなげていくことができるのです。