Wenn man eine Windows-App besser nicht ins Web migriert: Entscheidungstabelle und die pragmatische Lösung der Aufteilung

„Wir möchten unsere intern genutzte Windows-Anwendung nun endlich ins Web migrieren” – diese Anfrage erreicht uns Jahr für Jahr häufiger. Oft steckt dahinter ein nachvollziehbares Motiv, doch wenn man genauer nachfragt, zeigt sich nicht selten, dass eine Anwendung vollständig ins Web migriert werden soll, die dadurch gerade unpraktischer und teurer würde.

Vorab sei gesagt: Dieser Artikel ist kein Plädoyer gegen Web-Migrationen generell. Es gibt viele Situationen – Nutzung von mehreren Standorten aus, Reduzierung des Endgeräte-Managements –, in denen eine Web-Migration eindeutig die richtige Wahl ist. Das eigentliche Problem ist, dass Anwendungen, deren Charakter sich für eine Web-Migration gar nicht eignet, pauschal unter die Formel „Modernisierung = Web-Migration” gefasst werden. Dieser Artikel stellt dar, wie wir in der Praxis der Windows-Auftragsentwicklung tatsächlich beurteilen, in welchen Fällen man besser auf eine Web-Migration verzichtet, und zeigt mit der Aufteilung eine pragmatische Alternative zur reinen Entweder-oder-Entscheidung zwischen „vollständig Web” und „vollständig Windows”.

1. Zunächst das Fazit (Entscheidungstabelle)

Entscheidend ist, nicht die Anwendung als Ganzes zu betrachten, sondern jede einzelne Funktion bzw. Eigenschaft der Anwendung gesondert zu beurteilen.

Und hier gleich das Fazit vorab:

• Hinter dem Wunsch „ins Web migrieren” verbergen sich meist drei unterschiedliche Probleme: der Aufwand für die Verteilung, Einschränkungen beim Einsatzort und die technologische Veralterung. Jedes davon hat eine andere Lösung, und nur bei einem Teil davon ist die Web-Migration tatsächlich die einzige Lösung (Kapitel 2).
• Bei Anwendungen mit Gerätekopplung, lokaler Dateiverarbeitung oder Offline-Betrieb ist es sicherer, zumindest diesen Teil nicht ins Web zu migrieren. Browser schränken den Zugriff auf lokale Ressourcen aus Sicherheitsgründen bewusst ein – das ist kein Mangel des Webs, sondern dessen Designphilosophie¹. Zwar gibt es Workarounds, doch diese bringen eigene Kosten mit sich: eingeschränkte Browser-Unterstützung und einen komplizierteren Betrieb (Kapitel 3–5).
• Eine Web-Migration ist kein „Portieren”, sondern ein „Neubau”. Bestehende Oberflächen-Assets lassen sich nicht einfach übernehmen, und nach Fertigstellung entsteht mit dem Serverbetrieb eine neue, dauerhafte Kostenposition. Wird die Kalkulation nicht auf dieser Grundlage aufgesetzt, gerät der Plan unterwegs ins Wanken (Kapitel 7).
• Die pragmatische Lösung ist die Aufteilung: Anzeige, Auswertung und Berichte gehen ins Web, Gerätekopplung und Eingaben vor Ort bleiben unter Windows – verbunden über eine gemeinsame API und Datenbank. So lässt sich kleiner starten als bei einer vollständigen Web-Migration, und man kann schrittweise mit den Bereichen beginnen, in denen der Nutzen am größten ist (Kapitel 8).

2. Was sich hinter dem Wunsch „ins Web migrieren” wirklich verbirgt

Wenn wir eine Anfrage zur Web-Migration erhalten, zerlegen wir als Erstes den eigentlichen Wunsch. Hinter der Aussage „wir wollen ins Web” steckt meist eines der folgenden drei Anliegen – oder mehrere davon.

(1) Der Aufwand für Verteilung und Updates soll entfallen. Das Problem lautet meist: „Bei jedem Update müssen wir alle Endgeräte einzeln aufsuchen und die neue Version installieren.” Eine Web-Migration löst dieses Problem zwar tatsächlich, aber sie ist dafür nicht nötig. Wechselt man zu einer Verteilungsmethode mit eingebautem Auto-Update wie ClickOnce oder MSIX, lässt sich der Verteilungsaufwand auch als Windows-App nahezu auf null senken. Details dazu finden sich in „Die richtige Verteilungsmethode für Windows-Apps auswählen”. Wenn der Verteilungsaufwand das einzige Motiv ist, ist eine Web-Migration eine Überinvestition.

