In diesem Projekt begleiteten wir die Transformation von WPF zu Angular-Microfrontends für ein Unternehmen. Im Mittelpunkt stand die Ablösung einer monolithischen WPF-Anwendung mit klassischer Schichtenarchitektur durch eine moderne Frontend-Architektur, ergänzt um die Modernisierung und Entkopplung der Backend-Logik. Zusätzlich übernahmen wir Aufgaben rund um Sicherheit, Entwicklungsrichtlinien sowie Build- und Deployment-Pipelines.

Ausgangslage

Unser Auftraggeber war ein Unternehmen. Ausgangspunkt war eine monolithische WPF-Anwendung in einer 3-Tier-Architektur, die in eine Angular-Microfrontend-Architektur transformiert werden sollte. Damit verbunden war die Aufgabe, die bestehende Backend-Logik zu modernisieren und zu entkoppeln sowie Anforderungen an Authentifizierung, Absicherung und Entwicklungsprozesse in die Umsetzung einzubeziehen.

Lösung

Sie sehen verbundene Modulbausteine, die zu Server und Cloud eine neue Architektur bilden.

Wir wirkten an der Migration zur Microfrontend-Architektur mit und setzten die Transformation fachlich und technisch um. Dazu gehörten die Modernisierung und Entkopplung der Backend-Logik, die Einbindung von OAuth2, OIDC, MFA und asymmetrischer Verschlüsselung sowie die Ausarbeitung von Entwicklungsrichtlinien.

Ergänzend definierten und unterstützten wir Semantic Versioning sowie Build- und Deployment-Pipelines. Die Umsetzung erfolgte von Juli 2023 bis Dezember 2023 in einem Team mit 12 Beteiligten. Im Projekt arbeiteten wir an Webentwicklung und an Themen der Datenbankentwicklung, Schnittstellen und Datenmigration.

Ergebnis

Geliefert wurde die Transformation einer monolithischen WPF-Anwendung in eine Angular-Microfrontend-Architektur. Bestandteil des abgeschlossenen Projekts waren außerdem die modernisierte und entkoppelte Backend-Logik, Sicherheitsbausteine für Authentifizierung und Verschlüsselung sowie Entwicklungsrichtlinien, Semantic Versioning und Build- und Deployment-Pipelines.

Das Projekt lief von Juli 2023 bis Dezember 2023 und hatte eine Laufzeit von 6 Monaten.

Technik

  • Angular für die Microfrontend-Architektur im Frontend
  • .NET mit C# für Backend-Logik
  • WPF und XAML im bestehenden Anwendungskontext der Ausgangslösung
  • Oracle im Datenbankumfeld
  • TypeScript und SCSS im Frontend
  • Docker für die Bereitstellung von Anwendungsbestandteilen
  • Azure DevOps für Build- und Deployment-Pipelines
  • OAuth2 und OIDC für Authentifizierung und Identitätsanbindung
  • MFA für zusätzliche Absicherung bei der Anmeldung
  • PKI für asymmetrische Verschlüsselung

Warum WPF zu Angular-Microfrontends sinnvoll sein kann

Bei der Modernisierung von Fachanwendungen stellt sich oft die Frage, wie eine gewachsene Desktop-Anwendung in eine zukunftsfähige Webarchitektur überführt werden kann. Der Schritt von WPF zu Angular-Microfrontends ist für solche Vorhaben interessant, wenn eine Anwendung fachlich gewachsen ist, mehrere Bereiche umfasst oder sich schrittweise erneuern lassen soll. Microfrontends sind ein Architekturansatz, bei dem eine große Oberfläche in fachlich getrennte, eigenständig entwickelbare Teile zerlegt wird. Für Entscheider ist wichtig: Das ist kein Selbstzweck, sondern ein Mittel, um Verantwortlichkeiten sauber zu trennen und Änderungen besser planbar zu machen.

