Aus Plugins werden Dienste: Was der Umstieg auf Shopify an Ihrer Shop-Architektur ändert
Shopware, Magento und WooCommerce sind Monolithen: Jedes Plugin läuft im selben Prozess, arbeitet auf derselben Datenbank und greift bei Bedarf in den Bestellvorgang ein. Shopify ist weder Monolith noch Microservice-Landschaft, sondern ein Kern, den Sie nicht betreiben, mit Rändern, die über Schnittstellen mit ihm sprechen. Was das für jedes einzelne Plugin bedeutet, warum aus Live-Abfragen Synchronisationen werden und was sich schon vor dem Go-live aus dem alten Shop herauslösen lässt.
In der dritten Projektwoche liegt die Plugin-Liste auf dem Tisch. 43 Zeilen, exportiert aus dem Shopware-Backend eines Großhändlers, jede mit einer leeren Spalte „Ersatz in Shopify“. Die meisten Zeilen sind schnell gefüllt. Versandkosten nach Gewicht: Standard. Bewertungen: App. Cookie-Banner: Einstellung. Dann Zeile 23, „ERP-Live-Preise“. In der Spalte steht bisher: „App suchen“.
Das Plugin tut seit acht Jahren dasselbe. Legt ein Kunde etwas in den Warenkorb, fragt es das ERP nach dem Preis für diesen Kunden und nach dem verfügbaren Bestand, wartet ein paar hundert Millisekunden und zeigt dann beides an. Antwortet das ERP nicht, lässt das Plugin keine Bestellung zu. Niemand im Raum hat das je für eine Architekturentscheidung gehalten. Es war ein Plugin.
Die Suche nach der passenden App scheitert. Nicht, weil der App Store zu klein wäre, sondern weil es die Stelle nicht gibt, an der eine App das tun könnte: Den Artikelpreis, den Shopify im Checkout berechnet, kann kein App-Code live beim ERP abfragen und als Verkaufspreis setzen. Shopify rechnet mit den Preisen, die schon in Shopify liegen, wenn der Kunde kommt. Die einzige Ausnahme, Functions mit Netzwerkzugriff, gibt es nur im Enterprise-Angebot oberhalb von Plus. Aus der Live-Abfrage wird eine Synchronisation. Das ist kein Detail der Umsetzung, sondern eine andere Bauweise. Und sie betrifft nicht nur Zeile 23.
Shopify hat Mitte September einen Ratgeber zum Wechsel vom Monolithen zu Microservices veröffentlicht: schrittweise, mit klaren Service-Grenzen und mit Monitoring von Anfang an. Für Händler, die das Shopsystem wechseln, stellt sich die Frage andersherum. Ob sich ihre Architektur ändert, entscheiden sie nicht, denn der Umstieg ändert sie so oder so. Offen ist nur, ob jemand diese Änderung plant.
Ihr Shopsystem ist ein Monolith, auch wenn es nie so hieß
Shopware 6, Magento 2 und WooCommerce sind in verschiedenen Sprachen und Frameworks gebaut, aber nach demselben Prinzip: eine Anwendung, eine Datenbank, und Erweiterungen, die innerhalb dieser Anwendung laufen. Ein Shopware-Plugin ist ein Symfony-Bundle im selben Prozess. Ein Magento-Modul setzt sich mit Plugins vor, nach oder um öffentliche Methoden des Kerns und hört über Observer auf dessen Ereignisse. Ein WooCommerce-Plugin hängt sich an Actions und Filter im selben PHP-Request. Alle drei dürfen eigene Tabellen anlegen, fremde Tabellen lesen und in den Bestellvorgang eingreifen, bis hin zum Abbruch: In Shopware hält ein Warenkorb-Validator die Bestellung auf, in WooCommerce genügt eine Fehlermeldung an der richtigen Stelle.
Das ist die Stärke dieser Systeme und der Grund, warum gewachsene Shops so viele Plugins haben. Fast jede Anforderung ließ sich genau dort lösen, wo sie auftrat. Es ist aber auch der Grund für den Nachteil, den der Ratgeber Monolithen zuschreibt: Änderungen an einem Bereich wirken auf andere. Wer ein Major-Update von Shopware oder Magento hinter sich hat, weiß, wie das aussieht. Jedes Plugin muss einzeln geprüft werden, weil jedes Plugin überall hingreifen darf.
Shopware und Adobe kennen inzwischen auch Erweiterungen, die außerhalb laufen: Shopware mit seinem App-System, das über Webhooks und die Admin API angebunden ist, Adobe Commerce mit dem App Builder. In gewachsenen Shops ist das trotzdem die Ausnahme. Wer ein Plugin schreiben durfte, hat ein Plugin geschrieben.
Ein Vorgang, zwei Bauweisen
Derselbe Bestellvorgang, zweimal gebaut
Oben der Checkout eines gewachsenen B2B-Shops auf Shopware oder Magento, unten derselbe Ablauf nach dem Umstieg. Die Nummern zeigen, wo jeder Schritt landet. Zwei wandern ganz aus dem Bestellvorgang hinaus, einer davor und einer dahinter. Ein dritter teilt sich.
Altsystem
Ein Prozess · eine Datenbank · ein Request
- 1 Kern Warenkorb berechnen
- 2 Plugin Preis und Bestand live beim ERP abfragen wartet, darf abbrechen
- 3 Plugin Rechnungskauf nur für Bestandskunden
- 4 Kern Bestellung speichern
- 5 Plugin Gravurtext in eigene Tabelle schreiben
- 6 Plugin Bestellung ans ERP übergeben
Alles läuft nacheinander in derselben Anfrage. Antwortet das ERP nicht, kann das Plugin in Schritt 2 die Bestellung verhindern.
Shopify
Ein Kern · Ränder über Schnittstellen
Vorher
Außen · asynchron
- 2 Ein Sync schreibt Preise und Bestände aus dem ERP nach Shopify.
- 3 Was der Checkout über den Kunden wissen muss, liegt als Kundenmerkmal bereit.
So aktuell wie der Takt des Syncs
Im Checkout
Im Kern · synchron
- 1 Shopify berechnet Warenkorb, Steuern und Versand.
- 3 Eine Function blendet den Rechnungskauf für Neukunden aus.
- 4 Shopify speichert die Bestellung.
- 5 Der Gravurtext hängt als Eigenschaft an der Position der Bestellung.
Preise und Bestände kommen aus dem Kern
Danach
Außen · asynchron
- 6 Ein Webhook meldet die Bestellung an Ihre App, die sie ans ERP übergibt.
Meist nach Sekunden, im Fehlerfall Stunden später
Schritt 3 steht unten zweimal, weil er sich teilt: Die Entscheidung fällt im Checkout, die Daten dafür müssen vorher im Kern liegen. Das ist das Muster fast jeder Checkout-Logik nach dem Umstieg.
In Shopify zerfällt der Bestellvorgang in drei Zeitpunkte, und nur der mittlere gehört dem Checkout. Was vorher passieren muss, läuft als Synchronisation außerhalb von Shopify. Was danach passieren soll, erfährt Ihr System über ein Ereignis, das nach der Bestellung eintrifft. Dazwischen laufen Functions, die schnell sind, weil sie nichts fragen dürfen.
Shopify ist weder das eine noch das andere
Eine Pointe am Rand: Shopify selbst betreibt einen der bekanntesten Monolithen im E-Commerce. Der Kern der Plattform ist eine große Ruby-on-Rails-Anwendung, und das Engineering-Team hat öffentlich beschrieben, warum es sie nicht in Microservices zerlegt hat, sondern in Komponenten mit festen Grenzen innerhalb derselben Codebasis. 2020 waren das nach eigenen Angaben über 2,8 Millionen Zeilen Ruby, 500.000 Commits und 37 Komponenten. Das Werkzeug, mit dem Shopify diese Grenzen prüft, heißt Packwerk und ist Open Source.
Die Frage „Monolith oder Microservices“ stellt sich nach dem Umstieg deshalb an anderer Stelle. Den Kern mit Katalog, Warenkorb, Checkout, Bestellungen und Kundenkonten bekommen Sie als verwalteten Block. Sie stellen ihn nicht bereit, skalieren ihn nicht und spielen keine Sicherheitsupdates ein. Alles, was Sie hinzufügen, liegt an den Rändern: Apps laufen auf eigenen Servern und sprechen über die Admin API und Webhooks mit dem Kern. Functions laufen in einer Sandbox im Kern. Das Theme stellt dar, was der Kern liefert.
Die fehlende dritte Spalte
Monolith, Microservices, Shopify: sechs Unterschiede im Alltag
Der übliche Vergleich kennt zwei Modelle. Wer auf Shopify umsteigt, landet in keinem von beiden. Er bekommt die Einfachheit des Monolithen für den Kern und die Eigenschaften von Microservices für alles, was er selbst hinzufügt.
Die Microservice-Spalte beschreibt, was der Shopify-Ratgeber für einen Eigenbau nennt. Beim Umstieg baut ihn niemand bewusst. Er entsteht an den Rändern, App für App.
An den Rändern bekommen Sie, was der Ratgeber für Microservices beschreibt: eigene Bereitstellung, eigene Skalierung, Kommunikation über Schnittstellen und Fehlersuche über Systemgrenzen hinweg. Ob Sie das wollen, spielt dabei keine Rolle. Jede App ist ein eigener Dienst, und bei einem gewachsenen Shop kommen schnell zwei Dutzend zusammen.
Auch der Zugriff auf Daten ändert seinen Charakter. Ein Plugin im Altsystem las die Bestelltabelle mit einer Datenbankabfrage, so oft es wollte. Eine App fragt die GraphQL Admin API und bezahlt jede Abfrage mit Punkten aus einem Kontingent. Es füllt sich in den Basistarifen mit 100 Punkten pro Sekunde wieder auf, bei Advanced mit 200 und bei Plus mit 1.000. Keine einzelne Abfrage darf mehr als 1.000 Punkte kosten. Für den Alltag reicht das fast immer. Für einen nächtlichen Export von 200.000 Bestellungen muss jemand die Massenabfragen der API eingeplant haben, sonst läuft der Export in die Grenze.
Wohin jedes Plugin wandert
Die Frage „Welche App ersetzt Plugin X?“ ist deshalb die falsche erste Frage. Die richtige lautet: Wann muss diese Logik laufen, und welche Daten braucht sie dafür? Daraus ergibt sich der Ort. Und erst am Ort entscheidet sich, ob daraus eine Einstellung, eine Function, eine App, eine Erweiterung oder ein Datenmodell wird.
Plugin-Liste nach dem Umstieg
Zwölf Anforderungen und ihr neuer Ort
Zwölf Zeilen, wie sie in fast jeder Liste aus Plugins und Sonderregeln eines gewachsenen Shops stehen. Welcher Ort passt, entscheidet nicht der Name des Plugins, sondern der Zeitpunkt, zu dem die Logik laufen muss, und die Daten, die sie dafür braucht.
- Einstellung · 3 von 12 Shopify kann es selbst
- Function · 4 von 12 Im Kern, synchron, ohne Netzwerk
- App oder Middleware · 3 von 12 Außen, über API und Webhooks
- Erweiterung · 1 von 12 Zeigt an oder fragt ab, in Theme oder Checkout
- Datenmodell · 1 von 12 Metafelder, Metaobjekte, Eigenschaften
Die Verteilung ist typisch, nicht gesetzmäßig. In B2B-Shops wächst der Anteil der Apps und Syncs, in Shops mit viel Checkout-Logik der Anteil der Functions. Fast nie ist es eine Eins-zu-eins-Liste von Plugin zu App.
Vier dieser Orte tauchen in fast jeder Liste auf.
Was Shopify selbst kann, wird zur Einstellung. Versandprofile, das Cookie-Banner, das Double-Opt-in für den Newsletter. Diese Zeilen sind am schnellsten erledigt, und trotzdem installieren Projekte genau hier am häufigsten zu viel: Das alte Plugin hatte einen Namen, und die Suche im App Store findet unter diesem Namen fast immer etwas.
Was im Checkout entscheiden muss, wird zur Function. Zahlungsarten ausblenden, Versandarten umbenennen, einen Mindestbestellwert erzwingen, Bundles bilden. Functions laufen synchron im Kern, aber mit harten Grenzen. Sie haben keinen Netzwerkzugriff, von der Enterprise-Ausnahme für einzelne Function-Arten abgesehen. Bei üblichen Warenkörben bekommen sie höchstens 128 kB Eingabedaten und elf Millionen Instruktionen. Alles, was eine Function braucht, muss deshalb vorher als Metafeld oder Kundenmerkmal im Kern liegen. Eigens gebaute Apps mit Functions sind Plus-Shops vorbehalten. Ohne Plus bleibt der Weg über eine öffentliche App aus dem App Store, die das Gewünschte kann.
Muss eine Prüfung unbedingt live beim ERP nachfragen, gibt es mit Plus noch einen Weg: eine Checkout-Erweiterung mit Netzwerkzugriff, die den Checkout anhalten darf. Sie läuft allerdings im Browser des Kunden. Für einen Hinweis an ehrliche Kunden taugt das, als Sperre, auf die sich die Buchhaltung verlassen kann, nicht.
Was nach der Bestellung passiert, wird zur App oder zur Middleware. Übergabe ans ERP, Rechnung, Versandlabel, Warenwirtschaft. Hier liegt die eigentliche Verschiebung, denn diese Logik kann den Bestellvorgang nicht mehr aufhalten. Die Bestellung existiert, bevor Ihre App von ihr erfährt.
Eigene Tabellen werden zu Metafeldern, Metaobjekten und Positionseigenschaften. Gravurtexte, Pflegehinweise, ein Händlerverzeichnis: Was ein Plugin im Altsystem in eine eigene Tabelle geschrieben hat, bekommt in Shopify einen Platz im Kern. Metafelder und Metaobjekte mit Definitionen und Typen, Positionseigenschaften als freie Werte an der einzelnen Bestellposition, alles erreichbar über dieselbe API wie der Rest. Das ist der seltene Fall, in dem die neue Bauweise einfacher ist als die alte.
Die Transaktion endet an der Systemgrenze
In vielen gewachsenen Shops war die Übergabe ans ERP ein Teil des Bestellvorgangs. Der Code lief in derselben Anfrage, und wenn er scheiterte, stand es im selben Log. Nach dem Umstieg ist die Übergabe eine Nachricht. Shopify schickt einen Webhook an Ihre App, und Ihre App gibt die Bestellung weiter. Dazwischen liegt ein Netzwerk, und für Nachrichten über ein Netzwerk gelten andere Zusagen als für einen Funktionsaufruf.
Nach der Bestellung
Was ein Webhook zusagt und was nicht
Nach dem Umstieg erfährt Ihr ERP von einer Bestellung durch eine Nachricht. Shopify dokumentiert genau, was für diese Nachrichten gilt. Fünf Punkte davon entscheiden, ob eine Anbindung im Alltag hält.
- 01
Kurze Antwortfrist
Shopify dokumentiert
Eine Sekunde für den Verbindungsaufbau, fünf Sekunden für die gesamte Anfrage. Alles darüber gilt als gescheitert.
Ihre Anbindung muss
Annehmen, in eine Warteschlange legen, sofort antworten. Verarbeitet wird danach, nicht währenddessen.
- 02
Wiederholung mit Ende
Shopify dokumentiert
Bis zu acht Wiederholungen innerhalb von vier Stunden. Halten die Fehler an, entfernt Shopify das Abonnement.
Ihre Anbindung muss
Die Zustellmetriken überwachen. Was nach dem letzten Versuch fehlt, holt nur noch der Abgleich zurück.
- 03
Duplikate sind möglich
Shopify dokumentiert
Dieselbe Zustellung kann mehr als einmal ankommen. Wiedererkennbar ist sie an
X-Shopify-Webhook-IdIhre Anbindung muss
Jede Nachricht so verarbeiten, dass die zweite nichts ändert. Im ERP heißt das: vor dem Anlegen die Bestellnummer prüfen.
- 04
Keine feste Reihenfolge
Shopify dokumentiert
Eine Änderung kann vor der Anlage ankommen. Shopify empfiehlt, nach dem Zeitstempel zu ordnen, etwa
X-Shopify-Triggered-AtIhre Anbindung muss
Nach Zeitstempel sortieren, nicht nach Ankunft. Eine Nachricht mit älterem Stand als dem gespeicherten verwerfen.
- 05
Kein Ersatz für den Abgleich
Shopify dokumentiert
Apps sollen sich nicht allein auf Webhooks verlassen, sondern regelmäßig Daten bei Shopify abrufen und abgleichen.
Ihre Anbindung muss
Einmal am Tag abgleichen: Bestellnummern in Shopify gegen Bestellnummern im ERP. Jede Differenz ist ein Fall, kein Rauschen.
Nach einem längeren Ausfall unterscheidet Shopify zwei Arten von Abonnements: Solche, die eine App in ihrer Konfiguration deklariert, müssen nicht neu angelegt werden. Solche, die sie zur Laufzeit über die API angelegt hat, schon. Welche Art Ihre Anbindung nutzt, gehört in die Dokumentation.
Keine dieser Eigenschaften ist ein Mangel. Sie sind der Preis dafür, dass ein Ausfall Ihres ERP nicht mehr Ihren Checkout blockiert. Das Plugin aus der Einleitung tut genau das. Aber sie verlangen von jeder Anbindung vier Fähigkeiten, die im Monolithen niemand gebraucht hat: Nachrichten sofort annehmen und später verarbeiten; dieselbe Nachricht zweimal verarbeiten, ohne doppelt zu buchen; die Reihenfolge selbst herstellen, statt sich auf die Ankunft zu verlassen; und regelmäßig abgleichen, weil nach dem letzten Zustellversuch nichts mehr kommt.
Den Abgleich rüsten wir in Projekten am häufigsten nach. Ein täglicher Vergleich der Bestellnummern des Vortags in Shopify und im ERP ist ein überschaubarer Baustein. Er findet Fehler, die sonst erst in der Monatsabstimmung der Buchhaltung auffallen, und dann ohne Hinweis darauf, wann sie entstanden sind. Wie die Anbindung selbst aufgebaut sein kann, von der direkten API-Verbindung bis zur Warteschlange, zeigen wir in den Integrationsmustern für ERP und Shopify.
Der verteilte Monolith entsteht über ein gemeinsames Feld
Der Ratgeber warnt vor einem Zustand, den er „verteilten Monolithen“ nennt: Services, die technisch getrennt, aber so eng voneinander abhängig sind, dass keiner ohne die anderen geändert werden kann. In Shopify-Shops entsteht er selten durch Code. Er entsteht über ein Feld, das mehrere Apps gemeinsam benutzen, und fast immer ist es zuerst ein Tag.
Der verteilte Monolith
Ein Kunden-Tag, vier Schreiber
So sieht enge Kopplung in einem Shopify-Shop aus: kein gemeinsamer Code, aber ein gemeinsames Feld. Oben der Zustand, der ohne Absicht entsteht, unten derselbe Ablauf mit klarer Datenhoheit.
Nach einem Jahr
Vier Schreiber, ein Tag
Schreibt
- ERP-Konnektor setzt es bei jedem Abgleich
- B2B-App setzt es bei der Freischaltung
- Flow-Workflow entfernt es beim Löschen des Firmenkontos
- Kundenservice setzt es von Hand
Feld
b2b Freier Text, jeder darf schreiben Liest
- Preis-App zeigt Nettopreise
- Theme blendet Staffelpreise ein
- E-Mail-App baut das Händler-Segment
Entfernt Flow das Tag und setzt das ERP es in der Nacht wieder, sieht ein gelöschter Händler am Morgen wieder Nettopreise. Keine der vier Stellen hat einen Fehler gemacht.
Mit einem Schreiber
Ein Schreiber, ein Metafeld
Schreibt
- ERP-Konnektor einziger Schreiber, Quelle ist das ERP
Feld
custom.kundenstatus Feste Definition, erlaubte Werte als Liste Liest
- Preis-App zeigt Nettopreise
- Theme blendet Staffelpreise ein
- E-Mail-App baut das Händler-Segment
- B2B-App liest, statt zu schreiben
Wer den Status ändern will, ändert ihn im ERP. Das Feld in Shopify ist eine Kopie mit genau einer Herkunft.
Vier Warnzeichen für einen verteilten Monolithen
- Ein Feld hat mehr als einen Schreiber.
- Eine App funktioniert nur, wenn eine andere vorher gelaufen ist.
- Mehr als zwei Automatisierungen reagieren nacheinander auf dasselbe Ereignis.
- Niemand kann sagen, welche App eine Bestellung zuletzt verändert hat.
Tags sind in Shopify das einfachste gemeinsame Feld. Jede App kann sie lesen und schreiben, Shopify Flow kann auf sie reagieren, das Theme kann sie auswerten, automatische Kollektionen filtern nach ihnen. Genau deshalb werden sie zum Integrationsbus, ohne dass es jemand beschließt. Nach einem Jahr weiß niemand mehr, wer das Feld führt. Das ist exakt die Frage, die der Ratgeber für die Aufteilung eines Monolithen stellt: Welcher Dienst verwaltet welche Daten?
Die Antwort ist hier dieselbe wie dort: Jedes Feld hat genau einen Schreiber. Für Tags heißt das, sie als Anzeige- und Filterhilfe zu verwenden, nicht als Übergabe zwischen Systemen. Für Daten, die mehrere Apps brauchen, gibt es Metafelder mit festen Definitionen und erlaubten Werten. Und jede Kette, in der mehr als zwei Systeme nacheinander auf dasselbe Ereignis reagieren, bekommt eine Zeile in der Dokumentation mit dem Namen der Person, der sie gehört.
Der verteilte Monolith hat eine zweite, leisere Form: Updates. Shopify veröffentlicht jedes Quartal eine neue API-Version und unterstützt jede mindestens zwölf Monate. Jede App, die Sie selbst betreiben, muss diesem Takt folgen. Bei öffentlichen Apps erledigt das der Anbieter, bei eigenen Apps niemand, wenn es niemand eingeplant hat. Im Altsystem kam der Update-Druck mit jedem Major-Release. Nach dem Umstieg kommt er in einem festen Rhythmus: mindestens ein Versionswechsel pro Jahr, bei vier neuen Versionen jährlich.
Was schon vor dem Umstieg aus dem Monolithen herauskann
Die wichtigste Empfehlung des Ratgebers lautet: nicht alles auf einmal. Mit einem abgegrenzten Bereich beginnen, alten und neuen Teil parallel betreiben, dann den nächsten Bereich herauslösen. In der Softwarearchitektur heißt das Strangler-Fig-Muster, benannt nach der Würgefeige, die einen Baum so lange umwächst, bis er nicht mehr gebraucht wird.
Auf einen Shopwechsel lässt sich das nur zur Hälfte übertragen. Der Kern zieht an einem Tag um. Eine Bestellung kann nicht halb im alten und halb im neuen Shop entstehen, ein Kundenkonto nicht in beiden gleichzeitig gelten, ein Bestand nicht von zwei Systemen abgebucht werden. Die Ränder aber lassen sich vorher lösen. Was schon vor dem Go-live außerhalb des alten Shops läuft und mit Shopify ebenso gut zusammenarbeitet, zieht am Go-live-Tag nicht mehr mit.
Das Strangler-Prinzip
Herauslösen, umziehen, ergänzen
Drei Phasen statt eines Stichtags: was vorher herauskann, was nur gemeinsam umziehen kann und was erst danach sinnvoll ist.
- 01
Vorher herauslösen
Wochen bis Monate vor dem Go-live
- Bewertungen zu einem Anbieter, der beide Systeme anbindet Bewertungen und ihre Historie ziehen nicht mehr um.
- Newsletter und Einwilligungen auf eine eigenständige E-Mail-Plattform Einwilligungen samt Zeitpunkt bleiben, wo sie sind.
- Produktdaten in ein PIM Shopify wird ein weiterer Kanal, den das PIM beliefert.
- ERP-Anbindung in eine Middleware Am Go-live wird ein Konnektor getauscht, nicht die Anbindung neu gebaut.
Jeder Baustein hier ist am Go-live-Tag eine Aufgabe weniger.
- 02
Am Go-live-Tag
Ein Tag, nicht teilbar
- Katalog und Preise
- Kundenkonten
- Bestellhistorie
- Warenkorb und Checkout
- Theme und Inhalte
- Weiterleitungen
Diese Teile hängen aneinander und ziehen gemeinsam um.
- 03
Danach ergänzen
In den Monaten nach dem Go-live
- Functions für Sonderlogik nachschärfen
- Apps zusammenlegen, die dasselbe tun
- Eigene Logik in einer App bündeln
- Einzelne Seiten entkoppeln, wo das Theme nicht reicht
Erst mit echten Daten aus dem Betrieb, nicht nach der Wunschliste von vorher.
Herauslösen lohnt sich vor allem, wenn beides zutrifft
- Der Baustein hält Daten, die den Umstieg überleben sollen.
- Der Anbieter bedient beide Systeme mit fertigen Anbindungen.
- Selten lohnend für Suche, Filter und Checkout-Logik: Sie werden auf Shopify ohnehin neu gebaut.
Das lohnt sich nicht für alles. Wer die Shopsuche drei Monate vor dem Umstieg auf einen externen Anbieter umstellt, bindet sie zweimal an: einmal an das alte System, einmal an Shopify. Das rechnet sich nur, wenn der Anbieter für beide Systeme fertige Anbindungen hat und die zweite Anbindung eine Konfiguration ist, kein Projekt. Die Faustregel lautet deshalb: Herauslösen lohnt sich für alles, was Daten hält, die den Umstieg überleben sollen, sofern der Anbieter beide Systeme fertig anbindet. Das trifft auf Bewertungen, Newsletter-Einwilligungen und Produktdaten zu. Die ERP-Anbindung ist ein Sonderfall: Sie hält keine eigenen Daten, aber wer sie ohnehin in eine Middleware verlegen will, tauscht am Go-live-Tag nur noch einen Konnektor. Für Funktionen, die auf Shopify ohnehin anders gebaut werden, lohnt sich das Herauslösen nicht.
Bei Bewertungen und Einwilligungen kommt ein zweiter Grund dazu. Liegen sie im alten Shop in Plugin-Tabellen, müssen sie exportiert, umgeformt und importiert werden, bei Einwilligungen samt dem Nachweis, wann und wie sie erteilt wurden. Liegen sie schon vorher bei einem Anbieter, der beide Systeme bedient, ist das am Go-live-Tag keine Aufgabe mehr. Jede solche Aufgabe weniger macht den Umstieg kürzer und den Rückweg einfacher; mehr dazu im Beitrag über das Risikomanagement beim Plattformwechsel.
Wann eigene Dienste neben Shopify sinnvoll sind
Bleibt die Frage, um die es im Ratgeber eigentlich geht: Brauchen Sie Microservices? Nach dem Umstieg lautet die Antwort für die meisten Shops: Nein, Sie haben bereits genug davon. Jede App ist einer, nur betreibt ihn jemand anders.
Eigene Dienste lohnen sich dort, wo drei Bedingungen zusammentreffen. Die Logik ist geschäftskritisch und spezifisch für Ihr Unternehmen. Sie ändert sich häufiger, als ein App-Anbieter liefern würde. Und Sie haben jemanden, der sie betreibt, mit Monitoring, mit dem Wechsel auf neue API-Versionen und mit Bereitschaft, wenn nachts die Übergabe hängt. Fehlt die dritte Bedingung, ist eine öffentliche App mit einem Anbieter, der das für Sie übernimmt, fast immer die bessere Wahl. Wann ein Eingriff ins Theme reicht und wann es eine eigene App braucht, haben wir im Vergleich Custom Liquid oder Custom App durchgespielt. Ähnlich beim Frontend: Headless ist eine Entscheidung für einzelne Stellen, nicht für den ganzen Shop.
Die häufigste gute Antwort ist eine einzige eigene App statt vieler kleiner. Ein Dienst, der die Übergabe ans ERP, die Sonderlogik für Großkunden und die zwei, drei Functions bündelt, die kein App-Anbieter so liefert. Das ist kein Microservice-Design, sondern sein Gegenteil: ein kleiner Monolith am Rand des großen. Für die meisten Händler ist das die Architektur, die zu ihrem Unternehmen passt. Und genau damit schließt auch der Ratgeber: Die Architektur muss zum Unternehmen passen.
Checkliste
Checkliste: Architektur vor dem Umstieg
Neun Punkte, die geklärt sein sollten, bevor die erste App installiert wird. Ihre Häkchen bleiben in diesem Browser gespeichert.
0 von 9 erledigt
Was für Ihre Ausgangslage sinnvoll ist
| Ihre Situation | Empfehlung |
|---|---|
| Shopware- oder Magento-Shop mit mehr als 30 Plugins | Die Liste nach Zeitpunkt sortieren, nicht nach Plugin-Namen. Erst danach im App Store suchen |
| B2B mit Live-Preisen oder Live-Bestand aus dem ERP | Früh klären, wie aktuell Preise und Bestände in Shopify sein müssen. Daraus folgt der Sync, nicht aus der Wahl der App |
| Eigene Plugins, die den Checkout abbrechen | Jede Bedingung einzeln prüfen. Mit Daten im Kern wird sie eine Function. Braucht sie Live-Daten, mit Plus eine Checkout-Erweiterung, sonst ein Prozess danach |
| Checkout-Logik ohne Plus-Tarif | Eigene Functions entfallen. Für jede Regel eine öffentliche App suchen oder die Regel vor den Checkout verlegen |
| Plugins mit eigenen Datenbanktabellen | Das Datenmodell in Shopify vor der Migration definieren und die Daten mit umziehen, nicht danach nachtragen |
| ERP-Übergabe bisher im selben Request | Warteschlange, Duplikatprüfung, Reihenfolge nach Zeitstempel und täglicher Abgleich gehören in die Abnahme, nicht in eine spätere Ausbaustufe |
| Mehrere Apps, die über Tags zusammenarbeiten sollen | Vor dem Go-live festlegen, welches System welches Feld schreibt. Übergaben über Metafelder mit Definition |
| Bewertungen oder Newsletter liegen in Plugin-Tabellen | Vor dem Umstieg zu einem Anbieter ziehen, der beide Systeme anbindet. Einwilligungen mit Zeitpunkt und Herkunft |
| Kleines Team ohne eigene Entwicklung | Möglichst wenig eigener Code. Öffentliche Apps, deren Anbieter Betrieb und API-Updates übernimmt |
| Eigene Entwicklung im Haus | Eine eigene App als Bündel statt vieler kleiner. Den Quartalstakt der API im Teamkalender verankern |
| Headless-Frontend im selben Projekt geplant | Systemwechsel und Architekturwechsel trennen. Erst umziehen, dann gezielt entkoppeln |
Was Sie aus diesem Artikel mitnehmen sollten
Der Umstieg von Shopware, Magento oder WooCommerce auf Shopify ist ein Architekturwechsel, auch wenn ihn niemand so nennt. Er führt nicht zu Microservices, sondern zu einem Kern, den Sie nicht mehr betreiben, und zu Rändern, die Sie bewusst gestalten sollten. Drei Punkte entscheiden das meiste.
Sortieren Sie Logik nach Zeitpunkt, nicht nach Plugin-Namen. Was vor dem Kauf feststehen muss, wird eine Synchronisation. Was im Checkout entscheidet, wird eine Function mit Daten aus dem Kern. Was danach passiert, wird eine Nachricht an eine App. Erst daraus ergibt sich, welche App oder welcher Code gebraucht wird.
Bauen Sie jede Anbindung für ein Netzwerk. Nachrichten kommen doppelt, in falscher Reihenfolge oder nach dem letzten Versuch gar nicht. Warteschlange, Duplikatprüfung, Zeitstempel und ein täglicher Abgleich sind keine Kür, sondern der Ersatz für die Transaktion, die es an der Systemgrenze nicht mehr gibt.
Geben Sie jedem Feld einen Schreiber. Der verteilte Monolith entsteht in Shopify nicht durch Code, sondern durch geteilte Tags und Metafelder. Wer vor dem Go-live festlegt, welches System welches Feld führt, spart sich die Fehlersuche über vier App-Anbieter hinweg.
Wenn Sie einen Systemwechsel planen und wissen wollen, wohin Ihre Plugin-Liste nach dem Umstieg wandert: Lassen Sie uns sprechen. Wie wir Migrationen aufsetzen, steht auf Shopsystem-Migration; wie die übrige Systemlandschaft beim Umstieg neu geordnet wird, beschreibt der Beitrag zum digitalen Ökosystem.
