素早く?それはすべてのマネージャーが望んでいることですが、私はそれを疑っています。
UI のモデルが根本的に異なり、プログラミング言語も異なります。これらのアプリケーションが小さい場合を除き、短時間で手動で変換できる可能性は低いです (または、OP が「意図する」ことを暗示しているように見えるため、自分で変換することもできます)。
Gartner Group は手動による移行を分析し、すべてが「類似」している場合、実際の変換率は ~~ 150 行/日であることを示唆しています。(SLOC のアプリケーションの大きさはどれくらいですか?) したがって、75,000 行のコードがある場合、最小で 500 人日が必要になります。プログラミング言語としての Delphi と C# は似ていると主張するかもしれません。Delphi UI と Silverlight の場合、合理的にそのように主張することはできないため、この見積もりは下限です。
「捨ててゼロから書き直せ」という人もいます。生産性が 1 日あたり 150 行のデバッグ コードを超えない限り [従来のソフトウェア エンジニアリングのテキストでは、これよりもはるかに小さいことがわかります]、これにはさらに時間がかかります。通常、現在のプログラムに存在する機能を忘れてしまい、開発の後半にそれらを再発見するか、再利用を試みた後にさらに悪いことに失敗するため、失敗します。通常、新しいアプリケーションが構築されている間、古いアプリケーションは進化し続け (新しいアプリケーションの最小値から 500 マン日離れていることを思い出してください!)、新しいアプリケーションはこれらの変更に追いつく必要があります。アプリケーションの規模が深刻な場合 (たとえば、100 万行)、新しいアプリケーションがサービスを提供できなくなることがよくあります。これについて考える別の方法は、"
私の非常に偏った意見 (私は言語翻訳ツールを作成しています) は、これを行う最も実用的な方法の 1 つは自動翻訳であるというものです。これにもコストがかかります。誰かがあなたに何を言おうと、それらは既製品ではありません。翻訳者をセットアップしましたが、これも多くのエネルギーを必要としますが、そのエネルギーは言語と (UI)ライブラリ機能のサイズに比例します。アプリケーションのサイズではなく使用されるため、プログラムが大きくなるにつれてはるかに効果的です。これは、言語翻訳部分だけをコーディングしてテストするのに、まだ数百工数のオーダーです。違いは、一度設定すると、どんな状態のどのようなサイズの既存のアプリケーションにも適用できることです。これよりも複雑な問題がありますが、このアプローチは手動変換の「追いつかない」問題を克服します。 、および「手動で翻訳するのに十分なコーダーを獲得できない」。
詳細については、言語間の翻訳方法に関する私の回答を参照してください。
アプリケーションが比較的小さい場合、私見では良い答えはありません。手作業による翻訳または再コーディングは、おそらく唯一の (醜い) 選択肢です。