Ein solcher Ansatz passt vor allem dann, wenn bestehende Funktionen nicht in einem einzigen großen Umbruch ersetzt werden sollen. Typisch ist vielmehr ein kontrollierter Übergang, bei dem alte und neue Teile über eine gewisse Zeit nebeneinander bestehen. Das reduziert die fachliche und organisatorische Komplexität eines Komplettumbaus, verlangt aber klare Architekturentscheidungen. Dazu zählen die Aufteilung nach fachlichen Domänen, gemeinsame Standards für Navigation und Gestaltung sowie Regeln dafür, welche Funktionen zentral und welche dezentral umgesetzt werden.

Auch auf der Backend-Seite ist die Architekturentscheidung wesentlich. Wenn Frontend-Bausteine unabhängig werden sollen, muss die zugrunde liegende Logik häufig ebenfalls entkoppelt werden. Entkopplung bedeutet, dass Funktionen und Datenzugriffe so getrennt werden, dass Änderungen in einem Bereich andere Bereiche weniger stark beeinflussen. In solchen Projekten geht es deshalb nicht nur um eine neue Oberfläche, sondern meist auch um Schnittstellen, Datenflüsse und Verantwortlichkeiten im Anwendungskern.

Sicherheitsfragen gehören früh auf die Agenda. Begriffe wie OAuth2 und OIDC beschreiben etablierte Verfahren für Anmeldung und Identitätsprüfung zwischen Anwendungen und zentralen Identitätssystemen. Mehrfaktor-Authentifizierung ergänzt die Anmeldung um einen weiteren Nachweis. Asymmetrische Verschlüsselung mit PKI arbeitet mit zusammengehörigen Schlüsseln und wird eingesetzt, wenn Identitäten, Signaturen oder geschützte Kommunikationswege sauber abgesichert werden sollen. Welche Ausgestaltung dafür passend ist, hängt vom Einsatzkontext ab und sollte fachlich, technisch und organisatorisch abgestimmt werden.

Für Unternehmen und öffentliche Auftraggeber ist entscheidend, dass die Modernisierung nicht nur technisch möglich ist, sondern auch in Betrieb, Wartung und Weiterentwicklung tragfähig bleibt. Genau deshalb werden in solchen Vorhaben Architektur, Sicherheitskonzept, Standards und Delivery-Prozess gemeinsam betrachtet. Wer ein ähnliches Projekt plant, kann den Rahmen zunächst mit dem Projekt-Check schärfen.

Wie solche Modernisierungen typischerweise umgesetzt werden

Ein Vorhaben zur Modernisierung einer bestehenden Anwendung beginnt typischerweise nicht mit der Oberfläche, sondern mit einer gemeinsamen Sicht auf Ziele, Randbedingungen und Abhängigkeiten. In solchen Projekten wird zuerst geklärt, welche fachlichen Bereiche es gibt, welche Teile besonders kritisch sind und welche technischen Kopplungen den Umbau erschweren. Erst auf dieser Grundlage lässt sich beurteilen, wie der Weg von der bestehenden Anwendung zu einer neuen Architektur sinnvoll geschnitten wird.

Danach folgt üblicherweise ein Architektur- und Umsetzungsbild. Dabei wird festgelegt, wie die Zielarchitektur aussehen soll, welche Frontend-Teile getrennt werden, wie sie zusammenspielen und welche Backend-Funktionen dafür bereitstehen müssen. Für Entscheider ist dabei wichtig, dass Begriffe wie Microfrontend oder entkoppeltes Backend nicht nur Technik beschreiben. Sie legen auch fest, wie Teams zusammenarbeiten, wie Änderungen freigegeben werden und wie Verantwortung zugeschnitten ist.

Parallel werden Qualitäts- und Betriebsanforderungen konkretisiert. Dazu gehören unter anderem Anmeldung, Berechtigungen, Schutz sensibler Daten, Nachvollziehbarkeit von Änderungen sowie ein verlässlicher Auslieferungsprozess. Build- und Deployment-Pipelines automatisieren wiederkehrende Schritte von der Prüfung bis zur Bereitstellung. Das reduziert manuelle Eingriffe und schafft eine nachvollziehbare Grundlage für Releases. Semantic Versioning ist ein Regelwerk für Versionsstände, das Änderungen in einer konsistenten Form kennzeichnet und die Abstimmung zwischen beteiligten Komponenten erleichtert.