(2) Die Anwendung soll von überall und auf jedem Gerät nutzbar sein. Nutzung von mehreren Standorten aus, Zugriff unterwegs beim Kunden oder von zu Hause, Ansicht auf dem Tablet – genau hier spielt eine Web-Migration ihre Stärken aus. Doch auch hier lohnt es sich zu unterscheiden, ob wirklich „alle Funktionen von überall” benötigt werden oder nur die Daten von überall eingesehen werden sollen. In der Praxis ist meist Letzteres der Fall, und dann genügt eine Aufteilung (Kapitel 8), bei der nur die Anzeige- und Auswertungsfunktionen ins Web wandern.

(3) Man möchte sich von veralteter Technik lösen. Das Motiv lautet hier oft: „Die Person, die die App gebaut hat, ist nicht mehr im Unternehmen” oder „Wir sind unruhig, weil wir noch auf .NET Framework laufen.” Das ist ein berechtigtes Anliegen, doch die Lösung muss nicht zwingend eine Web-Migration sein. Wenn ohnehin ein Neubau ansteht und die Art der Aufgabe für den Desktop geeignet ist, kann man die Anwendung auch mit dem aktuellen .NET als Windows-App neu aufbauen (Entscheidungstabelle für WinForms / WPF / WinUI). Außerdem sollte man festhalten, dass eine Web-Migration nicht automatisch vor Veralterung schützt. Das bekannte Beispiel eines internen Web-Systems, das ausschließlich für den IE gebaut wurde und mit dessen Ende quasi handlungsunfähig wurde, zeigt das deutlich („Verlängerung eines IE-Modus-abhängigen internen Web-Systems und Ausstiegsstrategie”). Auch Web-Anwendungen brauchen laufende Pflege, um mit Änderungen an Frameworks und Browsern Schritt zu halten – „ins Web migrieren” bedeutet nicht „befreit von Wartung”.

Zerlegt man den Wunsch auf diese Weise, wird sichtbar, was sich nur durch eine Web-Migration lösen lässt, was auch anders gelöst werden kann und was selbst eine Web-Migration nicht löst. Auf dieser Grundlage prüft man anschließend, ob die Anwendung Funktionen enthält, die zu den im Folgenden beschriebenen „Fällen, in denen man besser nicht ins Web migriert” passen.

3. Fall 1: Direkte Kopplung mit Geräten oder Peripherie

Kommunikation mit Fertigungsanlagen, Datenerfassung von Mess- und Prüfgeräten, seriell (RS-232C) angeschlossene Waagen und Barcode-Scanner, feingranulare Steuerung von Spezialdruckern – Anwendungen mit Funktionen, die direkt mit Hardware kommunizieren, eignen sich in diesem Teil strukturell nicht für eine Web-Migration.

Der Grund ist einfach: Code im Browser läuft in einer isolierten Umgebung, der sogenannten Sandbox. Es wäre fatal, wenn allein das Öffnen einer Webseite beliebigen Zugriff auf Dateien oder Geräte des Endgeräts erlauben würde – deshalb blockieren Browser den Zugriff auf lokale Ressourcen bewusst. Das ist kein Mangel des Webs, sondern das Sicherheitsdesign selbst. Selbst bei Blazor WebAssembly, mit dem sich Web-Clients in C# schreiben lassen, läuft der Code innerhalb der Sicherheits-Sandbox des Browsers, und der Zugriff auf das Dateisystem oder das Öffnen beliebiger Netzwerkverbindungen löst eine PlatformNotSupportedException aus¹. Möglich ist nur, was der Browser selbst an Funktionen bereitstellt².

