ある情報インフラから別の情報インフラへ移す、というのは結構最近多いようで、最近ではマイグレーション、と呼ばれているようだ。
例えば、Microsoft SQL Server を 2000 から 2005 にする際、Microsoft ではマイグレーションの研修（といっても実地）を開催していたりしたので、ソフトウェアのバージョンアップに伴う移行もそう呼ぶらしい。
私自身は異機種間／異言語間でのデータ連係や情報インフラの移行、ソフトウェア資産の移行、データの移行、などの経験が多い。いずれにせよ、連携元／連携先か移植前／移植後の環境に詳しくなくては真っ当な設計ができず、あとあと問題になることが多いが、知識や経験でカバーできることが多く、カバーできないところは新たに勉強する、場合によっては確実に行うために顧客に検証（実験）を認めて貰う、等で補ったので、期限を守れる成果を十分に出せているおり、それほど難しいと思ったことはない。ただ、実験するにせよ、データ連係よりマイグレーションの方が制約事項が多いこともあり、また全く未経験の者であることも多く、難易度は高いのは確かである。
以下、マイグレーション系の経験をいくつか挙げる。
○データベース変更に伴うデータベースサーバ構築（機器選定、構成含む）とデータ移行
・Microsoft SQL Server を 2000 から 2005への変更で、アプリケーションへの影響が最小限となるよう検討し、結果的にアプリケーションは変更せずにすむようにした。
→変更点は結構多く。Microsoftがマイグレーション研修を開くだけのことはあったと思う。
○大型汎用機の機種変更（更改、と言っていた）に伴うプログラム改修のテスト
・COBOL、JCLは問題なかったが、CALLされるアセンブラに問題があった。古い話で記憶が怪しいのだが、富士通汎用機のCOBOLコンパイラには24ビットモードと31ビットモードがあり、アセンブラが24ビットモードで作成されていた。ところが新しい機種では31ビットモードでなければならなかったらしく、アセンブラの書き換えがある必要があった。COBOL自体はリコンパイルで済んだが、COBOLからのCALL結果を確認する細かいテストが必要だった。ただし、このときはこの作業よりも並行して行った2000年対応の方が大変であった。
○大型汎用機からUNIXへの変更
・金融系で、プラットフォームは全て移すが、オンライン系とバッチ系では移行が違った。
・オンライン系はJavaに移植。データベースも汎用機のシーケンシャルファイルや索引ファイルからOracleへ移植、というもの。両方の言語に精通しているものがほとんどおらず、Javaをしっかり学び、Javaの常識とCOBOLの常識を通訳していた。
・バッチ系はCOBOLをCOBOLのままUNIXへ移す。JCLはJP1などのツールに置き換えをすることになっていた。直接関わることは少なかったが、仕様上の助言は何度も行った。例えば汎用機上のCOBOLで扱える数字の桁数は、ソースコードを見る限り標準COBOLよりも4桁多かった。誰も指摘しないので、これをソースコード変更しなければコンパイルエラーが出るし、コードを変更すれば桁数を保障できなくなる恐れがあるので、調査必要である旨提言したり、個人情報の電話番号がハイフン込みで12桁であったが、電話加入権の価格もあり、携帯電話しか持たない世代も出始めていたので桁数を増やすべきでは、との提言をしたり。当時、プロジェクト内ではバッチ処理に関して誰よりも詳しかったと思う。
最近ではVMの環境も出来ており、検証する環境は整えやすくなっているだろう。しかし、汎用機の資産を抱えていると、なかなかそうもいかない。
コスト的には汎用機はもはやメリットはない。信頼性や安定性といったビジネスを続けていくための基盤としても、今はクラスタリングなどでカバーできるのではないか。
おそらく、残っている利点とすれば「利用する資源の活用をコントロールできる」ことではないかと思う。UNIXでもタスクの優先度は付けられる。しかし、メモリをこれだけまで、データサイズをこのくらいまで、という制限を掛けられないのではないか？
汎用機では、予定していた容量より多く、追加領域をどれだけ使った、という情報がログとして残る。多すぎる場合は異常終了する。これによりデータ量が適正だったのかの検証ができる。いわば、内部統制の一種と言ってもいいかもしれない。バッチJCLではごく当たり前の制約だが、UNIX系のジョブコントロールソフトでこういう機能があるのか、過去に調べた限りはなさそうであった。
他の利点があるかもしれないが、私が知る限りの利点はこれだけで、これが克服されれば、もう汎用機は完全になくせてしまうのではないか、とも思っている。
例えば、Microsoft SQL Server を 2000 から 2005 にする際、Microsoft ではマイグレーションの研修（といっても実地）を開催していたりしたので、ソフトウェアのバージョンアップに伴う移行もそう呼ぶらしい。
私自身は異機種間／異言語間でのデータ連係や情報インフラの移行、ソフトウェア資産の移行、データの移行、などの経験が多い。いずれにせよ、連携元／連携先か移植前／移植後の環境に詳しくなくては真っ当な設計ができず、あとあと問題になることが多いが、知識や経験でカバーできることが多く、カバーできないところは新たに勉強する、場合によっては確実に行うために顧客に検証（実験）を認めて貰う、等で補ったので、期限を守れる成果を十分に出せているおり、それほど難しいと思ったことはない。ただ、実験するにせよ、データ連係よりマイグレーションの方が制約事項が多いこともあり、また全く未経験の者であることも多く、難易度は高いのは確かである。
以下、マイグレーション系の経験をいくつか挙げる。
○データベース変更に伴うデータベースサーバ構築（機器選定、構成含む）とデータ移行
・Microsoft SQL Server を 2000 から 2005への変更で、アプリケーションへの影響が最小限となるよう検討し、結果的にアプリケーションは変更せずにすむようにした。
→変更点は結構多く。Microsoftがマイグレーション研修を開くだけのことはあったと思う。
○大型汎用機の機種変更（更改、と言っていた）に伴うプログラム改修のテスト
・COBOL、JCLは問題なかったが、CALLされるアセンブラに問題があった。古い話で記憶が怪しいのだが、富士通汎用機のCOBOLコンパイラには24ビットモードと31ビットモードがあり、アセンブラが24ビットモードで作成されていた。ところが新しい機種では31ビットモードでなければならなかったらしく、アセンブラの書き換えがある必要があった。COBOL自体はリコンパイルで済んだが、COBOLからのCALL結果を確認する細かいテストが必要だった。ただし、このときはこの作業よりも並行して行った2000年対応の方が大変であった。
○大型汎用機からUNIXへの変更
・金融系で、プラットフォームは全て移すが、オンライン系とバッチ系では移行が違った。
・オンライン系はJavaに移植。データベースも汎用機のシーケンシャルファイルや索引ファイルからOracleへ移植、というもの。両方の言語に精通しているものがほとんどおらず、Javaをしっかり学び、Javaの常識とCOBOLの常識を通訳していた。
・バッチ系はCOBOLをCOBOLのままUNIXへ移す。JCLはJP1などのツールに置き換えをすることになっていた。直接関わることは少なかったが、仕様上の助言は何度も行った。例えば汎用機上のCOBOLで扱える数字の桁数は、ソースコードを見る限り標準COBOLよりも4桁多かった。誰も指摘しないので、これをソースコード変更しなければコンパイルエラーが出るし、コードを変更すれば桁数を保障できなくなる恐れがあるので、調査必要である旨提言したり、個人情報の電話番号がハイフン込みで12桁であったが、電話加入権の価格もあり、携帯電話しか持たない世代も出始めていたので桁数を増やすべきでは、との提言をしたり。当時、プロジェクト内ではバッチ処理に関して誰よりも詳しかったと思う。
最近ではVMの環境も出来ており、検証する環境は整えやすくなっているだろう。しかし、汎用機の資産を抱えていると、なかなかそうもいかない。
コスト的には汎用機はもはやメリットはない。信頼性や安定性といったビジネスを続けていくための基盤としても、今はクラスタリングなどでカバーできるのではないか。
おそらく、残っている利点とすれば「利用する資源の活用をコントロールできる」ことではないかと思う。UNIXでもタスクの優先度は付けられる。しかし、メモリをこれだけまで、データサイズをこのくらいまで、という制限を掛けられないのではないか？
汎用機では、予定していた容量より多く、追加領域をどれだけ使った、という情報がログとして残る。多すぎる場合は異常終了する。これによりデータ量が適正だったのかの検証ができる。いわば、内部統制の一種と言ってもいいかもしれない。バッチJCLではごく当たり前の制約だが、UNIX系のジョブコントロールソフトでこういう機能があるのか、過去に調べた限りはなさそうであった。
他の利点があるかもしれないが、私が知る限りの利点はこれだけで、これが克服されれば、もう汎用機は完全になくせてしまうのではないか、とも思っている。
