Website oder Webanwendung? Wann eine normale Website nicht mehr ausreicht

Der Übergang von der Website zur Webanwendung geschieht in den meisten Unternehmen nicht als Projekt, sondern als schleichende Überlastung: Die bestehende Firmen-Website funktioniert weiterhin, aber sie erledigt plötzlich Aufgaben, für die sie nie gebaut wurde. Ein Kontaktformular wird zum Auftragseingang. Eine Excel-Tabelle wird zum Kundenstamm. Ein passwortgeschütztes Verzeichnis wird zum Kundenportal. Jede dieser Zwischenlösungen ist einzeln vertretbar – zusammen ergeben sie ein System, das niemand mehr überblickt.

Dieser Artikel zeigt, woran Sie den Kipppunkt erkennen, welche Zwischenstufen es zwischen Website und Eigenentwicklung gibt und welche Infrastruktur die jeweilige Stufe voraussetzt.

Der technische Unterschied: Inhalte ausliefern oder Zustand verwalten

Die Website liefert aus

Eine klassische Website ist im Kern ein Auslieferungssystem. Der Server beantwortet Anfragen mit weitgehend identischen Inhalten für alle Besucher. Ob die Seiten statisch generiert oder von einem CMS wie WordPress dynamisch zusammengesetzt werden, ändert daran wenig: Der Zustand liegt in der Datenbank des Redaktionssystems, nicht beim einzelnen Benutzer. Caching funktioniert deshalb exzellent, und die Last skaliert nahezu linear mit den Seitenaufrufen.

Die Webanwendung verwaltet Zustand

Eine Webanwendung kehrt dieses Verhältnis um. Sie hält für jeden authentifizierten Benutzer einen individuellen Zustand – offene Aufträge, hochgeladene Dokumente, Genehmigungsstufen, Berechtigungen. Jede Anfrage erzeugt Datenbankarbeit, die sich nicht wegcachen lässt, weil die Antwort für jeden Benutzer eine andere ist. Aus «Seiten ausliefern» wird «Transaktionen verarbeiten», und das ist eine grundlegend andere Belastungscharakteristik.

Die letzte Zeile ist die entscheidende: Fällt eine Website für zwei Stunden aus, ist das unangenehm. Fällt ein Kundenportal für zwei Stunden aus, arbeitet Ihr Support-Team nicht mehr, und Ihre Kunden merken es sofort.

Fünf Signale, dass eine Website nicht mehr ausreicht

1. Es braucht einen echten Login-Bereich

   Ein Passwortschutz auf Verzeichnisebene reicht, solange alle Berechtigten dasselbe sehen dürfen. Sobald Benutzer A andere Inhalte sehen soll als Benutzer B, brauchen Sie Benutzerverwaltung, Session-Handling, Passwort-Reset-Prozesse und – bei sensiblen Daten – Zwei-Faktor-Authentifizierung. Das ist Anwendungslogik, nicht Konfiguration.
    

2. Kunden fragen nach Daten, die Sie manuell heraussuchen

   Wenn Ihr Team regelmässig Rechnungskopien, Lieferstatus, Vertragsdokumente oder Verbrauchsdaten auf Anfrage per Mail verschickt, ist die Aufgabe bereits definiert: ein Kundenportal. Der Nutzen ist hier ausnahmsweise gut messbar – zählen Sie die Anfragen pro Monat und multiplizieren Sie sie mit der durchschnittlichen Bearbeitungszeit.
    

3. Prozesse laufen über Formular, Mail und Tabelle

   Ein typisches Muster: Ein Webformular erzeugt eine E-Mail, jemand überträgt den Inhalt in eine Tabelle, ein Zweiter prüft, ein Dritter gibt frei. Jeder Schritt ist ein Medienbruch mit Fehlerpotenzial und ohne Nachvollziehbarkeit. Genau diese Kette ersetzt eine Webanwendung durch einen Datensatz mit Statusfeld und Verlauf.
    

4. Rollen und Berechtigungen werden relevant

   Sobald die Frage «Wer darf was sehen und ändern?» differenziert beantwortet werden muss, ist die Grenze überschritten. Rollenmodelle sind mit CMS-Plugins abbildbar, aber jede zusätzliche Ausnahmeregel erhöht die Wahrscheinlichkeit einer Fehlkonfiguration – und Fehlkonfigurationen in Berechtigungssystemen sind der häufigste Weg, auf dem Daten ungewollt sichtbar werden.
    

5. Die Anwendung soll mit Drittsystemen sprechen

   ERP, Warenwirtschaft, Buchhaltung, CRM, Zahlungsdienstleister: Sobald Ihre Weblösung Daten bidirektional mit anderen Systemen austauschen soll, brauchen Sie API-Anbindungen, Fehlerbehandlung, Wiederholungslogik und Protokollierung. Das ist der Punkt, an dem die Grenze technisch eindeutig überschritten ist.

Faustregel: Ein Signal lässt sich meist noch mit Erweiterungen im bestehenden System abfedern. Ab drei Signalen arbeiten Sie gegen die Architektur, und jede weitere Anpassung wird teurer als der saubere Neubau.

Zwischenstufen: Nicht jede Anforderung braucht eine Eigenentwicklung

Der Sprung von der Website zur individuell entwickelten Applikation ist der teuerste Weg – und selten der nötige. Vier Stufen liegen dazwischen:

Die ehrliche Prüffrage lautet: Ist der Prozess, den Sie abbilden wollen, Teil Ihres Wettbewerbsvorteils? Wenn ja, lohnt sich die Eigenentwicklung. Wenn nein, ist eine Standardlösung fast immer die wirtschaftlichere Wahl.

