.net - データ移行の見積もりを支援する

Question

私たちのクライアントには、ASP 1.1で構築され、後で2.0にアップグレードされた完全にカスタムのCMSがあります。データベースには200を超えるテーブルがありますが、残念ながら、ASPコードまたはデータベースのドキュメントはありません。元の開発者は質問することができず、私の会社の誰もセットアップに精通していません。

データベーステーブルの大部分にはタイムスタンプ列がないため、検査だけで使用されているテーブルと使用されていないテーブルを判別することは困難です。タスクの複雑さに加えて、CMSのポータルサイトごとに、個々のデータベーステーブルを使用するカスタム機能が開発されており、場合によっては、個々のクライアントサイトのデータを処理するためのストアドプロシージャが開発されています。

このプロジェクトに取り組んでいた元の開発者がいなくなり、思いがけず私の皿に載せられました。各モジュールおよび各クライアントサイトのデータを含む、既存のCMSのすべてのデータを、開発中のカスタムモジュールを含むDotNetNukeインストールに移動する必要があります。私が手渡した見積もりは3週間です。

誰かが以前にそのようなタスクを試みたことがある場合：これは3週間で実行可能ですか？私はこれまでこのような大規模なデータ移行を試みたことがありません。戦略に関する支援があれば役立つでしょう。

Answer 1

悪いニュースから始めます。おそらくそうではありません。(私は 3 暦週間を考えていません: 140 人時がより長い期間に及ぶわけではありません)。

その理由は、少し「通常とは異なる」ものに関するドキュメントがないためです-手順からの奇妙な動作、バグを修正するためのハック、データの不一致、データ汚染など。ドキュメントがないという事実を考えると、期待できません一流のデータ検証またはモデルのいずれか。（存在する可能性があります。保証されていません）。

これは単なる技術的な理由です。「開発中のカスタム モジュール」と言うと警鐘が鳴ります。あなたのプロジェクトはあまりにも流動的であり、関係者間であまりにも多くの話し合いが必要になります.

戦略については、各システムの中核にあり、変換に 20% の労力しか必要としない 80% の共通機能を特定します。コードとデータベースがあります。それをテスト サーバーに配置し、数人のユーザーに共通のアクションを実行させます。コードにトレース/ロギングを入れて、何がヒットしたかを確認してください。タイムスタンプ列または監査証跡をテーブルに配置し、データベースの変更を確認します。

幸運を！

Answer 2

私は数年前に同様のプロジェクトに参加しました。当初の予定は 3 か月でしたが、最終的には生産に入るまでに 6 か月かかりました。このシステムは、公開 Web サイトのフロント エンドを備えた重要な注文処理アプリケーションでした。約40名のバックオフィスユーザーが旧システムから新システムへ一気に移行。

遅延のほとんどは「カスタム モジュール」アプリケーション開発の部分によるものでしたが、移行には 3 週間以上かかったのは間違いありません。ソースデータベースには、外部キー制約といくつかのドキュメントを備えた適切に正規化された設計がありました。最終的に、移行に必要なテーブルは 50 未満でした。しかし、古いシステムのリバース エンジニアリングにはまだ時間がかかりました。データベースで使用されるビュー定義は、このプロセスで大いに役立ちました。

抽出フェーズに加えて、ターゲットへの変換を開発するのにもかなりの時間がかかりました。目的地に必要な変換は、プロジェクト中に多少変更されました。ターゲット スキーマがほぼ修正されている場合は、確かに役立ちます。移行先にすでに新しいデータがあり、それを完全にリロードできなかった場合、稼働後にデータ移行に対する複数の修正も必要でした。

移行に使用しているテクノロジーが何であれ、プロセスが自動化され、簡単に再現できるように開発することをお勧めします。プロジェクトで SSIS を使用しました。本番環境に移行するまでは、おそらく、テスト システムの宛先データベースを複数回初期化して再読み込みする必要があります。また、少数のテーブルしか移行されていない場合でも、ほとんどの場合、テスト システムに実際のデータが存在することは、アプリケーションのテストに役立ちます。