Man könnte einwenden, dass die Web Serial API oder WebUSB serielle Kommunikation aus dem Browser heraus ermöglichen. Das stimmt zwar, doch die Browser-Unterstützung ist begrenzt. Die Web Serial API wird von Chromium-basierten Browsern wie Chrome und Edge unterstützt, und seit Firefox 151 (veröffentlicht im Mai 2026) auch von der Desktop-Version von Firefox – Safari unterstützt sie jedoch nicht (und auf Mobilgeräten bietet lediglich Chrome für Android eine teilweise Unterstützung für serielle Verbindungen über Bluetooth), während WebUSB weiterhin auf Chromium-Browser beschränkt ist³. Damit wird der größte Vorteil einer Web-Migration – die Nutzbarkeit „von jedem Browser aus” – bereits eingeschränkt, und beim Verbinden eines Geräts muss der Nutzer (zumindest beim ersten Mal oder bei jedem neuen Gerät) über einen Browser-Dialog das Gerät auswählen und die Berechtigung erteilen. In der Praxis lohnt sich das als Mechanismus zur Gerätekopplung in Geschäftsanwendungen daher meist nicht.

Eine weitere Möglichkeit ist, das Problem mit einer Architektur aus „Web-App plus einem auf jedem Endgerät laufenden Kopplungs-Agenten” zu umgehen. Dabei bleibt jedoch letztlich ein Windows-Programm bestehen, das verteilt und aktualisiert werden muss. Das ist an sich nichts Schlechtes – tatsächlich ist es eine Variante der Aufteilung aus Kapitel 8 –, doch man sollte bereits in der Planungsphase klarstellen, dass dies etwas anderes ist als die ursprüngliche Erwartung, durch die Web-Migration müsse auf den Endgeräten gar nichts mehr installiert werden.

Zum Entwurf der Gerätekopplung siehe auch „Best Practices zur Statusprüfung und -anzeige externer Geräte”.

4. Fall 2: Enge Kopplung mit lokalen Dateien oder anderen Anwendungen

Der zweithäufigste Fall ist, dass die Zusammenarbeit mit Dateien auf dem Endgerät oder mit anderen Anwendungen im Kern des Arbeitsablaufs steht.

• Überwachung eines freigegebenen oder lokalen Ordners, um dort abgelegte Dateien automatisch zu verarbeiten
• Stapelweise Konvertierung, Umbenennung oder Sortierung von Hunderten oder Tausenden von Dateien
• Starten von Excel, um Berichte über COM zusammenzustellen, oder Zusammenarbeit mit bestehenden Excel-Makros
• Datenaustausch mit anderen Geschäftsanwendungen über Dateien oder Interprozesskommunikation

Grundsätzlich ist der Dateizugriff im Browser auf „die Datei, die der Nutzer gerade in einem Dialog ausgewählt hat” beschränkt. Ein Massenzugriff ohne Nutzerinteraktion oder eine dauerhaft laufende Überwachung, die auch bei geschlossenem Browser weiterarbeitet, ist nicht möglich. Die neuere File System Access API erlaubt zwar den Zugriff auf einen vom Nutzer ausgewählten Ordner, und mit FileSystemObserver gibt es sogar eine experimentelle API, die Änderungen in einem gewählten Ordner überwacht, solange die Seite geöffnet ist – doch beide sind auf Chromium-Browser beschränkt⁴ und haben damit dasselbe Problem der eingeschränkten Browser-Unterstützung wie bei der Gerätekopplung. Einen anderen lokalen Prozess (etwa Excel) aus dem Browser heraus zu starten und zu steuern, ist ohnehin nicht möglich.

Will man diese Art von Funktion ins Web migrieren, muss der Arbeitsablauf so geändert werden, dass Nutzer Dateien auf den Server hochladen und die Verarbeitung dort stattfindet. Wenn der Arbeitsablauf das zulässt, ist das eine Option. Liegen jedoch Umstände vor wie das routinemäßige Verarbeiten gigabytegroßer Dateien, die lokale Verarbeitung von Daten, die das Unternehmen nicht verlassen dürfen, oder eine enge Kopplung an Excel-Assets, ist es für Entwickler wie Nutzer gleichermaßen sinnvoller, diesen Teil als Windows-App zu belassen (bei unbeaufsichtigten Vorgängen wie Ordnerüberwachung oder Stapelverarbeitung als Windows-Dienst). Besondere Vorsicht ist jedoch bei der COM-Kopplung mit Excel geboten: Microsoft rät von der Automatisierung von Office aus unbeaufsichtigten, nicht interaktiven Umgebungen wie Diensten ab und unterstützt dies nicht⁵. Code, der Excel automatisch steuert, sollte daher auf der Desktop-App-Seite laufen, wo ein angemeldeter Nutzer aktiv ist, oder durch Lese-/Schreibzugriffe über eine Open-XML-Bibliothek ersetzt werden, die Office gar nicht erst startet. Wie man die Excel-Kopplung umsetzt, behandeln wir in „Excel-Berichtsausgabe erstellen”, die Ordnerüberwachung in „Die sicheren Grundlagen von FileSystemWatcher”.