In der Umsetzung empfiehlt sich meist ein schrittweises Vorgehen mit enger Abstimmung zwischen Fachseite, Architektur und Entwicklung. So können einzelne Bereiche vorbereitet, migriert und in den Gesamtzusammenhang eingeordnet werden, ohne den Überblick über Abhängigkeiten zu verlieren. Gerade bei bestehenden Anwendungen ist es sinnvoll, Entscheidungen zu dokumentieren und Standards bewusst zu setzen: für Code-Struktur, Oberflächenverhalten, Schnittstellen, Fehlerbehandlung und Sicherheitsmechanismen.

Vor dem Livegang stehen in solchen Projekten nicht nur Funktionstests, sondern auch Prüfungen der Integrationen, der Berechtigungslogik und des Betriebsmodells. Nach dem Start geht es typischerweise weiter mit Stabilisierung, Anpassungen und schrittweiser Weiterentwicklung. Wer ein ähnliches Vorhaben strukturiert angehen möchte, kann den Umfang zunächst mit dem Kostenrechner grob einordnen und dann in einem unverbindlichen Erstgespräch besprechen.

Typische Stolpersteine bei Architektur, Sicherheit und Betrieb

Sie sehen Schild, Zahnräder, Server und Cloud als Symbol für Sicherheit und Betrieb.

Bei einer Modernisierung gewachsener Anwendungen entstehen die größten Risiken oft nicht durch einzelne Technologien, sondern an den Übergängen: zwischen alt und neu, zwischen Frontend und Backend, zwischen Fachlogik und Identitätssystemen sowie zwischen Entwicklung und Betrieb. Gerade deshalb lohnt es sich, typische Stolpersteine früh sichtbar zu machen.

Ein häufiger Fehler ist eine zu technische Sicht auf die Zerlegung. Wenn die Aufteilung einer Anwendung nicht an fachlichen Verantwortlichkeiten orientiert ist, entstehen schnell neue Abhängigkeiten statt klarer Grenzen. In Microfrontend-Projekten sollte deshalb früh festgelegt werden, welche Teile eigenständig sind, welche gemeinsamen Bausteine es gibt und welche Regeln für Navigation, Design und Fehlerverhalten gelten. Ohne diese Leitplanken wächst die Komplexität im neuen System oft rasch nach.

Ein weiterer kritischer Punkt ist das Backend. Wenn nur die Oberfläche modernisiert wird, aber Fachlogik und Datenzugriffe unverändert eng gekoppelt bleiben, wird die neue Architektur ausgebremst. Schnittstellen müssen so gestaltet sein, dass sie fachlich verständlich, stabil und für mehrere Frontend-Teile nutzbar sind. Das betrifft auch Datenbanken und Integrationen. Werden bestehende Datenstrukturen, Oracle-Anbindungen oder externe Systeme berührt, sollten Verantwortlichkeiten, Datenhoheit und Migrationspfade sauber geklärt sein.

Besondere Aufmerksamkeit verlangt die Sicherheit. OAuth2 und OIDC sind verbreitete Standards, müssen aber im jeweiligen Anwendungskontext passend umgesetzt werden. Mehrfaktor-Authentifizierung erhöht die Hürde für unberechtigte Zugriffe, verändert aber auch Prozesse für Anmeldung, Support und Betrieb. PKI und asymmetrische Verschlüsselung bringen zusätzlichen Schutz, verlangen jedoch klares Schlüsselmanagement und eindeutige Zuständigkeiten. Wo personenbezogene Daten, Nachweise oder Protokollierungen betroffen sind, sollten Datenschutzbeauftragte und bei rechtlichen Fragen juristische Ansprechpartner einbezogen werden.

