.NET-Modernisierung

Legacy-.NET voranbringen, ohne das Geschäft anzuhalten

Die Anwendung trägt immer noch das Geschäft – genau deshalb will sie niemand anfassen. Wir bringen WebForms-, WCF-, VB.NET- und .NET-Framework-Systeme Stück für Stück auf aktuelles .NET, wobei Alt und Neu parallel laufen, bis auf der alten Seite nichts mehr übrig ist.

Einstiegsangebote mit festem Umfang Termin buchen

Typische Ausgangslagen

Eine WebForms- oder WCF-Anwendung trägt noch immer einen kritischen Teil des Geschäfts, und die Leute, die sie geschrieben haben, sind nicht mehr da.
Jede Schätzung für die Modernisierung lief auf eine Neuentwicklung hinaus, für die Sie die Roadmap unmöglich einfrieren können.
Sie sind an Windows Server und IIS gebunden, weil die Anwendung nirgendwo sonst läuft.
Sicherheits- und Compliance-Prüfungen bemängeln immer wieder eine nicht mehr unterstützte Framework-Version.

Wie wir modernisieren

Jedes Mal nach demselben Muster – weil es das einzige ist, das wir je bis zum Ende haben laufen sehen.

Bewertung aus Erfahrung, nicht aus Recherche

Wir haben in jedem Stack der Liste unten Produktivcode geschrieben – die Analyse ist also Erfahrung statt einer Recherchephase, die Sie bezahlen.

Zuerst den Build freischalten

Projekte im SDK-Stil, gemeinsame Bibliotheken für mehrere Ziel-Frameworks und eine Pipeline, die von selbst läuft. Das zahlt sich aus, bevor die Migration abgeschlossen ist, und macht alles Weitere wiederholbar.

Strangler statt Big Bang

Der neue Stack entsteht neben dem alten. Teilstücke ziehen nacheinander hinter dieselben URLs um, jedes mit einem Weg zurück.

Ihr Team befähigen, es zu Ende zu bringen

Jedes Teilstück wird als Muster dokumentiert. Ziel ist, dass Ihre eigenen Entwickler die späteren Teilstücke übernehmen und wir reviewen.

.NET-Modernisierung

Jeder Stack auf dieser Liste, produktiv ausgeliefert

Legacy-.NET ist nicht ein Problem. Eine WebForms-App, eine WCF-Serviceschicht und ein WinForms-Client geraten aus völlig unterschiedlichen Gründen ins Stocken, und eine Schätzung ist nur so gut wie die Person, die in diesem Stack tatsächlich gearbeitet hat. Wir haben in allen davon Produktivcode geschrieben – auch in den VB.NET-Projekten, die niemand öffnen will –, die Bewertung ist also Erfahrung statt einer Recherchephase, die Sie bezahlen.

2002–2012ASP.NET WebFormsASP.NET Core mit Razor Pages oder Blazor
Seitenlebenszyklus, ViewState und Server-Controls haben kein Gegenstück, das Markup wird also tatsächlich neu geschrieben. Die Geschäftslogik darunter meist nicht – und die beiden zu trennen, ist der Großteil der Arbeit.
2003–2010ASMX- und WCF-DiensteASP.NET-Core-APIs, gRPC oder CoreWCF
Bindings, Behaviors und SOAP-Verträge lassen sich nicht portieren. Wo die Aufrufer Dritte sind, die Sie nicht ändern können, hält CoreWCF den Vertrag am Leben, während alles dahinter umzieht.
2007–2015Silverlight- und Browser-Plugin-ClientsEin Web-Frontend oder eine mobile App
Hier gibt es nichts, wohin man migrieren könnte – die Runtime ist aus allen Browsern verschwunden. Solche Projekte beginnen mit einem Gespräch darüber, was die Anwendung eigentlich leisten musste.
2008–2019DataSets, EF6 und handgeschriebenes ADO.NETEF Core, oder Dapper, wo es sich lohnt
In der Datenschicht wird eine einfache Portierung teuer. Query-Übersetzung, Transaktionen und Lazy Loading verhalten sich anders, und das zeigt sich in der Produktion statt beim Kompilieren.
2009–2016ASP.NET MVC 5 und Web API 2ASP.NET Core MVC
Das, was auf dieser Liste einer mechanischen Portierung am nächsten kommt. Die eigentliche Arbeit sind Hosting, Konfiguration, Dependency Injection und die Middleware-Pipeline – nicht Ihre Controller.
2002–heuteWinForms und WPFAktuelles .NET für den Desktop, oder MAUI, wenn es aufs Smartphone gehört
Beide laufen noch auf modernem .NET, eine Neuentwicklung ist also selten nötig. Was blockiert, sind verwaiste Control-Suiten von Drittanbietern und COM-Interop – danach suchen wir als Erstes.
Jede Version.NET-Framework-KlassenbibliothekenAktuelles .NET, während des Umzugs mit Multi-Targeting
Gemeinsame Bibliotheken ermöglichen es, altes und neues System parallel zu betreiben. Sie zuerst auf Multi-Targeting umzustellen, ist meist der Schlüssel für alles andere auf dieser Liste.
Laufendpackages.config, alte csproj-Dateien, IIS auf Windows ServerSDK-Projekte, Container, CI, die von selbst läuft
Unspektakulär – und genau das macht den Rest wiederholbar. Es zahlt sich außerdem lange vor dem Ende der Migration aus, weshalb es oft der richtige erste Schritt ist.

