Wenn Cloud wie günstigeres Hosting klingt

11 Min. Lesezeit

Die Infrastruktur-Illusion

Das Gespräch startet fast immer gleich.

Ein Inhaber spricht mit einem Kunden, der fragt: „Haben Sie eine Cloud-Version?“ Jemand im Vertrieb verliert einen Auftrag, weil „die IT keine weitere On-Prem-Installation will“. Ein Berater wirft „Cloud Migration“ in den Raum, als wäre das eine Wochenendaufgabe. Jemand leitet eine Grafik zu SaaS (Software as a Service: Sie betreiben es für Kunden) Margen weiter. Ein Wettbewerber bringt eine SaaS-Version.

Dann kommt die eigentliche Frage, von der Person, die die Gehälter zahlen muss: „Hängen wir hinterher?“

Dasselbe Missverständnis landet regelmäßig im Graben, siehe Es ist doch nur eine einfache Neuentwicklung — Eine Geschichte von Schätzungen, Egos und schließlichem Erfolg.

Der erste Gedanke ist verführerisch. Sie haben funktionierende Software. Sie haben Kunden. Cloud-Anbieter bieten Infrastruktur. Also verschieben Sie die Anwendung von Kundensystemen auf Ihre Systeme in einem Rechenzentrum. Fertig. Oder?

Nein. Und der Fehler ist vorhersehbar.

Wenn Sie seit Jahren On-Premise-Software verkaufen, wirkt die Cloud wie ein Infrastrukturdetail. Ihre Software funktioniert. Ihre Kunden arbeiten damit. Die Verlagerung auf zentrale Infrastruktur fühlt sich wie eine technische Aufgabe an, nicht wie eine Transformation des Geschäfts.

Installation ist nicht Betrieb

On-Premise wird nicht „von Ihnen ausgerollt“ im modernen Sinn. Es wird vom Kunden installiert.

Jemand startet ein Installationsprogramm. Ein Administrator plant ein Wartungsfenster. Ein Key-User testet. Dann bleibt die Installation lange auf einer Version, weil Upgrades Risiko bedeuten.

Diese Upgrade-Schwerkraft ist keine Randnotiz. Sie definiert das Produkt.

On-Premise-Realität:

• Kunden entscheiden, wann sie eine neue Version installieren.
• Viele Kunden tun es erst, wenn etwas kaputtgeht oder ein großes Feature sie zwingt.
• Sie unterstützen mehrere Versionen parallel, weil Sie es müssen.
• Fehler können längst behoben sein und leben trotzdem weiter, weil Kunden Monate oder Jahre hinterherhinken.

SaaS-Realität:

• Sie entscheiden, wann eine neue Version live geht.
• Jede Auslieferung betrifft alle.
• Sie betreiben CI/CD (Continuous Integration und Continuous Delivery) und Continuous Deployment als normalen Betriebsmodus. Viele Teams liefern Änderungen mehrmals täglich aus.
• Abwärtskompatibilität und Datenmigration sind jedes Mal Ihr Problem.
• „Ausliefern und die Kunden upgraden lassen“ ist keine Strategie mehr.

Wenn das sitzt, klingt Cloud nicht mehr nach Schnäppchen, sondern nach einer zweiten Firma.

Was Sie wirklich vorhaben

Wenn Sie sagen „wir gehen in die Cloud“, dann sagen Sie in Wahrheit Folgendes, ob Sie es mögen oder nicht:

Sie wechseln vom Produktverkauf zum Betrieb eines Dienstes. On-Premise-Software wird einmal pro Kunde ausgeliefert. Sie liefern, der Kunde installiert, es läuft auf seiner Infrastruktur. Ihre Verantwortung endet weitgehend bei Installationssupport.

Cloud-Software läuft dauerhaft auf Ihrer Infrastruktur für alle Kunden. Sie sind verantwortlich für Verfügbarkeit, Performance, Sicherheit, Backups, Desaster-Fall, und Störungsbehebung. 24 Stunden am Tag. 7 Tage die Woche. Für immer.

Sie werden zum Datenverantwortlichen. Früher lagen Kundendaten auf Kundensystemen. Wenn Daten verloren gingen, war es deren Backup-Problem. Wenn es einen Sicherheitsvorfall gab, war es deren Thema.