5. Fall 3: Einsatz für Abläufe, die nicht unterbrochen werden dürfen, bei instabilem Netzwerk

Web-Anwendungen setzen aufgrund ihrer Architektur grundsätzlich eine aktive Netzwerkverbindung voraus. Das gilt selbstverständlich für serverseitig gerenderte Web-Anwendungen, aber auch für das im C#-Umfeld beliebte Blazor Server: Da dort jede UI-Interaktion über eine dauerhafte Verbindung zum Server verarbeitet wird, stoppt die Anwendung, sobald die Verbindung abreißt. Die offizielle Dokumentation stellt ausdrücklich klar, dass es keine Offline-Unterstützung gibt².

Zum Problem wird das in Umgebungen wie diesen:

• Fabriken, Lagerhallen, Außeneinsätze: WLAN-Signale werden durch Metallregale oder Maschinen abgeschirmt, kurze Verbindungsabbrüche gehören zum Alltag
• Produktionslinien, die nicht anhalten dürfen: Schon wenige Minuten Ausfall eines Erfassungs- oder Anweisungsbildschirms beeinträchtigen Produktion oder Versand
• Standorte mit schwacher oder instabiler Anbindung: provisorische Büros, die auf Mobilfunk angewiesen sind, an Bord von Schiffen, in Bergregionen und Ähnliches

Eine native Windows-App lässt sich unkompliziert so bauen, dass sie Daten lokal vorhält, offline weiterläuft und nach Wiederherstellung der Verbindung synchronisiert. Offline-Betrieb wird von Microsoft selbst als Grund genannt, sich für eine native App zu entscheiden⁶. Technisch ist es zwar auch möglich, eine Web-Anwendung mittels PWA (Service Worker) oder einem Design mit clientseitiger Datenhaltung offlinefähig zu machen, doch die dafür nötige Entwicklung – inklusive Synchronisation und Konfliktlösung – erfordert eine erhebliche zusätzliche Investition, was der ursprünglichen Erwartung „Web-Migration macht es günstiger” entgegenläuft.

Die entscheidende Frage lautet: „Kann dieser Arbeitsablauf warten, wenn das Netzwerk 30 Minuten lang ausfällt?” Wenn nicht, sollte zumindest der dafür zuständige Bildschirm lokal lauffähig sein.

6. Fall 4: Schnelle, umfangreiche Tastatureingabe steht im Mittelpunkt der Arbeit

Belegerfassung, Wareneingangs- und Versandregistrierung, Bildschirme für Callcenter-Gespräche – all das sind Tätigkeiten, bei denen den ganzen Tag über an diesem Bildschirm gesessen und überwiegend per Tastatur eine große Menge an Daten eingegeben wird. In diesem Bereich sind Desktop-UIs sehr ausgereift, weshalb sich eine Web-Migration hier besonders deutlich in einer schlechteren gefühlten Qualität niederschlägt.

• Antwortverzögerung: Bei serververbundenen Modellen wie Blazor Server ist bei jeder Nutzeraktion ein Netzwerk-Roundtrip nötig, was die UI-Latenz erhöht². Selbst wenige Dutzend Millisekunden pro Aktion machen sich bei mehreren Tausend Eingaben am Tag spürbar als „Hakeln” bemerkbar.
• Nachbau des Tastaturverhaltens: Selbstverständlichkeiten der Dateneingabe – Feldwechsel per Enter, Belegung von Funktionstasten, sofortige Validierung während der Eingabe – müssen gegen das Standardverhalten des Browsers erkämpft werden (Enter sendet ein Formular ab, F1 öffnet die Hilfe usw.). Es ist nicht unmöglich, bedeutet aber, mit zusätzlichem Aufwand die Qualität nachzuholen, die ein Desktop-Framework samt Grid-Steuerelement von Haus aus mitbringt.
• Grids mit großen Datenmengen: Um im Web ein Grid auf Desktop-Niveau umzusetzen – das Zehntausende Zeilen flüssig per virtuellem Scrolling anzeigt und Zellbearbeitung, fixierte Spalten sowie Kopieren und Einfügen unterstützt – braucht es eine leistungsfähige kommerzielle Komponente und entsprechend viel Feinabstimmung.

