Das wertvollste Wissen einer gewachsenen .NET-Anwendung steht selten vollständig in einem Fachkonzept. Es steckt in Quellcode, Daten, Berichten, Schnittstellen und den Wegen, auf denen Menschen ihre Arbeit tatsächlich erledigen. Wer dieses Wissen vor der Modernisierung sichtbar und prüfbar macht, kann Technik erneuern, ohne fachliche Sicherheit dem Zufall zu überlassen.
Ziel Fachwissen aus Code, Daten, Dokumenten und Bedienwegen ausdrücklich beschreiben.
Grenze Technische Altlasten dürfen entfallen. Bestätigte Fachregeln und gespeicherte Daten müssen überprüfbar bleiben.
Nachweis Modelle, Codelisten, Verträge und Tests zeigen, dass ein modernisiertes Feature fachlich trägt.
Wo Fachwissen in .NET-Anwendungen tatsächlich steckt
Eine Validierung in einer C#-Methode kann eine vertragliche Regel abbilden. Ein enum kann eine historisch gewachsene Codeliste sein. Eine SQL-Abfrage kann festlegen, welche Fälle in einem Bericht erscheinen. Eine ausgegraute Schaltfläche kann eine Berechtigung ausdrücken, die in keinem Rollenhandbuch steht.
Zu den wichtigsten Fundstellen gehören:
- Fachobjekte, Beziehungen und Berechnungen im Quellcode
- Datenbankschemata, gespeicherte Werte und Migrationshistorien
- Konstanten, Aufzählungen, Ressourcen und Konfigurationen
- Berechtigungen, Statusübergänge und Freigaben
- Berichte, Vorlagen, Exporte und Importformate
- Schnittstellen zu anderen Anwendungen und Geräten
- Fehlermeldungen, Protokolle und bekannte Sonderfälle
- reale Benutzerwege einschließlich seltener Monats-, Jahres- und Ausnahmeprozesse
Nicht jede alte Implementierung ist erhaltenswert. Jede fachlich wirksame Entscheidung sollte jedoch verstanden werden, bevor der Code verschwindet, der sie bisher getragen hat.
Wissensinventur statt bloßer Codeanalyse
Eine technische Analyse beantwortet, welche Frameworks, Pakete und Plattformen veraltet sind. Eine Wissensinventur fragt zusätzlich, was die Anwendung für das Unternehmen bedeutet. Dafür betrachten wir Quellcode, Daten, Dokumentation und Benutzerbeobachtung gemeinsam.
Das Ergebnis ist keine lose Liste von Fundstellen, sondern eine Wissenslandkarte. Sie ordnet Regeln einem Fachobjekt, einem verantwortlichen Bereich, einem Benutzerweg und einem späteren Nachweis zu. Widersprüche bleiben ausdrücklich sichtbar: Wenn Dokumentation, Code und gelebter Ablauf voneinander abweichen, ist genau diese Abweichung eine notwendige Fachentscheidung.
Fachlich notwendiges Verhalten von technischen Altlasten trennen
Altcode ist eine Quelle, aber kein unveränderliches Gesetz. Duplizierte Maskenlogik, nicht mehr unterstützte Bibliotheken, technische Umwege und unbenutzte Varianten dürfen verschwinden. Erhalten bleiben muss, was fachlich bestätigt wurde oder sich aus notwendigen Daten- und Prozessbedingungen ergibt.
Für jede wichtige Regel helfen vier Fragen:
- Welchen fachlichen Zweck erfüllt sie?
- Für welche Daten, Rollen und Ausnahmen gilt sie?
- Wer kann bestätigen, dass sie weiterhin benötigt wird?
- Woran erkennen wir nach der Modernisierung, dass sie korrekt wirkt?
Fehlt auf eine dieser Fragen eine belastbare Antwort, wird die Unsicherheit dokumentiert und in einem begrenzten Feature geklärt. Sie sollte nicht unbemerkt in eine neue Architektur kopiert werden.
Wissen in prüfbare Artefakte überführen
Fachwissen bleibt leichter erhalten, wenn es nicht erneut an zufälligen Stellen im neuen Quellcode verschwindet. Abhängig vom Inhalt wird es in eine passende Form überführt:
- Fachobjekte, Beziehungen und Zustände werden zu expliziten Modellen.
- Auswahlwerte und Länderregeln werden zu versionierten Codelisten oder Konfigurationen.
- Ein- und Ausgabeformate werden als validierbare Schnittstellenverträge beschrieben.
- Geschäftsregeln werden durch verständliche Beispiele und automatisierte Tests abgesichert.
- wichtige Bedienwege erhalten nachvollziehbare Akzeptanzkriterien.
- wiederkehrende Projektregeln werden in Dokumentation und Skills festgehalten.
Diese Artefakte sind keine Nebenprodukte. Sie bilden den stabilen fachlichen Kern, an dem Menschen, klassische Werkzeuge und KI-Agenten arbeiten können.
Featureweise modernisieren und am echten Benutzerweg prüfen
Eine vollständige Anwendung auf einmal umzuschreiben, macht Ursachen und Wirkungen schwer unterscheidbar. Ein begrenztes Feature schafft dagegen einen prüfbaren Arbeitsraum: Der heutige Ablauf wird beobachtet, seine Regeln werden beschrieben, die technische Umsetzung wird erneuert und anschließend im realen Anwendungskontext geprüft.
Frühe Builds sind dabei wichtiger als späte Vollständigkeit. Sobald Navigation, Datenzugriff und ein erster Benutzerweg lauffähig sind, zeigen sich falsche Annahmen. Automatisierte Tests sichern Fachregeln ab; UI-Prüfungen zeigen zusätzlich, ob ein Benutzer das Feature tatsächlich erreichen und erfolgreich verwenden kann.
KI-Agenten als Werkzeug mit klaren Grenzen einsetzen
KI-Agenten können große Codebestände untersuchen, wiederkehrende Muster erkennen, Änderungen umsetzen und Prüfungen ausführen. Verlässlich werden sie erst durch einen klaren Auftrag, begrenzte Änderungsräume und konkrete Fertigkriterien.
Die Verantwortung bleibt beim Menschen: Fachbereiche entscheiden über die Bedeutung einer Regel, Architektur und Betrieb setzen Grenzen, und die Freigabe orientiert sich an nachvollziehbaren Ergebnissen. Modelle und Werkzeuge dürfen wechseln. Die Wissenslandkarte, Fachmodelle, Tests, Korrekturen und die Definition eines guten Ergebnisses müssen beim Unternehmen bleiben.
Ergebnis-Checkliste für einen modernisierbaren Teilbereich
Ein Teilbereich ist vorbereitet, wenn folgende Ergebnisse vorliegen:
- Abgrenzung: Feature, Benutzergruppen, Daten und Schnittstellen sind benannt.
- Wissenslandkarte: Regeln, Ausnahmen und verantwortliche Ansprechpartner sind zugeordnet.
- Stabiler Kern: Datenformate und fachlich bestätigtes Verhalten sind beschrieben.
- Zielbild: Technische Leitplanken und wiederverwendbare Komponenten sind festgelegt.
- Nachweis: Fachtests, Build und der reale Benutzerweg können wiederholt geprüft werden.
- Eigentum: Modelle, Codelisten, Tests, Skills und Entscheidungen bleiben im Projekt verfügbar.
Die übergeordnete Planung von Team, Arbeitsumgebung, Kosten und dauerhaftem Modernisierungsprozess beschreibt der Leitfaden Wie plane ich eine App-Modernisierung?.
Fachwissen sichern und .NET-Anwendungen kontrolliert erneuern
APLICONUS verbindet Bestandsanalyse, explizite Fachmodelle, wiederverwendbare Komponenten und agentenbasierte Entwicklung zu einem überprüfbaren Modernisierungsweg.