WebMCP und MCP finden sich gerade in zwei verschiedenen Rollen ein: WebMCP laesst einen Agenten im B…
Shopify Scripts EOL am 30. Juni: Checkout migrieren, ohne das Frontend zu verlieren
Am 30. Juni 2026 schalten Shopify Scripts ab. Wer als Plus-Brand Payment-, Shipping- oder Line-Item-Logik per Script anpasst, hat ab dann keine laufenden Scripts mehr. Editieren ging seit dem 15. April ohnehin nicht mehr. Das sind keine Wochen mehr, das sind Tage. Dieser Post zeigt, warum die erzwungene Functions-Migration der richtige Moment ist, die gesamte Customizing-Architektur einmal sauber zu entwirren, statt nur Script gegen Function zu tauschen.
Was am 30. Juni passiert
Shopify hat die Deprecation klar terminiert: Seit dem 15. April 2026 lassen sich Scripts weder bearbeiten noch neu veröffentlichen. Bestehende Scripts laufen weiter bis zum 30. Juni 2026, danach werden sie nicht mehr ausgeführt (shopify.dev/changelog). Die ursprünglich für August 2025 geplante Frist wurde 2025 auf Juni 2026 verschoben. Diese Verschiebung war einmalig, eine weitere ist von Shopify klar ausgeschlossen.
Betroffen ist jede Plus-Brand mit aktiven Scripts im Script Editor: Discount-Logik, Versandkosten-Regeln, Payment-Method-Sortierung, Bundle-Preise. Die offizielle Nachfolge heißt Shopify Functions plus Checkout Extensibility. Die Migration ist Pflicht, nicht optional.
Warum die meisten die Migration zu eng denken
Die naheliegende Reaktion ist ein 1:1-Port: jedes Script wird zur Function, der Rest bleibt, wie er ist. Das schließt die Deadline, lässt aber die eigentliche Frage liegen.
Denn die meisten Plus-Brands haben über Jahre ein Customizing-Geflecht aufgebaut, das aus drei Schichten besteht, die niemand mehr ganz überblickt:
- Liquid-Theme-Anpassungen für Darstellung und Page-Logik
- Scripts für Checkout-Regeln (die jetzt sterben)
- Checkout-Apps und App-Blocks für alles, was Theme und Script nicht konnten
Diese drei Schichten greifen ineinander, oft mit doppelter Logik. Eine Versandkosten-Regel steckt halb im Script, halb in einer App. Eine Rabatt-Mechanik ist im Liquid hartkodiert, obwohl es ein Script dafür gäbe. Die Functions-Migration zwingt dich, mindestens eine dieser Schichten anzufassen. Das ist der Moment, in dem du die anderen zwei gleich mit sortieren kannst, statt das Geflecht in eine neue Generation zu schleppen.
Der eigentliche Engpass ist das Frontend
Hier liegt die Pointe, die in den meisten Migration-Guides fehlt. Shopify Functions lösen das Checkout-Backend sauber. Sie lösen nicht den Grund, warum Plus-Brands ihr Frontend als Bremse erleben.
Das Frontend einer gewachsenen Shopify-Plus-Storefront kennt in der Praxis zwei Aggregatzustände, beide mit Lock-in:
- Liquid-Theme: ein über App-Blocks und Custom-Code gepatchter Page-Builder-Stack. Performance ist von der Theme- und App-Pflege abhängig, Marketing wartet auf Theme-PR-Reviews, A11y ist fragmentiert.
- Hydrogen plus Oxygen: moderner React-Stack, aber das Frontend muss vollständig entkoppelt werden. Oxygen bringt ein 50ms-CPU-Budget pro Worker, keine WebSockets, GitHub-only CI/CD. Der Checkout läuft trotzdem über Shopify-Payment-Fees.
Beide Wege binden dich an Shopify-spezifische Frontend-Infrastruktur. Wer jetzt nur die Scripts auf Functions hebt und die Frontend-Frage vertagt, schließt eine Baustelle und lässt die größere offen.
Die dritte Option: Functions im Backend, Frontend als eigene Schicht
Es gibt einen Weg, der beide Probleme in einem Zug adressiert. Du migrierst die Checkout-Logik auf Shopify Functions, wo sie hingehört, und entkoppelst gleichzeitig das Frontend in eine eigene Management-Schicht. Shopify bleibt Backend und Commerce-Engine, die Storefront-API (GraphQL) liefert die Daten. Das Frontend wird austauschbar.
Das ist die Kern-These der Frontend Management Platform: Die Schicht, in der Storefronts komponiert, lokalisiert und ausgeliefert werden, gehört nicht in jedes Backend einzeln, sondern in eine eigene Ebene über dem Backend. Konkret für Shopify:
- Laioutr koppelt sich an die Shopify Storefront API. Standard-Integration, kein Custom-Glue-Code.
- Die Checkout-Regeln, die du gerade ohnehin auf Functions migrierst, bleiben in Shopify. Functions ist der saubere Platz dafür.
- Das Frontend läuft als Composable Headless Frontend auf einer Nuxt-Codebasis, nicht als Liquid-Theme und nicht als Hydrogen-auf-Oxygen.
- Multi-Brand und Multi-Locale laufen auf einer Codebasis statt als n parallele Shopify-Stores mit duplizierten App-Lizenzen.
Der entscheidende Punkt: Die Functions-Migration und das Frontend-Decoupling kollidieren nicht. Sie ergänzen sich. Functions ist die richtige Antwort auf das Checkout-Backend, ein entkoppeltes Frontend die richtige Antwort auf den Marketing- und Performance-Engpass.
Migration als Architektur-Inventur: 4 Schritte
Wenn du die Deadline ohnehin angehen musst, nutze sie als strukturierte Inventur statt als Notfall-Port.
1. Customizing-Schichten kartieren
Liste auf, was heute wo lebt: welche Logik im Liquid-Theme, welche in Scripts, welche in Checkout-Apps. Markiere doppelte Logik und tote Pfade. Diese Karte ist die Voraussetzung für jede saubere Entscheidung.
2. Checkout-Logik auf Functions heben
Payment-, Shipping- und Discount-Logik gehören in Shopify Functions. Das ist der Pflicht-Teil mit Deadline. Halte die Functions schlank und sauber dokumentiert, statt die alte Script-Komplexität 1:1 zu übernehmen.
3. Frontend-Logik vom Checkout trennen
Alles, was Darstellung, Page-Komposition, Personalisierung und Marketing-Content betrifft, gehört nicht in Functions und nicht in App-Block-Wildwuchs. Das ist Frontend-Verantwortung. Hier entscheidet sich, ob du an Liquid oder Hydrogen gebunden bleibst oder die Schicht entkoppelst.
4. Den Decoupling-Pfad bewerten
Prüfe, ob ein eigener Frontend-Layer über der Storefront API für dich tragfähig ist. Die Frage ist nicht akademisch: Sie entscheidet, ob deine nächste Replatforming-Diskussion in 24 Monaten ein 18-Monats-Greenfield-Projekt wird oder ein Frontend-Refactor bei laufendem Backend.
Was du gewinnst
Dimension | Nur 1:1-Port auf Functions | Functions plus Frontend-Decoupling |
|---|---|---|
Checkout-Regeln | sauber auf Functions, Deadline geschlossen | sauber auf Functions, Deadline geschlossen |
Frontend-Engpass | bleibt (Liquid oder Hydrogen-Lock) | aufgelöst, Nuxt-Layer über Storefront API |
Time-to-Market Landingpages | Theme-PR-Review, Tage bis Wochen | Studio-Editor mit Live-Preview, Stunden |
Multi-Brand | n Stores, n App-Lizenzen | eine Codebasis, n Brand-Themes |
EU-Hosting | US-Vendor, Schrems-II-Caveat | EU-Region im Frontend-Layer wählbar |
FAQ
Muss ich vor dem 30. Juni das Frontend entkoppeln?
Nein. Die harte Deadline betrifft nur die Scripts. Functions ist der Pflicht-Teil. Das Frontend-Decoupling ist die strategische Option, die du dir mit der Inventur erschließt, nicht unter Zeitdruck erzwingst. Aber genau jetzt liegt die Customizing-Karte ohnehin auf dem Tisch.
Verliere ich Shopify als Backend, wenn ich das Frontend entkopple?
Nein. Shopify bleibt Commerce-Engine und Checkout-Backend. Die Functions, die du jetzt migrierst, laufen weiter in Shopify. Entkoppelt wird nur die Frontend-Schicht über der Storefront API.
Was passiert mit meinem Shopify-Checkout?
Der bleibt. Shopify-Checkout läuft default weiter, die migrierten Functions inklusive. Ein Headless-Checkout ist optional für B2B- oder Multi-Step-Flows, keine Voraussetzung.
Nächste Schritte
Wenn du die Functions-Deadline ohnehin angehst und dabei wissen willst, wie ein entkoppelter Frontend-Layer über deiner Shopify Storefront API in der Praxis aussieht: Buch eine Demo. Wir zeigen dir am echten Setup, wie Backend bei Shopify bleibt und das Frontend wieder in deiner Hand liegt.
Weitere Themen aus der Laioutr-Plattform
Mehr dazu: Magento 2.4.x End-of-Life-Kalender: Versionen & Daten und SAP Accelerator End of Life: Migration zu Composable Frontend ohne Backend Replatforming.