Wie kann mein multinationales Unternehmen von einer Entwicklungsplattform zur anderen wechseln?

Ich arbeite in der IT-Abteilung eines großen internationalen Unternehmens. Wir entwickeln verschiedene Intranet-Anwendungen für das Unternehmen (Beschwerden, Rabatte, Service Desk usw.). Jetzt haben wir uns für eine Migration von der PHP-Plattform zu .NET entschieden (die Integration in MS CRM Dynamics, Exchange und MS Office ist unter anderem ein Grund). Da das Unternehmen auf der aktuellen PHP-Plattform etwa 20 verschiedene Anwendungen verwendet, müssen wir den besten Weg finden, um sie alle auf die neue Plattform zu verschieben. Ich möchte nicht näher auf die Konvertierung des Codes usw. eingehen, da wir während der Migration alle diese Anwendungen verbessern möchten.

Wir haben uns also zwei Möglichkeiten ausgedacht, um diese Apps zu verschieben:

1. Unterstützt nur eine Plattform. Was würde es bedeuten? Erstellen Sie eine Homepage und migrieren Sie buchstäblich alle Apps wie sie sind nach .NET (ohne sie dabei zu verbessern). Nachdem das neue Intranet ausgeführt wurde, werden migrierte Anwendungen neu erstellt und verbessert. Das würde uns die Entwicklung eines Intranets in .NET ersparen und gleichzeitig die PHP-Plattform unterstützen.

2. Unterstützen Sie beide Plattformen für einige Zeit. Das würde bedeuten, nur eine Homepage und 1 oder 2 neue Anwendungen zu erstellen (die auf unserer PHP-Plattform nicht vorhanden sind). Diese für die Benutzer verfügbar machen, aber die PHP-Plattform nicht entfernen (wir würden Menüs und Links einbinden, um den Benutzern den Wechsel zwischen Apps auf der PHP-Seite und der neuen zu erleichtern). Dann würden wir anfangen, die PHP-Anwendungen neu zu schreiben und sie zu verbessern.

Jetzt bin ich mir nicht sicher, was besser wäre. Einerseits (Option 1) werden wir den Benutzern möglicherweise alles leichter machen, indem wir sie nicht zwingen, zwei verschiedene Plattformen gleichzeitig zu verwenden. Obwohl sie keine Verbesserung der neuen Plattform sehen werden, wird die Funktionalität der Anwendungen auf der neuen Plattform für einige Zeit dieselbe sein, abgesehen davon, dass alles besser aussieht. Ich denke auch, dass wir uns (IT-Abteilung) mehr Arbeit hinzufügen würden, da wir im Wesentlichen jede App zweimal schreiben würden.
Andererseits hätten Benutzer in Option zwei (2) schlechtere Erfahrungen, da zwei Plattformen unterschiedlich aussehen, aber sie würden die Vorteile der neuen Plattform erkennen, wenn neue Anwendungen verschoben werden.

Ist jemand von euch auf so etwas gestoßen? Was würdest du wählen? Oder gibt es vielleicht sogar einen anderen, besseren Weg als den, den ich vorgestellt habe? Ich würde gerne wissen, was Sie denken und wie Sie das angehen würden.

Betrachten wir beide Szenarien:

Alles auf einmal Migration

Während Sie Ihre Codebasis migrieren, verwenden Ihre Kunden weiterhin Ihre vorhandenen Apps. Da die Migration nicht trivial lange dauert, benötigen Sie ein Wartungsteam auf der alten Codebasis, um Fehler zu beheben und Funktionen zu entwickeln. Jede Änderung, die Sie an der alten Codebasis vornehmen, muss in der neuen Codebasis erfolgen. Am Ende schreiben Sie jede Codezeile doppelt so lange, wie die Migration nicht abgeschlossen ist. Je teurer die Migration, desto teurer wird sie. Es läuft also alles darauf hinaus: Wie wird die Bearbeitungszeit für die vollständige Migration sein? Ihre Entwicklungskosten werden so lange steigen, wie die Bearbeitungszeit dauert.

Stück für Stück Migration

In diesem Szenario haben Sie eine bessere Kontrolle über den doppelten Aufwand, aber Sie werden immer noch viele zusätzliche Kosten haben. Ihre Bereitstellung umfasst zwei separate Plattformen mit doppelt so vielen Bereitstellungsproblemen und zusätzlichen Serverressourcen. Wenn Sie nicht über eine sehr modular organisierte App verfügen, werden Sie feststellen, dass auf der anderen Plattform als der, auf der Sie sie benötigen, häufig ein Code vorhanden ist, was zusätzlichen Portierungs- und Wartungsaufwand verursacht. Solange die Migration nicht durchgeführt wird, sind Ihre Entwicklungskosten höher. Gleichzeitig bedeutet der Funktionsdruck, dass Sie sehr lange brauchen werden, um die Migration abzuschließen.

Fazit

Aus persönlicher Erfahrung kann ich Ihnen zwei Dinge sagen:

• Das Wechseln der Programmiersprache zahlt sich selten aus. Aufgrund einer Kosten-Nutzen-Analyse ist es sehr unwahrscheinlich, dass ein Wechsel von PHP zu .NET rentabel ist. Mein Hauptratschlag lautet also: Nicht. Versuchen Sie, Ihre Probleme mit Ihrer vorhandenen Codebasis zu lösen.
• Stück für Stück ist der beste Ansatz, aber auf der Ebene der Anwendungsmodule fällt es Ihnen schwer, dies zu tun. Sie werden feststellen, dass Sie Funktionen auf beiden Seiten der Architektur entwickeln und warten müssen, solange die Migration nicht vollständig abgeschlossen ist. Es kann eine gute Idee sein, Funktionen zu priorisieren, die nicht darauf basieren, was Kunden am meisten benötigen, sondern darauf, was den doppelten Aufwand begrenzt (wodurch die Kosten gesenkt werden).

Aus finanziellen Gründen haben sich die meisten Unternehmen, für die ich gearbeitet habe, zu Recht für den zweiten Ansatz entschieden. Es braucht viel Geld, Zeit und Risiken, um die Nummer 1 zu erreichen. Benutzer würden meistens # 2 verstehen, solange sie Ihren Fortschritt und Ihre Interaktion mit ihnen sehen. In dieser schlanken und gemeinen Wirtschaft bezweifle ich, dass irgendjemand den ersten Ansatz wählen würde.

Big-Bang-Ansätze sind für Endnutzer selten konstruktiv. Ich würde davon abraten und um ehrlich zu sein, kann ich nicht glauben, dass jemand es angesichts der Anzahl der betroffenen Anträge ernsthaft als Option in Betracht ziehen würde.

Ich würde gerne Option zwei wählen und von Fall zu Fall Nacharbeiten durchführen. Zugegeben, dies kann länger dauern als der Ansatz auf dem Papier, aber in Wirklichkeit eröffnen Sie ein erhebliches Geschäftsrisiko, wenn Sie den ersten Ansatz wählen, und ich würde wirklich nicht gerne am ersten Tag bei den Supportanrufen dabei sein, wenn es überhaupt einen gibt nur ein kleines Problem auf der Benutzerseite.

Wie ist das verfügbare .Net-Know-how, wenn der überwiegende Teil Ihrer auf Webdiensten basierenden Anwendungen bereits in PHP geschrieben ist?

Ich denke, so oder so müssen Ihre Benutzer Veränderungen erleben, entweder Urknall (viele Support-Anrufe) oder stückweise (zunehmende Vertrautheit). Ich neige dazu zu glauben, dass Sie nicht wirklich genau herausgefunden haben, wie viel Arbeit erledigt werden muss, um von nahezu vollständigem PHP zu vollständig .Net zu gelangen.

Erstens stimme ich allem zu, was Joeri sagt.

Option eins ist wirklich schrecklich. Wenn Sie dies tun und den Support nicht fortsetzen, wie Joeri es beschreibt, stellen Sie den Support möglicherweise für ein paar Jahre ein, soweit Ihr Kunde dies sieht. Nach zwei Jahren erhalten sie effektiv dieselbe Website mit denselben Problemen, die sie in den letzten Jahren kennen und hassen gelernt haben. Plus das Risiko, dass sich der Markt in der Zwischenzeit verändert hat und die Anwendung veraltet ist und einer umfassenden Überarbeitung bedarf. Wenn Sie den Support für zwei Jahre einstellen, was wird Ihrer Meinung nach mit allen Serviceanfragen passieren? Sie werden nicht weggehen. Zumindest einige Ihrer Benutzer werden "Schurken" werden und unternehmenskritische Systeme in (wahrscheinlich) Access entwickeln, um die Lücken in den Systemen zu schließen, die Sie neu schreiben - dann unterstützen Sie immer noch zwei Plattformen ...

Option zwei bedeutet, dass Sie beide Technologien über einen längeren Zeitraum unterstützen. Dieser Zeitraum wird länger sein als Sie denken und es könnte zu einem dauerhaft fragmentierten Ökosystem kommen - dh zu einer erheblichen Menge an PHP-Code, dessen Umschreiben in Verbindung mit neuerem .NET-Code nicht wirtschaftlich ist.

Drücken Sie hart gegen jeden, der dies vorschlägt. Es ist viel billiger, Code zu schreiben, um die PHP-Anwendungen in die von Ihnen vorgeschlagenen Produkte zu integrieren, als alles in .NET neu zu schreiben und dann den neu geschriebenen Code in die Produkte zu integrieren. Vergessen Sie nicht, dass die Integration nicht auf magische Weise erfolgt, wenn Sie .NET verwenden .

Nehmen Sie die Anzahl der Zeilen PHP-Code und fügen Sie ihn in ein COCOMO 2-Tool ein, um eine Vorstellung davon zu erhalten, wie lange und wie viele Entwickler Sie benötigen, um das Umschreiben abzuschließen.

Sie haben eine dritte Option: -

Migrieren Sie den PHP-Code auf Ihren Windows-Server und die ISS (derselbe, auf dem Sie .NET ausführen möchten!).

Sie können dann neue Anwendungen in .NET hinzufügen (und einige ältere langsam in .NET konvertieren), während Sie Ihren Benutzern ein einzelnes System präsentieren.