Für reine Anzeige, Freigaben oder gelegentliche Eingaben genügt ein Web-Formular völlig. Bei Bildschirmen, bei denen die Eingabegeschwindigkeit direkt die Produktivität bestimmt, sollte man jedoch nüchtern prüfen, ob der Nutzen der Web-Migration – Nutzbarkeit von überall – überhaupt zum Tragen kommt oder ob dieser Bildschirm am Ende ohnehin nur vom festen Arbeitsplatz im Büro aus genutzt wird. Ist der Einsatzort fest, gewinnt man durch die Web-Migration nichts, sondern verliert nur.

7. Fall 5: Ein „Neubau” wird nach der Kalkulation eines „Portierens” begonnen

Bisher ging es um Funktionen und Nutzungsformen, zum Schluss geht es um die Kostenstruktur. Das typische Muster, nach dem ein Web-Migrationsprojekt unterwegs scheitert, ist: Man kalkuliert im Sinne eines Portierens – „das Bestehende einfach ins Web übertragen” – und stellt später fest, dass es in Wirklichkeit ein Neubau war.

• Oberflächen-Assets lassen sich nicht übernehmen. Es gibt keine praxistaugliche Methode, um WinForms- oder WPF-Bildschirmdefinitionen und -logik automatisch ins Web zu übertragen – die UI muss für jeden Bildschirm neu entworfen und gebaut werden. Die Anzahl der Bildschirme multipliziert mit ihrer Komplexität ergibt direkt den Aufwand.
• Die Geschäftslogik muss zunächst vollständig erfasst werden. Bei lange betriebenen Anwendungen kommt es nicht selten vor, dass Geschäftsregeln nirgendwo in der Spezifikation stehen, sondern ausschließlich im Code existieren. Eine Web-Migration umfasst die Arbeit, all dies aufzuspüren und neu zu implementieren. Hier gilt genau das Prinzip „nicht sofort komplett neu schreiben” aus „VB6-/Access-Geschäftsanwendungen migrieren”.
• Die Betriebskosten steigen nach Fertigstellung strukturell. Beim Betrieb einer Desktop-App ging es darum, sich um die Endgeräte zu kümmern. Bei einer Web-App entsteht dagegen mit Aufbau, Überwachung, Backup sowie Zertifikats- und Sicherheitsupdates eines Servers (oder einer Cloud-Umgebung) eine dauerhafte Aufgabe. Fehlt intern die entsprechende Struktur, fallen monatlich Kosten für einen externen Dienstleister an. Der Kostenvergleich einer Web-Migration muss neben den anfänglichen Entwicklungskosten auch diese laufenden Kosten einbeziehen.
• Die sicherheitstechnischen Voraussetzungen ändern sich. Sobald eine Anwendung, die bisher nur im internen LAN lief, ins Web migriert und für externen Zugriff geöffnet wird, steigen die Anforderungen an Authentifizierung, Autorisierung, Verschlüsselung der Kommunikation und Abwehr von Angriffen um eine ganze Stufe. Auch das gehört zu den „Kosten der Web-Migration”.

Auch das ist, wie gesagt, kein Argument gegen die Web-Migration, sondern Material für eine Kalkulation auf der richtigen Grundlage. Überwiegen die Vorteile der Web-Migration auch nach Einbeziehung von Neubau- und laufenden Kosten, sollte man sie umsetzen. Überwiegen sie nicht, sollte man zunächst prüfen, ob eine Modernisierung als Windows-App – Umstieg auf das aktuelle .NET, Verbesserung der Verteilungsmethode, Überarbeitung der UI – mit einer kleineren Investition den Großteil des ursprünglichen Anliegens erfüllen kann.

8. Die pragmatische Lösung: Keine Entweder-oder-Entscheidung zwischen vollständig Web und vollständig Windows