Jetzt halten Sie alle Kundendaten. Sie sind verantwortlich für Schutz, Backups und Compliance.

In Europa heißt das DSGVO, plus das, was Ihre Kunden zusätzlich mitbringen (Betriebsrat, branchenspezifische Vorgaben, Erwartungen an Datenresidenz, Audit-Anforderungen). In den USA kann das HIPAA (Gesundheitswesen), PCI DSS (Zahlungen), GLBA (Finanzdienstleistungen) und ein wachsender Haufen an Datenschutzgesetzen der Bundesstaaten bedeuten.

Wenn Sie das falsch machen, bekommen Sie nicht nur eine unangenehme E-Mail. Sie bekommen Aufsichtsbehörden, Vertragsstrafen und Kunden, die Ihnen nie wieder vertrauen.

Sie akzeptieren eine permanente Betriebsbelastung. On-Premise konnte Fehler sammeln. Kunden meldeten sie. Sie beheben sie in der nächsten Version. Der Druck war oft niedrig, weil Kunden stabile Versionen nutzen und selbst entscheiden konnten, ob und wann sie ein Update installieren.

Cloud muss ständig überwacht werden. Performance-Probleme betreffen alle Kunden gleichzeitig. Sicherheitslücken müssen sofort geschlossen werden. Datenbankmigrationen müssen ohne Ausfallzeit funktionieren. Jede Änderung erzeugt Risiko für Ihre gesamte Kundenbasis.

Sie wechseln von unbefristeten Lizenzen zu Abonnements. Das ist nicht nur ein neues Preisschild. Es ist eine grundlegende Veränderung der Kundenbeziehung, der Liquidität und der Erlöslogik.

On-Premise kaufen Kunden eine Lizenz, zahlen oft Wartung und behandeln größere Versionssprünge wie einen neuen Kauf oder ein eigenes Projekt. Versionsrückstand ist normal.

In SaaS zahlen Kunden laufend. Sie erwarten laufende Verbesserung. Sie erwarten auch, dass Sie ihre Abläufe nicht an einem beliebigen Dienstagmorgen zerlegen. „Upgrade nach Bedarf“ fällt weg. Abwanderung ist eine Kennzahl, die Sie nicht mehr ignorieren können.

Das ist nicht offensichtlich, wenn Sie auf AWS-Preise starren und denken: „Wir können das günstiger betreiben als unsere Kunden ihre eigenen Server.”

Die Kompetenzlücke, für die niemand Budget einplant

Ihr Entwicklungsteam baut seit Jahren Features für ein On-Premise-Produkt. Es versteht die Domäne. Es kennt die Codebasis. Es liefert zwei Releases pro Jahr.

Der Betrieb eines Cloud-Dienstes erfordert andere Fähigkeiten:

Kontinuierliche Auslieferung. Zwei Releases pro Jahr reichen nicht mehr. Sie brauchen automatisierte Pipelines, gestaffelte Auslieferungen, Feature-Flags und Rollback-Verfahren. Auslieferungen müssen mehrmals täglich sicher möglich sein.

Beobachtbarkeit. Sie brauchen Logs, Metriken, Traces und Alarme über den gesamten Stack. Wenn etwas bricht, haben Sie Minuten für Diagnose und Abhilfe, nicht Tage. Sie müssen wissen, wie „normal“ aussieht.

Störungsbehebung. Um 03:00 Uhr am Sonntag, wenn die Datenbank timeouts produziert, muss jemand analysieren, stabilisieren und beheben. Sie brauchen Rufbereitschaft, Runbooks, Post-Incident-Reviews und die Disziplin, das wirklich zu leben.

Security-Betrieb. Schwachstellen sofort beheben. Secrets sicher verwalten. Credentials rotieren. Intrusion-Monitoring. Reaktion auf Sicherheitsvorfälle. Audits bestehen. Das ist nicht optional. Das ist der Preis dafür, Kundendaten zu halten.

Performance-Engineering. Wenn alle Kunden Infrastruktur teilen, trifft ein Peak eines Kunden alle. Sie brauchen Isolation, Kapazitätsplanung, Auto-Scaling und Performance-Monitoring. „Läuft auf meinem Laptop“ reicht nicht.