Keine Big-Bang-Neuentwicklung

Nichts auf dieser Liste wird in einem einzigen Schritt ersetzt. Was funktioniert, ist das Strangler-Muster: Den neuen Stack neben dem alten aufbauen, Stück für Stück hinter denselben URLs umziehen und beide betreiben, bis auf der alten Seite nichts mehr übrig ist. Auf dem Papier sieht das langsamer aus – und es ist die einzige Variante, die wir je bis zum Ende haben laufen sehen.

Einstiegsangebote mit festem Umfang

Ein erster Schritt, den eine Führungskraft freigeben kann

Jede Zusammenarbeit kann mit einem dieser Angebote beginnen. Jedes hat einen Namen und einen vor Beginn schriftlich festgelegten Umfang. So ist die erste Entscheidung eine kleine – und Sie sehen, wie wir arbeiten, bevor Sie sich auf etwas Größeres festlegen.

2 Wochen

Modernisierungsanalyse

Jedes Projekt, jede Abhängigkeit und jede Hosting-Annahme der Lösung, zugeordnet zu dem, was daraus wird – und kalkuliert als Strangler-Plan, den Sie Phase für Phase finanzieren können.

Was enthalten ist

Bestandsaufnahme von Projekten, Paketen, Drittanbieter-Controls und COM-Interop
Was sich mechanisch portieren lässt, was wirklich neu geschrieben wird und was nicht überleben sollte
Nach Risiko gewichteter, gestaffelter Migrationsplan mit Schätzungen
Eine Ergebnispräsentation für diejenigen, die es bezahlen

Was Sie mitnehmen

Ein kalkulierter, gestaffelter Plan, mit dem Sie in die Budgetrunde gehen können – und den Sie behalten, ob wir die Arbeit machen oder nicht.

Dazu anfragen

3 Wochen

Build- & Pipeline-Modernisierung

Projekte im SDK-Stil, zeitgemäße Paketverwaltung und eine CI-Pipeline, die von selbst läuft. Der unspektakuläre Schritt, der jeden weiteren wiederholbar macht.

Was enthalten ist

Alte csproj-Dateien und packages.config umgestellt
Gemeinsame Bibliotheken für den Umzug auf mehrere Ziel-Frameworks ausgelegt
CI baut und testet jede Änderung
Containerisierter Build und Deployment, wo es passt

Was Sie mitnehmen

Eine Lösung, die überall gleich baut, bereit für den Start der Migration – und die sich schon vorher auszahlt.

Dazu anfragen

6–8 Wochen

Migration des ersten Teilstücks

Ein klar abgegrenzter Teil der Anwendung auf modernes .NET gebracht, neben dem alten System hinter denselben URLs betrieben und in Produktion bewiesen.

Was enthalten ist

Teilstück ausgewählt nach Nutzen und danach, wie sauber es sich herauslösen lässt
Neuer Stack neben dem alten aufgebaut
Datenverkehr Stück für Stück umgeleitet, mit Rollback
Das Vorgehen dokumentiert, damit Ihr Team es wiederholen kann

Was Sie mitnehmen

Das Strangler-Muster an Ihrem eigenen System bewiesen, mit echten Nutzern auf der neuen Seite – und eine belastbare Schätzung für den Rest.

Dazu anfragen

Jedes Angebot erhalten Sie zum Festpreis, sobald wir den Umfang gesehen haben – und ein Festpreis bleibt fest. Brauchen wir länger, ist das unser Problem, nicht Ihres.

Fragen, die Einkäufer stellen

Müssen wir unsere WebForms-Anwendung neu schreiben?

Das Markup ja – Seitenlebenszyklus und ViewState haben in modernem .NET kein Gegenstück. Die Geschäftslogik darunter meist nicht, und die beiden voneinander zu trennen ist der Großteil der Arbeit. Deshalb steht die Analyse am Anfang.

Können unsere WCF-Dienste ihre bestehenden Aufrufer behalten?

Oft ja. Wo die Aufrufer Dritte sind, die Sie nicht ändern können, hält CoreWCF den SOAP-Vertrag am Leben, während alles dahinter auf modernes .NET umzieht.

Wie lange dauert eine Migration von .NET Framework?

Das hängt weit mehr von der Datenschicht und den Drittanbieter-Abhängigkeiten ab als von der Größe der Codebasis. Die zweiwöchige Analyse ist genau dafür da, diese Frage mit einer gestaffelten Schätzung statt mit einer Vermutung zu beantworten.

Arbeiten Sie auch mit VB.NET?

Ja. Wir haben VB.NET produktiv ausgeliefert und lesen, portieren oder kapseln es – auch die Teile, die im aktuellen Team niemand öffnen will.

Läuft bei Ihnen noch .NET Framework?

Sagen Sie uns, was die Anwendung macht und worauf sie läuft. Wir sagen Ihnen, was der Umzug tatsächlich bedeutet – und welches Teilstück das erste sein sollte.

Termin buchen Nachricht senden