Überträgt man die bisherigen Überlegungen in die Praxis, lautet die Antwort in den meisten Fällen weder „vollständige Web-Migration” noch „alles beim Alten belassen”, sondern Aufteilung.

Der Gedanke dahinter ist einfach: Man wendet die Entscheidungstabelle aus Kapitel 1 nicht auf die gesamte Anwendung an, sondern auf jede einzelne Funktion.

• Was ins Web wandert: Anzeige, Suche und Auswertung von Daten, die von mehreren Standorten oder Personen eingesehen werden sollen, das Herunterladen von Berichten sowie leichte Vorgänge wie Freigaben. Meist gehört auch die Pflege von Stammdaten hierher.
• Was unter Windows bleibt: die Kopplung mit Geräten und Peripherie, die Überwachung und Stapelverarbeitung lokaler Dateien, Arbeiten vor Ort, die auch offline nicht stoppen dürfen, sowie Bildschirme für schnelle Dateneingabe.
• Was gemeinsam genutzt wird: die Datenbank und die Geschäftslogik. Die Daten werden zentralisiert, sodass sowohl die Web-App als auch die Windows-App dieselbe API (oder Datenbank) verwenden. Ist dies einmal gemeinsam genutzt, entsteht eine Architektur, die den Großteil des ursprünglichen Web-Migrations-Motivs erfüllt: Vor Ort wird über die Windows-App eingegeben, während die Zentrale über den Browser sofort einsehen kann, was passiert.

Diese Architektur bietet praktische Vorteile, die eine vollständige Web-Migration nicht hat: Der auf einmal zu erneuernde Bereich bleibt klein, man kann schrittweise vorgehen, beginnend mit den Bereichen mit dem größten Nutzen (Anzeige), und die Benutzerfreundlichkeit vor Ort leidet nicht. Umgekehrt braucht es eine Struktur, die zwei Systeme – Windows-App und Web-App – parallel pflegt. Ist die betreffende Anwendung klein und im Wesentlichen auf Anzeige ausgerichtet, kann eine vollständige Web-Migration durchaus die bessere Wahl sein. Auch hier handelt es sich nicht um ein Entweder-oder, sondern um eine Frage des Ausmaßes.

Für die Anforderung „die Oberfläche soll mit Webtechnologie gebaut werden, gleichzeitig soll aber auch auf lokale Ressourcen zugegriffen werden können” gibt es außerdem hybride Optionen wie Electron oder Blazor Hybrid (WebView2). Damit lässt sich eine mit Webtechnologie gebaute UI nutzen, ohne den Einschränkungen der Browser-Sandbox zu unterliegen – man sollte jedoch beachten, dass es sich dabei um eine Desktop-App handelt, die verteilt werden muss, und dass dies keine Antwort auf den Wunsch ist, die Anwendung „nur über den Browser” nutzen zu können.

9. Checkliste vor der Entscheidung für eine Web-Migration

Bevor man ein Angebot einholt oder eine interne Freigabe beantragt, lohnt es sich, Folgendes zu prüfen, um spätere Nacharbeit zu vermeiden.

1. Das Motiv zerlegen: Ist das eigentliche Problem der Verteilungsaufwand, der Einsatzort oder die technologische Veralterung? Wenn nur die Verteilung das Problem ist, würde dann nicht ein Wechsel der Verteilungsmethode ausreichen?
2. Hardwarekopplung vorhanden?: Gibt es Funktionen, die direkt mit seriellen/USB-Geräten, Messgeräten oder Spezialdruckern kommunizieren? Falls ja, sollte vorab festgelegt werden, wie mit diesem Teil umgegangen wird (unter Windows belassen / Agenten-Architektur).
3. Abhängigkeit von lokalen Ressourcen: Gibt es Ordnerüberwachung, Stapelverarbeitung von Dateien oder Prozesskopplung mit Excel und Ähnlichem? Lässt sich der Arbeitsablauf auf ein serverseitiges Verarbeitungsmodell umstellen?
4. Offline-Anforderungen: Kann der Arbeitsablauf warten, wenn das Netzwerk 30 Minuten lang ausfällt?
5. Gewicht der Eingabearbeit: Gibt es Bildschirme, an denen den ganzen Tag über per Tastatur eingegeben wird? Wird dieser Bildschirm wirklich „von überall” genutzt?
6. Tatsächliche Nutzer und Einsatzorte: Wer möchte was von wo aus sehen oder eingeben? Geht es darum, dass „alle alle Funktionen von außerhalb” nutzen sollen, oder will „nur die Zentrale die Daten einsehen”?
7. Betriebsstruktur: Wer übernimmt Aufbau, Überwachung und Sicherheitsupdates des Servers? Wie hoch sind die monatlichen Kosten dafür?
8. Wo die Geschäftslogik liegt: Stimmt die Spezifikation mit dem Code überein? Wurde die für die Bestandsaufnahme benötigte Zeit in die Kalkulation einbezogen?