Datenbankbetrieb. Schema-Migrationen ohne Ausfallzeit. Backups wirklich testen. Replikation überwachen. Queries unter Last optimieren. Point-in-Time-Recovery. Das sind Spezialfähigkeiten, die Ihr Team vielleicht nicht hat.

Ihre drei Entwickler, die bisher zwei Releases pro Jahr geliefert haben? Sie können das alles nicht automatisch. Ihr Support kann es nicht. Sie wahrscheinlich auch nicht.

Vorhersehbare Auslieferung erfordert technische Praktiken, die Geschäftsergebnisse liefern, nicht nur gute Absichten.

Das Supportmodell verändert sich

On-Premise-Support ist reaktiv. Ein Kunde ruft an. Sie helfen bei der Fehlersuche. Ist es ein Fehler, beheben Sie ihn in der nächsten Version. Ist es Konfiguration, helfen Sie dem Kunden. Das Problem betrifft nur diesen Kunden.

Cloud-Support ist proaktiv und universell. Sie müssen Probleme erkennen, bevor Kunden sie melden. Wenn Sie eine fehlerhafte Version veröffentlichen, trifft es alle Kunden gleichzeitig.

Damit diese Release-Frequenz überhaupt überlebbar ist, brauchen Sie Orchestrierung: Rolling Upgrades ohne Ausfallzeit, gestaffelte Auslieferung nach Kundengruppen, Canary-Releases, Feature-Flags, A/B-Tests und die Fähigkeit, schnell zurückzurollen, wenn die Realität Ihren Plan widerlegt.

Wenn Performance sinkt, merkt es jeder.

Ihr Support, trainiert für einzelne Kundenfälle, muss in Plattformgesundheit denken. Dashboards mit systemweiten Metriken. Unterscheidung zwischen Kundenproblem und Plattformvorfall. Koordination mit der Entwicklung während Auslieferungen.

Das braucht neue Werkzeuge, neue Prozesse und neue Fähigkeiten. Supportfälle sind nicht mehr „Kunde A kann Rechnungen nicht drucken“, sondern „Datenbankperformance 40 Prozent schlechter in der letzten Stunde: welche Kunden sind betroffen?“

Die Kostenstruktur, die niemand erwähnt

Der Cloud-Verkaufstext verspricht günstigere Infrastruktur. Keine teuren Server mehr beim Kunden. Zentraler Betrieb bedeutet Skaleneffekte. Niedrigere Kosten, bessere Marge.

Seien wir präzise, was dieser Pitch ist und für wen er gedacht war.

„Cloud ist günstiger“ ist die Hyperscaler-Geschichte für Software-Anbieter, die ohnehin SaaS betreiben und die Betriebsbelastung bereits tragen. Diese Anbieter vergleichen ihr eigenes Rechenzentrum mit gemieteter Kapazität.

Wenn Sie aus On-Premise kommen, machen Sie diesen Vergleich nicht. Sie kaufen sich in ein neues Geschäftsfeld ein: Betrieb.

Die Realität ist teurer als fast jeder plant:

Infrastrukturkosten. Sie hosten nicht nur die Anwendung. Sie brauchen Produktion, Staging, Entwicklung, Desaster-Fall. Sie brauchen Monitoring, Logging, Backup-Storage und Redundanz. Die monatliche AWS-Rechnung wächst schneller als die Kundenzahl.

Operatives Personal. Sie brauchen DevOps, Datenbankadministration, Security-Spezialisten und SRE-Kapazität. Das ist nicht optional. Das ist Mindestbesetzung, um einen Cloud-Dienst sicher zu betreiben.

Security und Compliance. DSGVO-Pflichten. ISO 27001 Audits (oder Äquivalente, je nach Kunden). Penetration Tests. Vulnerability Scanning. Verschlüsselung. Zugriffskontrollen. Beratung. Das läppert sich.

Rufbereitschaft. Wenn Sie erwarten, dass Menschen um 03:00 Uhr reagieren, bezahlen Sie Verfügbarkeit. Rufbereitschaft ist kein Ehrenamt.

