もちろん、これは非常に幅広い質問ですが、どのようにアプローチするかについていくつかの提案をしようと思います:
<オール> <リ>最初の目標は、2005 データベースをテストするスクリプト (ストアド プロシージャ) を作成することです。既存のすべての sproc を実行し、テーブル内のレコードをカウントし、インデックスを一覧表示します。これにより、2005 年にそれらを実行し、移行が完了した後に 2008/2012 年に実行できるようになります。スキーマを証明するのに役立ちますおよび データは無事に終わりました。
<リ>2005 年のデータベースのバックアップを作成し、2008/2012 に復元します。必要に応じて、手順 1 と並行してこれを行うことができます。使い始めるだけです。すべて正常にインポートされましたか?それは視力検査に合格しますか？対処する必要のあるエラーはありますか?
<リ>ステップ 2 の後、現在の .NET 2.0 コードのコピーを作成し、ステップ 2 の新しいインスタンスをポイントします。アプリケーションは動作しますか?繰り返しますが、それは視力検査に合格しますか?
<リ>自信が持てるまで、アプリケーションのコピーと新しいデータベースを繰り返します。コードベース用のテスト スイートがあれば、直感を使うよりも問題がないことを証明するのに役立ちます。
.NET 2.0 から .NET 4.0/4.5 に移行する限り ...
<オール> <リ>コードベースは下位互換性がある必要があります。私が見ることができる唯一の問題は、他のシステムがあなたのコードベースに依存しているかどうかです。コア ライブラリがあり、それを 4.0 にアップグレードしたい場合、そしてまだ 2.0 を使用している別のシステムがそのライブラリを必要としている場合、問題が発生します。
<リ>後まで、.NET バージョンのアップグレードを待ちたいと思います。 データベースの移行を完了します。移行中に問題が発生した場合は、それが .NET ではないことを確認する必要があります。バグや問題を絞り込むのに役立ちます。
このような多くの移行を行った後、いくつかの一般的なアドバイス:
<オール> <リ>新しいインスタンス/システムを自由に作成して、テスト、テスト、テストしてください。ソース管理で既存のコードを直接操作したり、既存のデプロイメント/サーバーを操作したりしないでください。コピーしてテストするだけです。
<リ>システム テストの自動化に役立つツールとスクリプトを記述します。 「はい、私の知る限り、スキーマはまったく同じです。」
<リ>反復を長くしすぎないでください。小さな方法で反復し、それが機能することを証明してから次に進みます。
お役に立てば幸いです。