Am 30. Juni 2026 schaltet Shopify den Script Editor endgültig ab. Seit dem 15. April 2026 können bestehende Scripts nicht mehr bearbeitet werden, nur noch angesehen. Wer Shopify Plus nutzt und mit Scripts arbeitet, hat jetzt ein paar Wochen, um sauber auf Shopify Functions umzustellen.
Das klingt nach Dev-Zeug, ist aber ein harter Business-Case: Nach dem Stichtag funktionieren Discount-Scripts, Shipping-Scripts und Payment-Scripts einfach nicht mehr. Wer unvorbereitet ist, verliert Automationen, die Umsatz bringen, und im schlimmsten Fall funktioniert der Checkout in Teilen nicht mehr wie erwartet. Die offizielle Ankündigung steht in der Shopify Help-Dokumentation, und Shopify Functions ist der offizielle Nachfolger.
Was der Umstieg konkret bedeutet, wen er betrifft und wie du dein Setup sauber auf Shopify Functions migrierst, steht in diesem Artikel.
Was am 30. Juni 2026 passiert
Shopify kündigt das Ende des Script Editors schon länger an. Die Timeline ist dreistufig:
Seit 15. April 2026: Scripts können nicht mehr bearbeitet werden. Bestehende Scripts laufen weiter, neue Scripts lassen sich nicht mehr anlegen und vorhandene nicht mehr ändern. Das betrifft auch kleinste Anpassungen wie Tippfehler-Korrekturen.
30. Juni 2026: Der Script Editor wird abgeschaltet. Alle Scripts werden deaktiviert. Das bedeutet: Rabatte, Versandregeln und Payment-Filter, die auf Scripts basieren, greifen nicht mehr.
Danach: Der Script Editor ist nur noch lesend erreichbar. Du kannst deine alten Scripts noch einsehen, aber nicht mehr reaktivieren. Für aktive Logik braucht es Shopify Functions.
Wichtig: Shopify migriert nicht automatisch. Jedes Script, das du aktiv hast, musst du manuell als Function nachbauen. Wer das versäumt, steht am 1. Juli ohne seine bisherige Rabatt- oder Checkout-Logik da.
Wer vom Scripts-Ende betroffen ist
Die Abschaltung betrifft ausschließlich Shopify Plus. Der Script Editor war nie auf Basic, Grow oder Advanced verfügbar. Wer auf diesen Plänen ist, muss nichts tun.
Für Plus-Shops geht es konkret um drei Script-Typen, die Shopify unterschied:
Line Item Scripts für Rabatte und Preisregeln am Warenkorb, zum Beispiel Staffelpreise, Kombi-Rabatte, Kunden-spezifische Discounts oder Mitgliederpreise.
Shipping Scripts für angepasste Versandregeln, etwa kostenloser Versand ab einem bestimmten Warenkorbwert, Ausblenden bestimmter Versandarten für bestimmte Regionen oder Produkte, Express-Optionen nur für bestimmte Kundengruppen.
Payment Scripts für das Filtern von Zahlungsmethoden, zum Beispiel Vorkasse ausblenden ab einem bestimmten Warenkorbwert oder PayPal nur für B2C-Kunden.
Wenn du dir unsicher bist, ob dein Shop Scripts nutzt: Admin-Bereich öffnen, unter Apps den Script Editor suchen. Wenn er installiert ist und aktive Scripts zeigt, hast du Migrationsbedarf.
Was Shopify Functions ist
Shopify Functions ist das Nachfolgesystem für den Script Editor. Es gibt aber zwei grundsätzliche Unterschiede: Functions laufen nicht mehr als interpretierte Scripts, sondern als kompilierter Code in WebAssembly. Und sie werden außerhalb des Shopify-Admins entwickelt, typischerweise in JavaScript oder Rust mit der Shopify CLI.
Der praktische Effekt: Functions sind deutlich schneller, skalieren besser bei großen Warenkörben und können komplexere Logik abbilden. Gleichzeitig sind sie aufwändiger zu entwickeln, weil sie ein richtiges Dev-Setup brauchen.
Functions werden als Custom App deployed. Das heißt: Du legst im Shopify Partner Dashboard eine App an, schreibst den Function-Code lokal, kompilierst ihn und pushst ihn in den Shop. Das klingt komplizierter als es ist, aber es ist ein anderer Workflow als der alte Script Editor, in dem du einfach in ein Textfeld getippt hast.
Script Editor vs Functions im Vergleich
Entwicklungsumgebung: Script Editor war ein Textfeld im Admin. Functions erfordern lokale Entwicklung mit Shopify CLI, Node.js und Git.
Sprache: Scripts waren in einem angepassten Ruby-Dialekt. Functions sind in JavaScript oder Rust.
Performance: Scripts hatten ein CPU-Limit pro Checkout. Functions sind deutlich performanter, weil sie als WASM laufen.
Testing: Scripts konnten nur live im Shop getestet werden. Functions lassen sich lokal testen, bevor sie deployed werden. Das ist der größte Win.
Deployment: Scripts wurden per Button im Admin aktiviert. Functions werden über die CLI deployed und im Admin einer spezifischen Discount oder Shipping Rule zugewiesen.
Wartbarkeit: Scripts lagen im Shopify-Admin, nicht in Versionskontrolle. Functions liegen in deinem Git-Repo, versionierbar und nachvollziehbar.
Migration Schritt für Schritt
Schritt 1: Inventur. Listee alle aktiven Scripts auf. Für jedes Script dokumentierst du: Welche Logik macht es, welche Edge Cases hat es, gibt es Kundengruppen-Abhängigkeiten, wie kritisch ist es fürs Business.
Schritt 2: Priorisieren. Rabattlogik am Warenkorb ist meist kritischer als Versand-Filter. Fang mit dem an, was im Fall eines Ausfalls den größten Umsatz-Schaden hätte.
Schritt 3: Dev-Setup. Shopify CLI installieren, Partner Dashboard anlegen falls noch nicht vorhanden, Custom App erstellen. Für Einsteiger: Shopify hat dafür die Dokumentation unter shopify.dev/docs/apps/build/functions. Wer das Dev-Setup nicht selbst aufziehen will, kann die komplette Migration als Shopify-Hilfe-Paket einkaufen.
Schritt 4: Function entwickeln. Shopify stellt Templates für die häufigsten Use Cases bereit: product-discount, order-discount, shipping-discount, delivery-customization, payment-customization. Jedes Template enthält ein Beispiel-Script, das du als Basis nutzen kannst.
Schritt 5: Lokal testen. Mit der CLI und realistischen Warenkorb-Daten testen. Unit Tests schreiben, falls die Logik komplex ist. Dieser Schritt war beim Script Editor nie möglich und ist jetzt der Hauptvorteil.
Schritt 6: Im Dev-Store deployen. Nie direkt in den Produktionsshop. Shopify Plus erlaubt Dev-Stores, in denen du die Function end-to-end testen kannst, ohne echte Bestellungen zu beeinflussen.
Schritt 7: Live schalten. Function in den Live-Shop deployen und der passenden Regel (Discount, Shipping Rule, Payment Customization) zuweisen. Erst dann das alte Script deaktivieren, nicht vorher.
Schritt 8: Monitoring. Mindestens zwei Wochen beobachten: Warenkorb-Reports, Conversion Rate, Kunden-Support-Tickets. Viele Migrations-Fehler fallen erst auf, wenn ein Edge Case im Checkout triggert.
Typische Stolpersteine
Komplexe verschachtelte Rabatt-Logik. Wer Scripts mit mehreren If-Else-Ebenen hatte, stellt fest, dass Functions einen anderen Execution-Context haben. Verschachtelte Conditions funktionieren anders, vor allem bei sich widersprechenden Rabatten.
Kundengruppen-Logik. Scripts konnten auf Customer Tags direkt zugreifen. Functions brauchen teilweise zusätzliche Metafelder oder API-Calls. Das ändert die Architektur, nicht nur den Code.
Versand-Regeln mit Gewichtsbezug. Wer Shipping Scripts hat, die auf Produkt-Gewicht filtern, muss in Functions teilweise Metafields oder Product-Tags nutzen, weil die Gewichts-Attribute anders verfügbar sind.
Payment-Filter mit B2B-Bezug. Wenn du Zahlungsmethoden nach B2B/B2C filterst, musst du prüfen, ob die Customer-Company-Daten in deiner Function verfügbar sind. Je nach Shop-Setup braucht das zusätzliche Konfiguration.
Deployment-Berechtigungen. Custom Apps zu deployen braucht im Partner Dashboard die richtigen Scopes. Wer das nicht vorbereitet hat, scheitert beim ersten Push.
Was die Migration kostet
Die Preisspanne ist groß, weil die Komplexität der Scripts stark variiert.
Kleine Shops mit 1 bis 2 Scripts: 500 bis 1.500 Euro, meist zwischen 4 und 12 Stunden Arbeit. Ein simples Free-Shipping-Script oder ein Staffelpreis lässt sich vergleichsweise schnell nachbauen.
Mittelgroße Shops mit 3 bis 5 Scripts: 1.500 bis 4.000 Euro. Hier kommt oft die Komplexität dazu, dass Scripts miteinander interagieren.
Große Plus-Shops mit komplexen B2B- oder Mitglieder-Regeln: 4.000 bis 10.000 Euro aufwärts. Hier geht es nicht nur um Code, sondern auch um Testing-Aufwand und parallele Dev- und Prod-Phase.
Nicht vergessen: Nach der Migration bleibt der Custom-App-Code bei dir und muss langfristig gepflegt werden. Wer keinen Developer im Team hat, plant einen Wartungs-Retainer ein.
Aus der Praxis
Ich habe kürzlich für einen Plus-Kunden drei Discount-Scripts migriert, die eine verschachtelte B2B-Rabattlogik mit Staffelpreisen und Kundengruppen abbildeten. Ein ähnliches Custom-App-Setup haben wir auch bei Strive Magazine umgesetzt, dort für die Subscription- und Bundle-Logik. Die reine Code-Portierung war in wenigen Stunden erledigt. Der größte Teil der zwei Tage Arbeit ging in Testing und Edge-Case-Prüfung im Dev-Store. Das zeigt: Die Migration selbst ist machbar, aber Testing ist nicht verhandelbar, weil Rabatt-Fehler direkt Umsatz kosten.
Fazit
Der 30. Juni 2026 ist ein harter Deadline. Wer Shopify Plus nutzt und Scripts aktiv hat, sollte jetzt handeln, nicht Ende Mai.
Die Migration ist keine einfache Knopf-Drücken-Aktion, sondern ein Dev-Projekt. Je komplexer die bestehenden Scripts, desto mehr Zeit solltest du einplanen, vor allem fürs Testing.
Der Vorteil: Shopify Functions sind performanter, besser testbar und langfristig wartbar. Wer jetzt sauber migriert, hat für die nächsten Jahre ein stabiles Setup.
Wenn du Unterstützung bei der Migration brauchst, melde dich. Ich arbeite regelmäßig mit Shopify Plus und helfe dir, die bestehenden Scripts sauber in Functions zu überführen, inklusive Testing und Live-Deployment.
Unterstützung bei der Umsetzung?
Du willst die Änderungen sauber in deinem Shopify-Shop umsetzen lassen? Ich übernehme die technische Arbeit und sorge dafür, dass alles zuverlässig läuft.
Jetzt Erstgespräch buchen