Eigener Server oder Cloud: Was der Wechsel auf Shopify an Ihrer Infrastruktur wirklich ändert
Die Frage klingt nach Technik und ist eine Zuständigkeitsfrage. Wir legen sieben Betriebsschichten nebeneinander, zeigen an einer Jahreslastkurve, warum feste Kapazität im Handel strukturell falsch dimensioniert ist, und trennen die vier Kostenposten auf Ihrer Rechnung von den sieben, die nirgends gebucht werden — damit der Vergleich zwischen Eigenbetrieb und gehosteter Plattform ehrlich wird.
Die Frage kommt fast immer im dritten Gespräch, und sie kommt als Technikfrage: “Wir überlegen, ob wir auf Cloud-Hosting gehen oder beim dedizierten Server bleiben. Was würden Sie empfehlen?”
Die ehrliche Antwort lautet: Das ist die zweitwichtigste Frage. Die wichtigste steht darunter und wird selten ausgesprochen — nämlich, wie viele Schichten Ihrer Infrastruktur Sie überhaupt noch selbst besetzen wollen. Wer von Magento, Shopware oder einem eigenentwickelten System auf eine gehostete Plattform wechselt, entscheidet nicht zwischen zwei Servertypen. Er entscheidet, ob die Serverfrage in zwei Jahren überhaupt noch auf seinem Tisch liegt.
Dieser Text ordnet beides. Zuerst die Sachfrage — was Cloud und dedizierter Server tatsächlich unterscheidet, ohne Marketingvokabular. Dann die Frage dahinter: was ein Plattformwechsel an dieser Rechnung verändert, und was er ausdrücklich nicht löst.
Die beiden Modelle, kurz und ohne Beschönigung
Ein dedizierter Server ist eine physische Maschine, die ausschließlich Ihnen zugeordnet ist. Prozessor, Arbeitsspeicher und Datenträger teilen Sie mit niemandem. Das bringt vorhersagbare Leistung und maximale Kontrolle über die Konfiguration — Sie bestimmen Kernel, PHP-Version, Datenbankeinstellungen, alles. Es bedeutet aber auch: Was Sie an Kapazität haben, haben Sie. Mehr gibt es erst nach einer Bestellung, einem Umzug oder einem Wartungsfenster.
Ein Cloud-Server ist eine virtuelle Instanz auf einem abstrahierten Hardware-Pool. Ressourcen lassen sich innerhalb von Minuten nach oben und unten anpassen, redundante Architekturen über mehrere Zonen sind ohne eigenes Rechenzentrum möglich, und abgerechnet wird häufig nach Nutzung statt nach Vorhaltung. Der Preis dafür ist ein geteiltes Verantwortungsmodell: Der Anbieter sichert die Infrastruktur, alles darüber — Betriebssystemhärtung, Zugriffsrechte, Anwendungssicherheit — bleibt Ihre Aufgabe. Wer das Kleingedruckte nicht liest, hält Dinge für abgedeckt, die es nicht sind.
Beide Modelle haben eine gemeinsame Eigenschaft, die im Vergleich untergeht: Sie setzen voraus, dass jemand in Ihrem Haus Server betreibt. Genau diese Voraussetzung stellt der Wechsel auf eine gehostete Handelsplattform zur Disposition.
Zuständigkeiten
Sieben Schichten — und die Frage, wer nachts dafür haftet
Server-Vergleiche diskutieren Leistung und Preis. Der Unterschied, der im Betrieb tatsächlich zählt, ist ein anderer: Welche dieser Schichten müssen Sie besetzen, überwachen und im Fehlerfall selbst reparieren? Je weiter unten eine Zeile liegt, desto seltener taucht sie in einer Wirtschaftlichkeitsrechnung auf — und desto verlässlicher kostet sie Zeit.
| Schicht | Dedizierter Server | Cloud-Server | Shopify |
|---|---|---|---|
| Rechenzentrum & Hardware Strom, Kühlung, Netzanbindung, defekte Platten. Beim dedizierten Server hängt das an einem Vertrag mit Reaktionszeiten — und an jemandem, der ihn im Ernstfall liest. | Sie Liegt bei Ihnen | Anbieter Liegt beim Anbieter | Anbieter Liegt beim Anbieter |
| Betriebssystem & Patches Kernel-Updates, PHP-Versionssprünge, auslaufende Distributionen. Die Arbeit ist planbar, aber sie hört nie auf und sie fällt immer dann an, wenn gerade Saison ist. | Sie Liegt bei Ihnen | Geteilt Geteilte Verantwortung | Anbieter Liegt beim Anbieter |
| Webserver, Datenbank, Cache Nginx, MySQL, Redis, Elasticsearch. In gewachsenen Setups die Schicht mit den meisten historischen Sonderkonfigurationen — und der geringsten Dokumentation. | Sie Liegt bei Ihnen | Geteilt Geteilte Verantwortung | Anbieter Liegt beim Anbieter |
| Skalierung bei Lastspitzen Wer im November mehr Last erwartet, muss beim eigenen Server im September bestellen. In der Cloud ist es eine Konfiguration, bei Shopify gar keine Entscheidung. | Sie Liegt bei Ihnen | Geteilt Geteilte Verantwortung | Anbieter Liegt beim Anbieter |
| Sicherheit & PCI-Nachweis Firewall, Zertifikate, Zugriffsrechte, jährlicher Nachweis für die Kartenzahlung. Beim dedizierten Server tragen Sie den Nachweis für den gesamten Zahlungspfad selbst. | Sie Liegt bei Ihnen | Geteilt Geteilte Verantwortung | Anbieter Liegt beim Anbieter |
| Shop-Anwendung & Updates Versionssprünge der Shop-Software, Kompatibilität der Erweiterungen, Regressionstests. Der Posten, der in Eigenbetriebs-Budgets am zuverlässigsten unterschätzt wird. | Sie Liegt bei Ihnen | Sie Liegt bei Ihnen | Anbieter Liegt beim Anbieter |
| Theme, Inhalte, Apps, Daten Ihr Sortiment, Ihre Gestaltung, Ihre Integrationen, Ihre Kundendaten. Diese Schicht wandert bei keinem Betriebsmodell weg — und sie ist die, die Ihr Geschäft ausmacht. | Sie Liegt bei Ihnen | Sie Liegt bei Ihnen | Sie Liegt bei Ihnen |
Die unterste Zeile ist der ehrliche Teil: Sortiment, Gestaltung, Integrationen und Kundendaten bleiben in jedem Modell Ihre Arbeit. Ein Plattformwechsel nimmt Ihnen die sechs Zeilen darüber ab — nicht die, an der Ihr Umsatz hängt.
Der Blick auf diese Matrix erklärt, warum Angebotsvergleiche zwischen Betriebsmodellen so oft schiefgehen. Verglichen wird die oberste Zeile — Hardware gegen Instanz, Preis gegen Preis. Entschieden wird faktisch über sechs weitere Zeilen, die in keinem Angebot stehen, weil sie keine Rechnungsposten sind, sondern Stellenanteile.
Warum feste Kapazität im Handel strukturell falsch liegt
Die Kernfrage bei der Dimensionierung lautet: Wie viel Last muss die Maschine tragen? Im Handel ist die Antwort unangenehm, weil die Nachfrage nicht gleichmäßig ist, sondern eine ausgeprägte Form hat.
Ein durchschnittlicher deutscher Onlineshop bewegt sich elf Monate im Jahr in einem engen Band. Dann kommt eine Aktionswoche im November, gefolgt von einem erhöhten Plateau bis Weihnachten. Der Unterschied zwischen dem ruhigsten Julitag und dem stärksten Aktionstag liegt regelmäßig beim Fünf- bis Zehnfachen — bei einzelnen Sortimenten deutlich darüber.
Lastverlauf
Sie bezahlen ein Jahr lang für einen einzigen November
Feste Kapazität und schwankende Nachfrage passen selten zusammen. Die Kapazitätslinie muss auf die Spitze ausgelegt sein, sonst fällt der Shop am umsatzstärksten Tag aus — und ist damit den Rest des Jahres deutlich zu groß. Beide Flächen unten sind Geld: die eine bezahlt und ungenutzt, die andere gebraucht und nicht verfügbar.
- Elf Monate unter der Linie Die bestellte Kapazität wird den größten Teil des Jahres nicht gebraucht. Bezahlt wird sie trotzdem — sie ist ja gemietet, nicht abgerufen.
- Eine Woche darüber Der Aktionszeitraum im November überschreitet die Linie deutlich. Was oberhalb liegt, wird nicht bedient: langsame Seiten, abgebrochene Checkouts, Fehlerseiten.
- Die Bestellung liegt Wochen davor Zusätzliche Hardware braucht Vorlauf. Sie entscheiden im September über eine Last, die Sie erst im November kennen — auf Basis des Vorjahres.
Auf einer gehosteten Plattform verschwindet diese Kurve nicht — sie hört nur auf, Ihre Entscheidung zu sein. Die Kapazität für den Aktionstag wird nicht bestellt, sondern vorausgesetzt.
Aus dieser Form folgt ein Dilemma, das sich mit fester Kapazität nicht auflösen lässt. Dimensionieren Sie auf den Durchschnitt, fällt der Shop an dem Tag aus, an dem er den Jahresumsatz mitentscheidet. Dimensionieren Sie auf die Spitze, bezahlen Sie elf Monate für Kapazität, die niemand abruft. Beide Varianten sind teuer, nur an unterschiedlichen Stellen — und die zweite ist die, die man wenigstens im Voraus beziffern kann.
Dazu kommt der Vorlauf. Zusätzliche Hardware ist nicht am Freitagnachmittag verfügbar. Sie entscheiden im September über eine Last, die Sie erst im November sehen, auf Basis der Vorjahreszahlen und eines Bauchgefühls über die eigene Marketingplanung. Wenn die Kampagne besser läuft als geplant, ist das im Eigenbetrieb kein Grund zur Freude, sondern ein Anruf beim Dienstleister.
Cloud-Infrastruktur löst den Vorlauf, nicht aber die Zuständigkeit: Sie können in Minuten skalieren, müssen die Regeln dafür aber selbst definieren, testen und überwachen. Automatische Skalierung ist keine Einstellung, die man anhakt — sie ist ein Stück Betriebslogik, das falsch konfiguriert entweder zu spät greift oder eine unerwartete Rechnung produziert.
Was der Wechsel auf Shopify an dieser Rechnung ändert
Auf einer gehosteten Plattform ist die Kapazitätsfrage keine Entscheidung mehr, sondern eine Zusicherung. Sie bestellen keine Server, Sie definieren keine Skalierungsregeln, und Sie führen im September kein Gespräch über den November. Die Infrastruktur ist auf die Spitzenlast tausender Händler ausgelegt und trägt Ihre Aktionswoche als Randerscheinung.
Das lässt sich messen. Shopify hat rund 200.000 Websites ausgewertet und dabei für Shopify-Shops eine durchschnittliche Time to First Byte von 0,51 Sekunden gemessen, gegenüber 1,4 Sekunden bei Shops auf anderen Plattformen — nach dieser Auswertung rendern Shopify-Shops im Mittel etwa 1,8-mal schneller, und 93 Prozent der untersuchten Shopify-Shops wurden als schnell eingestuft. Die Zahl stammt vom Anbieter selbst und ist entsprechend einzuordnen; die Größenordnung deckt sich aber mit dem, was wir bei Migrationen sehen, bei denen vorher niemand ein Performance-Budget gepflegt hat.
Wichtiger als die Kennzahl ist der Mechanismus dahinter. Bei einem selbst betriebenen Shop ist gute Antwortzeit das Ergebnis fortlaufender Arbeit: Caching-Strategie, Datenbankindizes, Bildoptimierung, CDN-Konfiguration, regelmäßiges Nachschärfen nach jedem größeren Release. Auf einer gehosteten Plattform ist ein erheblicher Teil davon Grundzustand. Was bleibt, ist die Schicht, die Sie ohnehin verantworten — und die haben wir in Mobile-First-Performance bei Shopify im Detail auseinandergenommen: Theme-Code, Apps, Drittanbieter-Skripte. Ein überladenes Theme ist auch auf schneller Infrastruktur langsam.
Die Kosten, die in keiner Kalkulation stehen
Der zweite Grund, warum Betriebsmodelle so schwer zu vergleichen sind: Die Rechnung des einen Modells ist vollständig, die des anderen nicht.
Kostenwahrheit
Vier Posten stehen auf der Rechnung. Sieben nicht.
Eigenbetrieb wirkt günstig, weil die linke Spalte vollständig sichtbar ist und die rechte nirgends gebucht wird. Sie fällt trotzdem an — als Arbeitszeit, als Bereitschaft, als Projektbudget im übernächsten Jahr. Wer Betriebsmodelle vergleicht, muss beide Spalten nebeneinanderlegen, sonst vergleicht er eine Rechnung mit einem Gesamtaufwand.
Auf der Rechnung
Sichtbar, monatlich, gut vergleichbar
- Servermiete oder Abschreibung Monatlich, planbar, in jedem Angebot enthalten.
- Plattform- oder Lizenzkosten Bei Open-Source-Systemen null — was die Rechnung schön und die Realität teuer macht.
- Backup-Speicher Meist als Zusatzposten gebucht, selten mit Wiederherstellungstest.
- CDN und Zertifikate Getrennte Verträge, getrennte Rechnungen, getrennte Kündigungsfristen.
Nicht auf der Rechnung
Arbeitszeit, Bereitschaft, entgangener Umsatz
- Wartungsfenster und Patches Sicherheits-Updates kommen nicht nach Kalender. Die Stunden fallen an, egal wer gerade Urlaub hat.
- Bereitschaft außerhalb der Geschäftszeit Ein Ausfall am Samstagabend braucht jemanden, der Zugriff hat und das System kennt. Das ist eine Personalfrage, keine Serverfrage.
- Versionssprünge der Shop-Software Alle ein bis zwei Jahre ein Projekt für sich: Kompatibilität der Erweiterungen, Testdurchlauf, Nacharbeit.
- PCI-Nachweis für den Zahlungspfad Wer Kartendaten über eigene Infrastruktur leitet, führt den Nachweis selbst — jährlich, mit Dokumentation.
- Vorhalten für Lastspitzen Kapazität für den Aktionstag steht das ganze Jahr bereit. Bezahlt wird die Spitze, genutzt der Durchschnitt.
- Nicht bedienter Umsatz bei Überlast Der Posten, der nie in einer Rechnung steht und trotzdem die größte Zahl ist — sichtbar nur im Vorher-Nachher der Conversion.
- Wissensbindung an einzelne Personen In gewachsenen Setups kennt eine Person die Sonderkonfiguration. Deren Kündigung ist ein Infrastrukturrisiko.
Auf einer gehosteten Plattform wandert die rechte Spalte in den Plan-Preis. Das ist nicht automatisch billiger — aber es ist erstmals eine Zahl, die man in ein Budget schreiben kann.
Der Posten, der in Gesprächen am längsten unterschätzt wird, ist der letzte in der rechten Spalte. In gewachsenen Setups kennt genau eine Person die Sonderkonfiguration — warum der Cronjob um 3:40 Uhr läuft, warum ein bestimmter Cache manuell geleert werden muss, warum das Deployment einen zusätzlichen Schritt hat. Solange diese Person da ist, ist alles in Ordnung. Ihre Kündigung ist dann kein Personalthema, sondern ein Infrastrukturrisiko. Wie man solche Abhängigkeiten vor einem Wechsel systematisch erfasst, haben wir im Risikomanagement bei der Shopify-Migration beschrieben.
Fairerweise gehört die Gegenrechnung dazu: Eine gehostete Plattform kostet einen Plan-Preis, und bei Shopify kommen je nach Zahlungsabwicklung Transaktionskosten hinzu. Das ist bei hohem Volumen eine relevante Zahl, und sie steigt mit dem Umsatz, während ein Server das nicht tut. Der ehrliche Vergleich lautet deshalb nicht “Plan gegen Servermiete”, sondern “Plan plus Transaktionskosten gegen Servermiete plus die gesamte rechte Spalte”. Welche Anteile davon tatsächlich anfallen, hängt am Zahlungsmix; die Systematik dazu steht in Zahlungs-APIs beim Shopify-Umstieg.
Sechs Fragen, die die Entscheidung tatsächlich treffen
Wenn Sie die Wahl auf drei Modelle eingrenzen wollen, sind es diese sechs Punkte — in dieser Reihenfolge.
Erstens: Wie stark schwankt Ihre Last über das Jahr? Nicht gefühlt, sondern gemessen. Ziehen Sie die Sitzungen der letzten zwölf Monate und teilen Sie den stärksten Tag durch den Median. Liegt der Faktor unter drei, ist feste Kapazität vertretbar. Liegt er über fünf, zahlen Sie mit jedem Modell außer einem elastischen dauerhaft für Luft.
Zweitens: Wie viel Kontrolle brauchen Sie wirklich? Es gibt legitime Gründe für eigene Infrastruktur — regulatorische Auflagen, sehr spezielle Datenverarbeitung, Software, die nicht anders läuft. Es gibt auch den unausgesprochenen Grund, dass die Konfiguration historisch gewachsen ist und niemand sie anfassen will. Der erste Fall ist eine Anforderung, der zweite eine Altlast. Sie sehen im Gespräch schnell, welcher vorliegt.
Drittens: Wer besetzt die Betriebsschichten heute — und wer in drei Jahren? Eine halbe Stelle Systemadministration ist in vielen Häusern die stillschweigende Voraussetzung des gesamten Modells. Fragen Sie, was passiert, wenn diese halbe Stelle nicht mehr da ist.
Viertens: Was kostet eine Stunde Ausfall? Rechnen Sie es einmal aus: Jahresumsatz geteilt durch Öffnungsstunden, dann mit dem Faktor Ihres schwächsten und Ihres stärksten Tages. Die Spanne zwischen beiden Zahlen ist der Rahmen, in dem sich Investitionen in Verfügbarkeit rechnen — oder eben nicht.
Fünftens: Wie lange dauert bei Ihnen ein Sicherheits-Patch? Von der Veröffentlichung bis zum Produktivsystem. Wenn die Antwort “das machen wir im nächsten Wartungsfenster” lautet, ist das eine Aussage über das Betriebsmodell, nicht über das Team.
Sechstens: Wann haben Sie zuletzt eine Wiederherstellung getestet? Nicht das Backup — die Wiederherstellung. Der Unterschied ist der ganze Punkt. Ein ungetestetes Backup ist eine Hoffnung mit Speicherkosten.
Wo Sie ansetzen, je nach Ausgangslage
| Ihre Situation | Der erste Handgriff |
|---|---|
| Dedizierter Server, Vertrag läuft bald aus | Nicht verlängern, bevor die rechte Spalte der Kostenaufstellung beziffert ist |
| Lastfaktor über fünf zwischen Median und Spitzentag | Elastische Kapazität priorisieren — feste Dimensionierung ist hier immer die falsche Zahl |
| Eine Person kennt die Konfiguration | Sonderkonfigurationen dokumentieren, bevor irgendein Wechsel geplant wird |
| Sicherheits-Patches laufen im Wartungsfenster | Zeit von Veröffentlichung bis Produktiv messen und als Risikokennzahl führen |
| Kartendaten laufen über eigene Infrastruktur | Prüfen, welcher PCI-Nachweis aktuell geführt wird und wer ihn verantwortet |
| Ausfälle traten zuletzt an Aktionstagen auf | Logs der betroffenen Stunden sichern — sie sind das stärkste Argument in der internen Diskussion |
| Migration ohnehin in Planung | Betriebsmodell nicht separat entscheiden, sondern als Teil des Zielbilds |
| Bereits Cloud-Hosting, aber ohne Skalierungsregeln | Prüfen, ob die Elastizität tatsächlich konfiguriert ist — sonst zahlen Sie Cloud-Preise für feste Kapazität |
Wenn mehrere Ländershops oder Marken auf derselben Infrastruktur liegen, verschiebt sich die Rechnung noch einmal deutlich; dazu steht die Struktur in Multishop-Architektur mit Shopify. Und wer aus einem Magento-Setup kommt, findet die konkrete Projektabfolge in unserer Migrationscheckliste Magento zu Shopify.
Checkliste
Bestandsaufnahme vor der Betriebsmodell-Entscheidung
Zehn Punkte, die geklärt sein sollten, bevor Sie einen Serververtrag verlängern oder einen Plattformwechsel budgetieren. Ihre Häkchen bleiben in diesem Browser gespeichert.
0 von 10 erledigt
Der letzte Punkt der Checkliste ist der eigentliche. Es gibt Unternehmen, für die eigene Infrastruktur ein Wettbewerbsvorteil ist — weil sie etwas tun, das eine Standardplattform nicht abbildet, und weil sie die Leute dafür haben. Für die ist ein dedizierter Server oder eine eigene Cloud-Architektur die richtige Antwort, und dieser Text ändert daran nichts.
Für alle anderen ist Infrastruktur eine Voraussetzung. Sie muss funktionieren, sie darf am Aktionstag nicht wegbrechen, und sie sollte so wenig Aufmerksamkeit wie möglich binden. In dieser Gruppe ist die Frage “Cloud oder dedizierter Server” oft schon die falsche — weil die bessere Antwort lautet, die Frage gar nicht mehr zu stellen.
Wenn Sie vor einer Vertragsverlängerung stehen oder ohnehin über einen Plattformwechsel nachdenken und wissen wollen, welche Ihrer sieben Betriebsschichten tatsächlich Arbeit binden: Lassen Sie uns sprechen — wir sehen uns Lastverlauf, Betriebsaufwand und Ausfallhistorie an und sagen Ihnen, welche Zeilen ein Wechsel Ihnen abnimmt und welche bleiben.
