多国籍企業をある開発プラットフォームから別の開発プラットフォームにどのように移行できますか？

私は、国際的な大企業のIT部門で働いています。私たちは、ビジネス向けのさまざまなイントラネットアプリケーション（苦情、リベート、サービスデスクなど）を開発しています。今度は、PHPプラットフォームから.NETへの移行を決定しました（MS CRM Dynamics、Exchange、MS Officeとの統合が多くの理由の1つです）。現在のPHPプラットフォームでビジネスが使用しているアプリケーションは約20あるため、それらすべてを新しいプラットフォームに移行するための最良の方法を考え出す必要があります。コードを変換する方法などは詳しく説明しません。移行する間は、これらのアプリケーションをすべて改善したいと考えています。

そこで、これらのアプリを移動する2つの主な方法を考え出しました。

1. 1つのプラットフォームのみをサポートします。それはどういう意味ですか？ホームページを作成し、文字通りすべてのアプリを.NETに移行します（その間、アプリを改善することはありません）。新しいイントラネットの実行後、移行したアプリケーションの再構築と改善を開始します。これにより、PHPプラットフォームをサポートする必要がある一方で、.NETでイントラネットを開発する手間が省けます。

2. しばらくの間、両方のプラットフォームをサポートしてください。それは、ホームページと1つまたは2つの新しいアプリケーション（PHPプラットフォームには存在しない）だけを構築することを意味します。これらをユーザーが利用できるようにするが、PHPプラットフォームを離陸しない（メニューとリンクを組み込んで、ユーザーがPHPページ上のアプリと新しいアプリの間を簡単に移動できるようにする）。次に、PHPアプリケーションを改善しながら書き直します。

どちらがより良いかはわかりませんが、一方で（オプション1）ユーザーが2つの異なるプラットフォームを同時に使用することを強制しないことで、ユーザーにとってすべてがより簡単になる可能性があります。新しいプラットフォームを使用することによる改善は見られませんが、見栄えの良いすべてのものは別として、新しいプラットフォーム上のアプリケーションの機能はしばらくの間同じです。また、本質的にすべてのアプリを2回記述するので、自分自身（IT dep）の作業を追加すると思います。
一方、オプション2では、2つのプラットフォームの見た目が異なるため、ユーザーのエクスペリエンスは低下しますが、新しいアプリケーションの移行に伴い、新しいプラットフォームのメリットを実感できます。

あなたはそのようなことに遭遇したことがありますか？何を選びますか？それとも、私が提示したものとは異なる、より良い方法があるのでしょうか？私はあなたがどう思うか、そしてあなたはそれにどのように取り組みますか知りたいのですが。

両方のシナリオを考えてみましょう：

すべてを一度に移行

コードベースを移行している間、顧客は既存のアプリを使い続けます。移行にはかなりの時間がかかるため、バグ修正と機能開発のために、古いコードベースに保守チームを置く必要があります。古いコードベースで行うすべての変更は、新しいコードベースで行う必要があります。移行が行われない限り、コードのすべての行を2回書くことになり、移行に時間がかかるほどコストが高くなります。つまり、すべてを要約すると、完全な移行のターンアラウンドタイムはどのくらいになるでしょうか。ターンアラウンドタイムが続く限り、開発コストは急上昇します。

ピース単位の移行

このシナリオでは、二重の労力をより適切に制御できますが、それでも多くの追加コストが発生します。デプロイメントには2つの別個のプラットフォームが含まれ、デプロイメントの問題の2倍と追加のサーバーリソースが必要になります。非常にモジュール化されたアプリがない限り、コードの一部が必要なプラットフォームとは別のプラットフォームに存在することがよくあり、追加の移植とメンテナンスの労力を引き起こします。移行を行わない限り、開発コストは高くなります。同時に、機能のプレッシャーは、移行を完了するのに非常に長い時間を要することを意味します。

結論

個人的な経験から、2つのことをお話しします。

• プログラミング言語の切り替えが効果を上げることはめったにありません。費用便益分析から、PHPから.NETに切り替えても利益が出る可能性はほとんどありません。だから私の主なアドバイスは：しないでください。既存のコードベースで問題を解決してください。
• ピースバイピースが最善のアプローチですが、アプリケーションモジュールのレベルでそれを行うのは難しいでしょう。移行が完全に行われない限り、アーキテクチャの両側で機能を開発および保守する必要があることがわかります。顧客が最も必要とするものではなく、2倍の労力を制限する（それによりコストを削減する）ものに基づいて機能に優先順位を付けることは良い考えです。

財務上の理由から、私がこれまでに取り組んだほとんどの企業は2番目のアプローチを採用しました。彼らが＃1を達成するには、多くのお金、時間、リスクが必要です。ユーザーは、あなたの進捗状況と彼らとのやり取りを見ている限り、ほとんど＃2を理解するでしょう。この無駄のない平均的な経済状況では、誰もが一番のアプローチを取るとは思えません。

エンドユーザーに関する限り、ビッグバンアプローチが建設的になることはめったにありません。私はそれに反対し、正直に言うと、関係するアプリケーションの数を考えると、だれもがそれをオプションとして真剣に考えるとは思えません。

私はオプション2を使い、ケースバイケースで再作業を処理する傾向があります。確かに、これは紙のアプローチ1よりも時間がかかる可能性がありますが、実際には、アプローチ1を実行することでかなりの量のビジネスリスクが発生します。ユーザー側での問題は1つだけです。

さらに、Webサービスベースのアプリケーションの圧倒的な大部分がすでにphpで記述されている場合、.Netの専門知識はどのように利用できますか？

ユーザーが変化を経験しなければならない方法は、ビッグバン（多くのサポートコールをキューに入れる）または少しずつ（親しみが増す）のどちらかだと思います。私は、あなたが本当に完全にすべてのphpに近い状態から完全に.Netに移行するために実行する必要がある作業の正確なサイズを実際に決定していないと思う傾向があります。

まず、ジョエリの言うことすべてに同意します。

オプション1は本当に恐ろしいです。これを行い、Joeriが説明するようにサポートを継続しない場合、顧客が見る限り、数年間はサポートをシャットダウンします。2年後、彼らは事実上同じサイトにアクセスし、過去数年間に知って嫌いになったすべての同じ問題を抱えています。加えて、市場が暫定的に変化し、アプリケーションが時代遅れになり、大幅な刷新が必要になるリスク。また、2年間サポートを終了した場合、すべてのサービスリクエストがどうなると思いますか。彼らは消えません。少なくとも一部のユーザーは（おそらく）Accessでミッションクリティカルなシステムを「悪用」し、開発して、書き換えるシステムのギャップを埋めます。それでも、2つのプラットフォームをサポートすることになります...

オプション2は、両方のテクノロジーを長期間サポートすることを意味します。この期間はあなたが考えるよりも長くなり、永久に断片化されたエコシステム、つまり新しい.NETコードと混合して書き換えるのに経済的でないかなりの量のPHPコードになる可能性があります。

これを示唆している人に対しては強く反発してください。.NETですべてを書き直してから、書き換えたコードを製品と統合するよりも、PHPアプリケーションを提案する製品と統合するためのコードを書く方がはるかに安上がりです。 。

さらに、PHPコードの行数をCOCOMO 2ツールに入力して、書き換えを完了するために必要な開発者の人数と長さを把握します。

3番目のオプションがあります。

phpコードをWindowsサーバーとISSに移行します（.NETを実行する予定と同じものです！）

次に、.NETに新しいアプリケーションを追加し（古いアプリケーションをゆっくりと.NETに変換し）、ユーザーに単一のシステムのように見せることができます。