Was eine Webanwendung technisch vom Hosting verlangt

Dieser Abschnitt ist der Grund, warum die Entscheidung nicht rein fachlich getroffen werden kann. Eine Webanwendung stellt Anforderungen, die ein auf Websites optimiertes Hosting-Paket bewusst nicht erfüllt.

Eigene Laufzeitumgebung und Hintergrundprozesse

Reports generieren, Mails versenden, Datenabgleiche mit Drittsystemen: Solche Aufgaben laufen zeitversetzt und nicht innerhalb eines Seitenaufrufs. Dafür braucht es Worker-Prozesse, Queues und Cronjobs mit garantierter Ausführung – also Kontrolle über die Laufzeitumgebung. Sobald Ihre Anwendung auf einem Framework mit eigenem Applikationsserver aufsetzt oder in einer Runtime läuft, die ein geteiltes Hosting nicht bereitstellt, ist ein VPS oder Managed Cloud Server die technische Voraussetzung, nicht das Upgrade.

Datenbanklast statt Seitenauslieferung

Die Datenbank wird zum eigentlichen Engpass. Verbindungslimits, Query-Optimierung, Indizes und ausreichend Arbeitsspeicher für den Datenbank-Cache bestimmen die Antwortzeit stärker als die reine CPU-Leistung. Planen Sie Ressourcen deshalb nach Datenbankverhalten, nicht nach Besucherzahlen.

Staging, Deployment und Rollback

Bei einer Website korrigieren Sie einen Fehler im Backend. Bei einer Webanwendung veröffentlichen Sie ein Release, das gleichzeitig ein Datenbankschema migriert – und eine fehlgeschlagene Migration ist ein Datenproblem, kein Darstellungsproblem. Eine Staging-Umgebung, die der Produktion strukturell entspricht, und ein geprüfter Rückweg sind keine Komfortfunktionen, sondern Grundausstattung.

Backups, die den Zustand wiederherstellen

Ein Tagesbackup genügt für eine Website, deren Inhalte sich langsam ändern. Für eine Anwendung, in die Kunden laufend Daten eingeben, bedeutet ein Tagesbackup im Ernstfall bis zu 24 Stunden verlorene Arbeit. Definieren Sie deshalb explizit, wie viel Datenverlust tolerierbar ist, und wählen Sie das Backup-Konzept danach.

Skalierung in zwei Richtungen

Websites skalieren mit Traffic, Anwendungen mit gleichzeitigen Sessions und Transaktionen. Diese Last ist oft stark schwankend – Monatsabschlüsse, Kampagnen, Saisonspitzen. Eine Umgebung, deren Ressourcen sich anpassen lassen, ohne die Anwendung neu aufzusetzen, spart hier langfristig sowohl Kosten als auch Betriebsrisiko.

Die passende Infrastruktur bei METANET

Drei Punkte, die im Projekt regelmässig zu spät bedacht werden:

Erstens die Domain-Struktur. Betreiben Sie die Anwendung auf einer eigenen Subdomain – etwa app.ihrefirma.ch oder portal.ihrefirma.ch – getrennt von der Marketing-Website. Das trennt Deployments, Zertifikate, Caching-Regeln und Sicherheitsrichtlinien sauber voneinander. Bei der Domain-Registrierung unterstützt METANET .ch, .swiss und zahlreiche weitere TLDs; Domain Protection schützt Ihre Hauptdomain zusätzlich gegen unbeabsichtigte Änderungen oder Transfers.

Zweitens die Verschlüsselung. Ein Login-Bereich ohne durchgehendes TLS ist keine Option. Planen Sie SSL-Zertifikate für alle Hostnamen der Anwendung von Beginn an ein, inklusive Staging.

Drittens die E-Mail-Trennung. Systemmails der Anwendung – Passwort-Reset, Benachrichtigungen, Statusmeldungen – gehören nicht in dieselbe Zustellstrecke wie Ihre geschäftliche Korrespondenz. Business Mail mit Schweizer Infrastruktur deckt die geschäftliche Kommunikation ab, ergänzt durch MX-Filter als Spamschutz; für Systemmails empfiehlt sich ein separater Versandweg, damit ein Reputationsproblem der Anwendung nicht Ihre Firmen-Mails blockiert.

Entscheidungsleitfaden in vier Schritten

Schritt 1: Prozesse zählen, nicht Wünsche. Notieren Sie über zwei Wochen jede Aufgabe, die manuell zwischen Website, Mail und Tabelle vermittelt wird. Die Häufigkeit ist Ihre Wirtschaftlichkeitsrechnung.

Schritt 2: Datenkategorien bestimmen. Welche personenbezogenen oder besonders schützenswerten Daten wird die Anwendung verarbeiten? Diese Antwort legt Standort, Verschlüsselung und Backup-Konzept fest.

Schritt 3: Die Standardlösung ernsthaft prüfen. Eine Eigenentwicklung ist nur dann richtig, wenn der Prozess Teil Ihres Wettbewerbsvorteils ist. Andernfalls kaufen Sie die Lösung ein.

Schritt 4: Infrastruktur nach Betriebsmodell wählen. Entscheidend ist nicht die Grösse der Anwendung, sondern die Frage, wer sie betreibt. Ohne eigenes Systemteam ist ein Managed Cloud Server die tragfähigere Wahl als ein unmanaged VPS mit ungeklärter Zuständigkeit für Updates.