すべてのカスタム レガシー ソフトウェアは変更が必要です。ユーザーはそう言います。場合によっては、1 つまたは 2 つの機能を追加し、コードの一部を変更したり、コントロールを追加したり、その他のマイナーなアップグレード タスクに必要なすべてを追加したりする必要があります。エラーが発生しやすい VB5 デスクトップ ソリューションを捨てて、すべてをリッチな Web 2.0 ASP.NET MVC アプリケーションとして書き直そうとする場合もあります。ただし、多くの場合、従来の機能に対する変更の範囲は、これら 2 つの両極端の間のどこかにあります。
既存のアプリケーションをアップグレードするか、ゼロから始めるかを決定する際に使用する経験則は何ですか?
これは決まり文句に聞こえるかもしれませんが、標準的な費用対効果の分析に進みます。
書き直しにかかるリソースのコストを計算します (現実的なコスト - 見積もりを 3 ～ 5 倍することを意味します)。これには、新しく選択したアーキテクチャ/ツールについて他の開発者をトレーニングする必要がある可能性と、ユーザーを再トレーニングするコストが含まれます。
今後 N か月以内に予想される実装が困難な変更からリソース コストを取得します (経験に基づいて) - 限界コストのみをカウントします (つまり、VB5 アプリの変更のコストが 1 週間であり、そのコストが同じである場合)機能を豊富な Web 2.0 ASP.NET MVC アプリケーションに実装するには 3 日かかりますが、2 日分の節約としてカウントされます)。Web 2.0 アプリがユーザーに提供する新機能から予測される利益を追加すると、VB5 アプリはまったく提供できません。
前者が後者よりも小さい場合は、書き直してください。
それを決定するのに便利なルールはありませんが、ジョエル・スポルスキーが会社が犯す可能性のある最悪の戦略的ミスについて書いている、 「絶対にやるべきでないこと」のパートIを読むことをお勧めします。
とは言うものの、私たちは顧客向けのアプリケーションを完全に書き直しました。これは、以前よりも信頼性が高く、高速で、機能が多く、美しいため、正しいことでした。古いアプリケーション（何とかハッキングされただけで何年にもわたって多くの機能を獲得してきた）を拡張することは、それが生きているアプリケーションであり、年に1〜2回追加の機能を取得するため、長期的にはより高価でした。
一般的に、機能を追加するために必要なリソース（時間、お金、開発者など）が、再書き込みに必要なリソース（時間、お金、開発者など）よりも多い場合は、再書き込みします。
バイアスを追加する必要があります。たとえば、アプリケーションを書き直すと、実装の一部として多くのバグが削除されるため、将来的にサポートコストが削減される可能性がありますが、新しいアプリケーションを作成するときにも問題が発生します（トレーニング、完成品に侵入する小さなバグ、ランダムなデバッグメッセージボックス、またはそのようなゴミ）。
書き直しは絶対に避けようとしています。必要な場合もありますが、当初の予想よりも常にかなり問題が多く、レガシーバージョンで潰されてから長い間バグが再発生する傾向があります。
現在のプラットフォームでサポートされていない機能を追加する必要がある場合は、書き直す以外に他のオプションはないように思われるかもしれませんが、他の選択肢を検討してください。別の方法で機能を追加できますか？イントラネット上のレポートまたは小さなWebパーツ？自動メール？データベースに反するある種のWebサービス？そこにあるものを完全に廃棄せずに、関連するすべてのリスクを受け入れることなく、機能を追加できる方法はいくつかあります。
ビジネスの観点からは、コストとメリットの違いです。単一の機能を追加する場合、それは開発時間と機能の利点です。ただし、書き換えが必要な単一の新機能が必要な場合は、突然8時間の機能が800時間の機能になります（書き換えの開発時間を見積もる場合は現実的です。「来週にやります」ではありません」多くの場合現実的です）、そしてビジネスはもはや開発時間を正当化することができないかもしれません。コストが利益によって正当化されることを確認してください。