Treffen die Punkte 2 bis 5 zu, empfehlen wir, statt einer vollständigen Web-Migration vor allem eine Aufteilung in Betracht zu ziehen. Zur allgemeinen Vorbereitung vor einer Beauftragung siehe auch „Was man vor der Beauftragung einer Windows-App-Entwicklung klären sollte”.

Zusammenfassung

Eine Web-Migration ist ein Werkzeug, kein Selbstzweck. Sie wirkt sich zwar klar positiv auf die Nutzung von mehreren Standorten aus und auf die Reduzierung des Endgeräte-Managements aus, doch Gerätekopplung und lokale Dateiverarbeitung stoßen auf Einschränkungen, die aus dem Sicherheitsdesign der Browser stammen und sich kaum durch die Wahl des Frameworks oder zusätzliche Entwicklungsarbeit umgehen lassen. Offline-Betrieb und schnelle Dateneingabe lassen sich zwar technisch umsetzen, doch die Kosten für Entwicklung und Betrieb laufen dem ursprünglichen Ziel „durch die Web-Migration wird alles einfacher” oft entgegen. Und eine Web-Migration ist kein Portieren, sondern ein Neubau – nach Fertigstellung kommt mit dem Serverbetrieb eine neue, dauerhafte Kostenposition hinzu.

Genau deshalb ist die praktische Entscheidung keine Frage von „Web-Migration ja oder nein”, sondern eine Design-Frage: Welche Funktionen kommen ins Web, welche bleiben unter Windows, und was wird gemeinsam genutzt? Von der Bestandsaufnahme der bestehenden Anwendung über die Beurteilung der Web-Migration bis zum Entwurf der Aufteilung ist meist eine Einschätzung nötig, die sich am tatsächlichen Code und Betrieb orientiert. Sprechen Sie uns gerne an, wenn Sie unsicher sind.

Verwandte Artikel

• Was man vor der Beauftragung einer Windows-App-Entwicklung klären sollte
• Verlängerung und Migration von VB6-/Access-Geschäftsanwendungen ── Entscheidungstabelle für Beibehalten, Kapseln oder Ersetzen
• Entscheidungstabelle für WinForms / WPF / WinUI
• Die richtige Verteilungsmethode für Windows-Apps auswählen (MSI / MSIX / ClickOnce / xcopy / eigener Updater)
• Verlängerung eines IE-Modus-abhängigen internen Web-Systems und Ausstiegsstrategie
• Best Practices zur Statusprüfung und -anzeige externer Geräte
• Die sicheren Grundlagen von FileSystemWatcher
• Excel-Berichtsausgabe erstellen

Verwandte Beratungsbereiche

KomuraSoft LLC bietet technische Beratung zur Beurteilung, ob eine bestehende Windows-Anwendung ins Web migriert werden sollte, zum Entwurf einer aufgeteilten Web-plus-Windows-Architektur sowie zur Entwicklung und Weiterentwicklung von Geschäftsanwendungen mit Gerätekopplung und lokaler Datenverarbeitung.

• Windows-App-Entwicklung
• Wartung und Weiterentwicklung bestehender Windows-Software
• Technische Beratung / Design-Review
• Kontakt

Quellen

Verwandte Artikel

Aktuelle Artikel mit denselben Schlagwörtern führen zu verwandten Themen weiter.

Verwandte Themen

Diese Seiten ordnen den Artikel in einen größeren Leistungs- und Entscheidungskontext ein.

Leistungen zu diesem Thema

