Ich übernehme keine Wartung technisch veralteter Projekte mehr, aber ich migriere sie oft auf aktuelle Technologien. Dies erfordert besondere Sorgfalt: Eine Versionsänderung verbirgt oft Bibliotheken, die ersetzt werden müssen, Architekturen, die neu strukturiert werden müssen, und Konfigurationen, die neu überdacht werden müssen.
In Umgebungen mit strengen Sicherheitskontrollen wird eine Version, die keine Updates mehr erhält, schnell zu einem Problem.
Sobald der Support endet, stoppen Sicherheitsupdates. Wo Sicherheits- und Datenschutzanforderungen gelten, kann dies eine Veröffentlichung blockieren oder in einer Prüfung auftauchen.
Der einfachste Fall: dasselbe Produkt, in einer neueren Version.
Sogar hier kann der Sprung groß sein. Der Wechsel von AngularJS zu Angular bedeutet im Wesentlichen, die Benutzeroberfläche neu zu schreiben; zwischen den Angular-Versionen geht man schrittweise vor, wobei man die Breaking Changes bei jedem Schritt überprüft.
Komponenten, die auf veralteten Bibliotheken basieren, müssen oft neu geschrieben werden, hauptsächlich auf der Client-Seite, aber auch auf dem Server.
Viele JavaScript-Bibliotheken verbergen eine umfangreiche Neuentwicklung hinter einer Versionsänderung. Auf dem Server haben einige die Lizenz geändert: Dies betrifft Anwendungen, die iTextSharp 4.1.6 verwenden, die letzte LGPL-Version. Spätere Versionen sind nur unter der AGPL oder einer kommerziellen Lizenz erhältlich, und für aktuelles .NET gibt es nur eine inoffizielle Portierung von 4.1.6.
Die Übernahme aktueller Standards bedeutet eine Umstrukturierung, nicht nur ein Neukompilieren.
Viele .NET Framework-Anwendungen verwenden veraltete Muster wie statische Klassen und handgefertigte Abhängigkeiten, während aktuelles .NET auf Dependency Injection aufgebaut ist. Einige Technologien haben auch kein direktes Äquivalent.
Ich habe Web Forms-Anwendungen zu modernen Web-Apps migriert, den Code-behind in Web APIs umgewandelt und in einem Fall zu Blazor, um auf einem vollständigen Microsoft-Stack zu bleiben. Auf ähnliche Weise habe ich WCF-Dienste zu REST-APIs verschoben: Hier ist der heikle Teil oft das Datenformat, weil die Clients die WCF-Serialisierung für selbstverständlich hielten.
Von einem traditionellen Server zur Cloud ist die Migration nicht nur eine Frage der Anwendung.
Konfiguration, Architektur, Berechtigungen und Datenzugriff müssen geprüft und angepasst werden, damit die Lösung in der Cloud funktioniert. Mit diesen Themen habe ich mich bei Migrationen dieser Art befasst.
Ein Inventar der Abhängigkeiten, Bibliotheken, Lizenzen und Integrationen. Für jede davon entscheiden Sie, ob sie aktualisiert, ersetzt oder neu geschrieben werden soll und welche Umstrukturierung erforderlich ist.
Die Funktionen, die benötigt werden, um zu beweisen, dass die neue Architektur hält, werden so früh wie möglich ausgeführt.
Ein Schritt-für-Schritt-Plan mit Regressionstests in jeder Phase.
Die Nutzer des Systems beginnen mit dem Testen der migrierten Teile, sobald diese bereit sind.
Wo möglich, laufen beide Anwendungen parallel. Bei der Migration von AngularJS zu Angular konnten die Nutzer sie vergleichen und für noch nicht migrierte Funktionen weiter die alte Anwendung verwenden.
Jede Migration ist ein einzigartiger Weg: Sie hängt davon ab, wo Sie starten, wohin Sie wollen und von all diesen Faktoren. Was sich nicht ändert, ist die Methode: Risiken werden zuerst analysiert, gefolgt von schrittweisen und überprüfbaren Schritten.
Die initiale Analyse kann auch ein eigenständiges Engagement sein. Häufiger, bei direkten Kunden, ist sie der erste Schritt eines Weges, der direkt zur migrierten Anwendung in Produktion führt, ohne dass Sie die Entwicklung intern übernehmen müssen.
Bei Migrationen verwende ich Coding Agents mit der spec-driven Methode: Ausgehend vom bestehenden Code lege ich die Abfolge der Schritte fest und wechsle zwischen den vom Agenten durchgeführten Tests und manuellen Überprüfungen.
Bei Legacy-Code bewerte ich auch, wie sich eine Änderung überprüfen lässt: Datenbankabhängigkeiten, externe Dienste und Konfigurationen können wiederholbare Tests erschweren. Eine Testumgebung und Regressionsprüfungen vorzubereiten, ist Teil des Migrationsplans.
Microsoft selbst hat sein Upgrade-Tool, Upgrade Assistant, durch einen KI-basierten Agenten ersetzt.
Die Quellen beschreiben Prüfung und Testbarkeit. Den Vorbereitungsaufwand in die Einführungskosten einzubeziehen, ist ein vorgeschlagenes Bewertungskriterium und kein allgemeines Maß für den Nutzen von Agenten.