Auch der Betrieb wird oft unterschätzt. Containerisierung mit Docker und automatisierte Pipelines erleichtern die Bereitstellung, ersetzen aber kein Betriebsmodell. In solchen Projekten müssen Zuständigkeiten für Monitoring, Fehleranalyse, Release-Freigaben und Notfallprozesse geklärt werden. Wer eine neue Anwendung oder Anwendungsarchitektur plant, sollte deshalb nicht nur an Entwicklung denken, sondern den späteren Hosting und Betrieb in der Microsoft Cloud beziehungsweise das eigene Betriebsmodell von Anfang an mitplanen.

Wenn Sie ein ähnliches Vorhaben vorbereiten, unterstützen wir bei ballmüller solutions gern dabei, Anforderungen und Risiken früh zu strukturieren.

Häufige Fragen

Wovon hängen die Kosten bei einer Migration von WPF zu Angular-Microfrontends ab?

Die Kosten hängen typischerweise davon ab, wie stark die bestehende Anwendung fachlich und technisch verflochten ist, wie viel Backend-Logik entkoppelt werden muss, welche Sicherheitsanforderungen bestehen und wie viele Schnittstellen berücksichtigt werden müssen. Auch Vorgaben für Betrieb, Testautomatisierung und Release-Prozesse wirken sich aus. Für eine erste Einordnung eignet sich der Kostenrechner; für eine fundiertere Sicht ist ein Projekt-Check auf Basis Ihrer Beschreibung oder Unterlagen sinnvoll.

Wie geht man bei einer solchen Modernisierung sinnvoll vor?

Bewährt hat sich ein schrittweises Vorgehen. Zunächst werden fachliche Bereiche, Abhängigkeiten und Zielbild geklärt. Danach folgen Architekturentscheidungen für Frontend, Backend, Identität und Auslieferung. Erst dann sollte die eigentliche Umsetzung starten. So lassen sich Risiken früher erkennen und Prioritäten besser setzen. Wichtig ist außerdem, Standards für Entwicklung, Versionierung und Bereitstellung festzulegen, damit die neue Lösung nicht nur entsteht, sondern auch langfristig beherrschbar bleibt.

Welche Risiken sind bei einem Projekt mit Microfrontends typisch?

Typisch sind unklare fachliche Zuschnitte, zu viele gemeinsame Abhängigkeiten und eine unzureichend entkoppelte Backend-Landschaft. Hinzu kommen Risiken bei Anmeldung, Berechtigungen und Integrationen mit bestehenden Systemen. Wenn Verantwortlichkeiten für Architektur, Freigaben und Betrieb nicht sauber geklärt sind, entstehen Reibungsverluste. Deshalb sollten Grenzziehungen, Schnittstellen und Sicherheitsmechanismen früh definiert und während des Projekts konsequent überprüft werden.

Welche Rolle spielen Sicherheit und Identitätsmanagement?

Sie sind ein tragender Teil der Architektur. Verfahren wie OAuth2 und OIDC regeln, wie Anwendungen Identitäten prüfen und Anmeldungen mit einem zentralen System verbinden. Mehrfaktor-Authentifizierung ergänzt diesen Prozess um zusätzliche Absicherung. Wenn Verschlüsselung und Zertifikate eingesetzt werden, braucht es außerdem klare Prozesse für Verwaltung und Zuständigkeiten. Welche Anforderungen im Einzelfall gelten, sollte technisch geplant und bei Datenschutz- oder Rechtsfragen mit den zuständigen Stellen geprüft werden.

Was muss der spätere Betrieb eines solchen Systems leisten?

Im Betrieb geht es nicht nur darum, dass die Anwendung bereitsteht. Er muss auch Releases nachvollziehbar ausrollen, Fehler erkennbar machen, Berechtigungen verlässlich unterstützen und Integrationen stabil überwachen. Automatisierte Build- und Deployment-Pipelines helfen dabei, wiederkehrende Abläufe einheitlich auszuführen. Ebenso wichtig sind klare Zuständigkeiten für Support, Monitoring und Weiterentwicklung. Wer das früh mitdenkt, reduziert spätere Reibung zwischen Entwicklung, Fachseite und Betrieb.