Dieser Artikel ist direkt mit den folgenden Leistungen verbunden.

Häufige Fragen

Fragen, die in Beratungen zu diesem Artikelthema häufig gestellt werden.

Sollte man beim Aktualisieren einer alten Windows-App gleich auch eine Web-Migration durchführen?

Wir raten davon ab, allein deshalb ins Web zu migrieren, weil die Anwendung „alt“ ist. Eine Web-Migration erfordert einen Aufwand, der eher einem Neubau als einer Portierung entspricht, und auch Web-Anwendungen unterliegen der technologischen Veralterung (das bekannte Beispiel eines internen Web-Systems, das ausschließlich für den IE gebaut wurde, ist dafür typisch). Entscheidend sollte nicht das Alter der Technik sein, sondern die Art, wie die Anwendung genutzt wird. Wird sie von mehreren Standorten aus verwendet oder soll das Endgeräte-Management reduziert werden, zeigt sich der Nutzen einer Web-Migration deutlich. Steht dagegen die Gerätekopplung oder lokale Dateiverarbeitung im Mittelpunkt, ist eine Modernisierung als Windows-App – etwa der Umstieg auf eine neuere .NET-Version oder eine Überarbeitung der UI – häufig das wirtschaftlichere Vorgehen.

Entfällt durch die Web-Migration nicht ohnehin der Aufwand für Verteilung und Installation?

Die client-seitige Verteilungsarbeit entfällt zwar, doch wenn „den Verteilungsaufwand loswerden“ das einzige Motiv ist, gibt es leichtere Lösungen als eine Web-Migration. Wechselt man zu einer Verteilungsmethode mit eingebautem Auto-Update wie ClickOnce oder MSIX, lässt sich die Installation auf jedem einzelnen Endgerät auch als Windows-App nahezu überflüssig machen. Migriert man dagegen ins Web, entsteht im Gegenzug eine neue, dauerhafte Betriebsaufgabe: Aufbau, Überwachung und Sicherheitsupdates eines Servers (oder einer Cloud-Umgebung). Berücksichtigen Sie bei Ihrer Entscheidung sowohl die wegfallenden als auch die neu hinzukommenden Kosten.

Kann man auch nur einen Teil der Anwendung ins Web migrieren?

Ja, und in der Praxis ist genau das oft die realistische Lösung. Typisch ist eine Architektur, bei der Datenanzeige, Auswertung, Berichte und der Zugriff von mehreren Standorten ins Web wandern, während Gerätekopplung, schnelle Eingabe vor Ort und lokale Dateiverarbeitung als Windows-App bestehen bleiben – verbunden über eine gemeinsame API und Datenbank. Im Vergleich zu einer vollständigen Web-Migration ist der auf einmal zu erneuernde Bereich kleiner, und man kann schrittweise mit den Bereichen beginnen, in denen der Nutzen der Web-Migration am größten ist.

Wie sieht es mit Zwischenlösungen wie Electron, PWA oder Blazor Hybrid aus?

Hier sind unterschiedliche Dinge vermischt, die man getrennt betrachten sollte. Electron und Blazor Hybrid (WebView2) laufen als Desktop-Anwendungen und können daher, ohne den Einschränkungen der Browser-Sandbox zu unterliegen, auf Dateien und Geräte zugreifen, während die Oberfläche mit Webtechnologie geschrieben wird. Dennoch bleiben es Desktop-Anwendungen, die verteilt und aktualisiert werden müssen – sie beantworten also nicht den Wunsch, die Anwendung „nur über den Browser“ nutzen zu können. Eine PWA wiederum kann sich zwar wie installiert anfühlen, etwa durch das Anheften an die Taskleiste, ist im Kern jedoch weiterhin eine im Browser laufende Web-Anwendung mit denselben Einschränkungen beim Zugriff auf lokale Ressourcen wie jede andere Web-Anwendung. Wichtig ist daher, vorab zu klären, welches Problem man mit der Web-Migration eigentlich lösen möchte.

Autorenprofil

Profilseite des Artikelautors.

Go Komura

Geschäftsführer von KomuraSoft LLC

Spezialisiert auf Windows-Softwareentwicklung, technische Beratung und Fehleranalyse, insbesondere bei bestehenden Systemen und schwer reproduzierbaren Störungen.