Höhere Entwicklungsgeschwindigkeit. Zwei Releases pro Jahr reichen nicht. Wettbewerber liefern täglich. Sie brauchen Continuous Integration, automatisierte Tests und schnellere Zyklen. Das erfordert bessere Werkzeuge und deutlich mehr Disziplin.

Infrastruktur kann pro Kunde günstiger sein. Die gesamten Betriebskosten sind deutlich höher.

Was Ihre Kunden wirklich bekommen

Sie verkaufen den Wechsel als „dieselbe Software, jetzt in der Cloud“. Kunden hören „Bequemlichkeit“ und „weniger IT-Aufwand“.

Was sie tatsächlich bekommen:

Weniger Kontrolle. Sie können Updates nicht frei planen. Sie können die Installation nicht nach Belieben anpassen. Sie können keine modifizierten Versionen laufen lassen. Sie hängen vollständig an Ihrer operativen Kompetenz.

Gemeinsames Schicksal. Wenn Ihr Dienst ausfällt, steht ihr Geschäft. Wenn Ihre Datenbank Probleme hat, sind Daten nicht verfügbar. Wenn Sie Fehler ausliefern, leiden sie.

Abo-Abhängigkeit. Sie können nicht aufhören zu zahlen, ohne den Zugriff auf Daten zu verlieren. Sie hängen an Ihrer Preisgestaltung. Preiserhöhungen sind ein Risiko.

Ihre Preisstrategie kann Sie trotzdem in diese Richtung drücken. Rechnen Sie mit Abwanderung bei Kunden, denen Kontrolle wichtiger war als Komfort.

Die Migration, die niemand eingeplant hat

Bestehende On-Premise-Installationen in Ihren Cloud-Dienst zu überführen klingt simpel. Kunden exportieren Daten, Sie importieren sie, fertig.

In der Praxis ist Migration ein Albtraum:

Datenkonsistenz. Jeder Kunde hat Jahre an Daten, oft mit leicht unterschiedlichen Schemas, weil über die Zeit unterschiedliche Versionen installiert wurden. Sie brauchen Migrationsskripte für jede Version, jeden Sonderfall, jede Anpassung.

Downtime-Fenster. Kunden mit 24/7 Betrieb tolerieren keine Ausfallzeit. Sie brauchen Online-Migrationsstrategien, in denen beide Systeme während des Übergangs parallel laufen.

Tests. Wie verifizieren Sie, dass die migrierten Daten korrekt sind? Automatisierte Tests fangen nur einen Teil. Manuelle Prüfung über hunderte Kunden ist unrealistisch.

Rollback. Wenn die Migration in der Mitte scheitert, und das wird passieren, wie rollen Sie sicher zurück, ohne Daten zu verlieren?

Support-Last. Jeder migrierende Kunde braucht Betreuung. Ihr Support ist ohnehin ausgelastet und soll jetzt zusätzlich Migration begleiten.

Eine erfolgreiche Führung von Legacy-Modernisierung erfordert, Migration als eigenständiges Projekt zu behandeln, nicht als Wochenendaufgabe.

Unbefristete Lizenzen bringen große Einmalzahlungen. Ein Kunde zahlt 50.000 € einmal. Der Umsatz wird sofort erkannt. Liquidität ist planbar. Wartung bringt eine stabile Basis.

Abo-Umsatz ist das Gegenteil. Ein Kunde zahlt 500 € pro Monat. Sie bekommen das Geld nicht im Voraus. Abwanderung wartet immer. Sie brauchen mehr Kunden, um denselben Lizenzumsatz zu ersetzen.

Viele Anbieter unterschätzen die Übergangszeit. Zwei bis fünf Jahre unterstützen Sie beide Modelle: On-Premise-Kunden auf Wartung und neue Cloud-Abos. Einnahmen sinken. Kosten steigen. Dann ist es keine Theorie mehr, sondern Liquidität.

Sie haben weiter Gehälter. Sie haben weiter Supportverpflichtungen. Sie haben weiter Kunden auf alten Versionen, die am Freitagnachmittag mit einem Produktionsproblem anrufen und erwarten, dass Sie sich kümmern.

