現行システムのソースは存在するか？
バージョン管理に失敗しており、どのソースが現行システムで動いているのか分からないと困ります。
また、ソース自体が無く現行システムで動作している実行ファイルのみが存在しているケースもかなり困ります。
設計書、仕様書は最悪無くてもソースを読み解けばシステムがどのように動いているか分かりますが、ソース自体が無いと実行ファイルからリバースしてソースを作成することになるので大変です。
ちなみに、設計書、仕様書が無い場合はバグまで再現してモダナイゼーションすることになります。機能追加などは設計書、仕様書を作成してから実施するのが最適でしょう。
テスト環境はあるか？
出力結果の比較をする際に、テスト環境相当を使用します。このテスト環境が実行環境と乖離がある状態だと、出力結果比較できないので困ります。メインフレームは高額であったため、テスト環境まで揃えられていないケースは結構あります。
テスト環境が存在していても、使用制限があったりして十分に出力結果を比較できなくても困ります。これもメインフレームが高額であることが起因しているのですが、複数システムのテスト環境として使用しているため、実行環境と大きく乖離した環境になっていることも結構あります。そして複数システムのテスト環境であるために、使用時間にかなりの制約があることが多いです。
クライアント作業の見積もり工数は十分か？
モダナイゼーションをベンダーに任せる場合でも、クライアント作業は想定以上に多くなりがちです。利益を生む作業ではないため、会社としては工数をなるべく少なくしたいという思いから工数を少なく見積もるよう各所から圧力があるかもしれませんが、負けずに工数を確保しましょう。
数十年運用保守を続けたシステムは簡単にモダナイゼーション出来ません。ベンダーに正確な情報やデータを提供する必要がありますが、関係各所への確認、背景の確認、データの取得、データをベンダーに提供するためのマスキング作業など、多くの手間と時間がかかるでしょう。