Wenn sich das wie Scheitern anfühlt, dann weil es für eine Weile genauso aussieht. Das ist die J-Kurve einer Geschäftsmodell-Transformation. Sie verlangt Reserven und Disziplin, die viele Inhaber unterschätzen, weil das Tagesgeschäft schon alles auffrisst.

Was es wirklich braucht

On-Premise in Richtung Cloud zu drehen ist machbar. Es ist nur nicht billig, und es ist kein Nebenprojekt. Erfolg setzt voraus, dass Sie sich nicht selbst belügen, worauf Sie sich einlassen:

Investition in Betrieb. Budgetieren Sie DevOps, Datenbankadministration, Security-Spezialisten und SRE-Kapazität bevor Sie live gehen. Einen Cloud-Dienst mit einem reinen Feature-Team zu betreiben ist eine Einladung zum Desaster.

Kompetenzaufbau. Schicken Sie Ihre Entwickler in Trainings zu Cloud-Architektur, Beobachtbarkeit, Incident Response und Sicherheit. Das ist keine Kür. Das ist Überleben.

Kulturwandel. Ihre Engineering-Kultur muss sich von „zwei Releases pro Jahr“ zu „Dauerbetrieb“ ändern. Das braucht neue Anreize, neue Prozesse und Führung.

Zwei Gleise. Planen Sie, On-Premise und Cloud jahrelang parallel zu betreiben, nicht Monate. Budgetieren Sie die doppelte Last.

Finanzielle Geduld. Abo-Umsatz braucht Jahre, bis er Lizenzumsatz überholt. Sorgen Sie für Runway.

Kundennähe. Nicht alle Kunden wollen Cloud. Bieten Sie hybride Optionen. Nehmen Sie Sorgen zu Kontrolle und Datensouveränität ernst.

Migrationsexpertise. Holen Sie Spezialisten für Datenmigration. Bauen Sie umfassende Tests. Planen Sie für Fehlschläge. Tun Sie nicht so, als wäre Migration ein Detail.

Der Weg nach vorn

Cloud ist nicht einfach günstigeres Hosting. Es ist eine grundlegende Veränderung vom Produktanbieter zum Servicebetreiber.

Wenn Sie diesen Schritt gehen, müssen Sie Folgendes verstehen:

Es ist schwerer als es aussieht. Infrastruktur ist der leichte Teil. Betriebsdisziplin, Kulturwandel und Geschäftsmodell sind die Faktoren, die über Erfolg oder Scheitern entscheiden.

Ihr aktuelles Team ist nicht vorbereitet. Es ist gut im Feature-Bau. Betrieb braucht andere Fähigkeiten. Investieren Sie in Training oder Einstellung, bevor Sie live gehen.

Der finanzielle Übergang tut weh. Planen Sie Jahre von Doppelbetrieb und gedrückten Einnahmen, bevor Abos die Lizenzumsätze überholen.

Nicht alle Kunden gehen mit. Manche bevorzugen Kontrolle. Manche dürfen rechtlich keine Cloud nutzen. Planen Sie Abwanderung.

Cloud-native Wettbewerber haben Vorteile. Sie haben Betriebsdisziplin von Tag eins. Sie bauen sie nachträglich in Produkt und Kultur ein. Das ist härter.

Unternehmen, die gewinnen, hören auf, Cloud als reines Infrastrukturthema zu verkaufen. Sie investieren in Betrieb. Sie trainieren Teams. Sie kommunizieren ehrlich mit Kunden. Sie schlucken kurzfristigen Schmerz, um langfristig zu überleben.

Unternehmen, die scheitern, behandeln es als technische Migration. Sie sparen beim Betrieb. Sie unterschätzen den Kulturwandel. Sie glauben, bestehende Fähigkeiten reichen. Dann wundern sie sich, wenn der Dienst wackelt, Kunden abwandern und Kosten explodieren.

Cloud ist keine Magie. Es ist ein anderes Geschäftsmodell mit anderen Anforderungen, anderer Ökonomie und anderem Risiko. Respektieren Sie das, oder Sie landen auf dem Friedhof traditioneller Software-Anbieter, die glaubten, Hosting sei der schwere Teil.