Shopify Scripts laufen ab dem 30. Juni nicht mehr. Wer nicht auf Functions umgestiegen ist, dessen Checkout fällt aus.

Wenn Ihr Shop irgendeine individuelle Logik im Checkout betreibt, gibt es einen Termin, den Sie sich an die Wand schreiben sollten: 30. Juni 2026. Das ist der Tag, an dem Shopify Scripts aufhören zu laufen. Nicht abgekündigt-aber-noch-humpelnd. Gestoppt. Welche Rabatt-, Versand- oder Zahlungsregel Sie auch in einem Script gebaut haben, sie läuft danach einfach nicht mehr.

Diese Sache erwischt die Leute deshalb, weil nichts Dramatisches passiert. Keine Fehlerseite, kein Warnbanner, keine E-Mail am Morgen danach. Der Rabatt, den Sie erwarten, greift einfach nicht. Der B2B-Kunde, der die Zahlungsbedingungen überspringen soll, kann es plötzlich nicht mehr. Sie erfahren davon aus einem Support-Ticket oder durch einen verwirrten Blick auf die Tageszahlen, was die schlechteste Art ist, davon zu erfahren.

Wenn Sie bereits migriert haben, können Sie diesen Tab schließen. Wenn Sie nicht sicher sind, ob Sie migriert haben, ist genau diese Unsicherheit das Problem, das es diesen Monat zu lösen gilt. Hier steht, was sich wirklich ändert und wie Sie die Arbeit ohne Panik planen.

Zwei Termine, und der zweite ist die Kante

Es gibt zwei Fristen, und man verwechselt sie leicht. Die erste ist schon vorbei. Am 15. April 2026 hat Shopify den Script Editor gesperrt. Sie können kein neues Script mehr schreiben oder ein bestehendes bearbeiten. Die vorhandenen liefen weiter, also änderte sich für viele Shops sichtbar nichts und der Termin geriet aus dem Blick.

Das zweite Datum ist das, das zubeißt. Am 30. Juni 2026 hört jedes Script auf zu laufen. Dieser Termin wurde bereits einmal verschoben, vom August 2025, also liegt die Versuchung nahe anzunehmen, er rutsche erneut. Planen Sie so, als ob nicht. Eine zweite Verlängerung wäre eine angenehme Überraschung, keine Strategie.

Ein Detail macht den Übergang einfacher, als er klingt: Scripts und Functions können bis zum Stichtag nebeneinander laufen. Sie müssen nicht alles an einem Wochenende umstellen. Sie können eine Regel als Function neu aufbauen, sie gegen das Script testen, das sie ersetzt, ihr Verhalten bestätigen und dann zur nächsten übergehen. Die Uhr ist das Einzige, was das Tempo vorgibt.

Was tatsächlich kaputtgeht

Scripts trieben die Checkout-Logik an, die nicht in Shopifys Standardeinstellungen passt. Wenn Sie ein Plus-Händler sind, ist ein Teil davon wahrscheinlich tragend für Ihren Umsatz. Die Kategorien, die am 30. Juni dunkel werden:

• Rabatte. Automatische Aktionen, gestaffelte und mengenabhängige Preise, Kaufe-X-erhalte-Y, Regeln auf Warenkorbebene. Wenn ein Script entscheidet, wer welchen Rabatt bekommt, wird diese Entscheidung nicht mehr getroffen.
• Versand. Individuelle Tariflogik, Ausblenden oder Umsortieren von Methoden, Regeln, die an Warenkorbinhalt oder Zielort hängen. Das Script, das den richtigen Tarif einblendet, fällt weg, und Kunden sehen, was übrig bleibt.
• Zahlungen. Filtern oder Umbenennen von Zahlungsmethoden, Ausblenden bestimmter Optionen für bestimmte Warenkörbe. Wenn das Script stoppt, stoppt die Filterung, und Optionen, die Sie ausgeblendet hatten, tauchen wieder auf.
• B2B und Beschränkungen. Großhandelsregeln auf Basis von Kunden-Tags, Mengenlimits, Produktbeschränkungen, Regionssperren. Das ist die Kategorie, in der sich am ehesten eine Regel versteckt, an deren Erstellung sich niemand erinnert.

Der Ausfallmodus, der Ihnen Sorgen bereiten sollte, ist nicht der Rabatt, der still aussetzt und Sie ein paar Conversions kostet. Es ist die Beschränkung, die still aussetzt. Ein Mengenlimit, das jemandem erlaubt, Ihr Lager leerzukaufen, eine Regionssperre, die eine Bestellung durchlässt, die Sie nicht erfüllen können, ein Zahlungsfilter, der eine Methode wieder öffnet, die Sie aus Betrugsgründen abgeschaltet hatten. Die kosten Sie keinen Verkauf. Die schaffen ein Chaos, das Sie später aufräumen.

Functions sind der Ersatz, und sie sind nicht einfach Scripts mit neuem Namen

Shopify Functions sind das, worauf Sie umsteigen. Technisch sind sie ein echtes Upgrade. Scripts waren Plus-exklusives Ruby, das in einer Sandbox lief; Functions kompilieren zu WebAssembly und laufen auf Shopifys Kerninfrastruktur, also sind sie schneller und verhalten sich unter Last vorhersehbarer. Für eine Gründerin ist die Geschwindigkeit nicht die Schlagzeile. Zwei andere Dinge sind es.

Erstens: Functions kommen in Apps. Das bedeutet, ein Teil der Logik, die früher einen Entwickler brauchte, der Ruby in einen Editor einfügt, kann jetzt aus einer App Store App kommen, die Sie installieren und konfigurieren. Zweitens, weil sie in Apps leben, sind Functions nicht auf Plus beschränkt. Shops auf niedrigeren Tarifen erhalten Zugriff auf dieselbe Checkout-Anpassung, die früher ein Plus-Vorteil war, was still verändert, was für kleinere Händler möglich ist.

Shopify hat außerdem einige gängige Fälle in die Plattform selbst geholt. BOGO und Mengenrabatte, die früher ein Script brauchten, lassen sich jetzt ganz ohne App in den Rabatteinstellungen einrichten. Bevor Sie also annehmen, dass Sie irgendetwas neu aufbauen müssen, lohnt es sich zu prüfen, was nativ geworden ist, denn die günstigste Migration ist die Regel, die Sie gar nicht neu aufbauen müssen.

Wie Sie den Umstieg planen, ohne zu raten

Shopify stellt Ihnen einen Scripts-Customizations-Report bereit, der Ihre aktuellen Scripts auflistet und kennzeichnet, welche auf eine native Funktion oder eine öffentliche App abbilden. Führen Sie ihn zuerst aus. Er verwandelt ein vages "wir haben irgendwo ein paar Scripts" in eine echte Liste, und für viele Shops zeigt er, dass die Hälfte der Arbeit eine Einstellungsänderung ist, kein Aufbau.

Der Teil, den der Report nicht für Sie erledigen kann, ist der Grund, warum das Wochen statt einen Nachmittag dauert. Ihre Scripts kodieren Geschäftsentscheidungen, die nie aufgeschrieben wurden: der Kunde, der einen Sonderpreis bekommt wegen eines Deals, der vor zwei Jahren abgeschlossen wurde, das Mengenlimit, das nach einer schlechten Fulfillment-Woche hinzukam, die Region, die jemand aus einem Grund sperrte, den niemand ganz rekonstruieren kann. Das Ruby sagt Ihnen, was die Regel tut. Es sagt Ihnen nicht, warum, oder ob sie es noch sollte. Die Migration ist eine Chance, die Regeln neu aufzubauen, die Sie noch wollen, und die fallen zu lassen, die Notlösungen für Probleme waren, die Sie nicht mehr haben.

Eine vernünftige Reihenfolge: ziehen Sie den Report, sortieren Sie jedes Script in nativ / öffentliche App / braucht eigene Function, und kümmern Sie sich dann um die individuellen Builds, solange noch Spielraum bleibt, sie gegen echte Warenkörbe zu testen. Lassen Sie die eigenen Functions bis zum letzten Juni-Wochenende liegen, und Sie debuggen Checkout-Logik ohne Reserve, was genau der Moment ist, in dem ein übersehener Sonderfall zu Rückerstattungen wird.

Wenn Ihre Checkout-Logik einfach ist, ist das eine kurze Aufgabe, die Sie selbst anhand des Reports erledigen können. Wenn Sie ein Plus-Shop mit jahrelang angesammelten Scripts und echtem Geld sind, das durch sie fließt, behandeln Sie es als Projekt mit einem Verantwortlichen und einer Frist, nicht als etwas, zu dem irgendwann jemand kommt. Die Frist ist nicht verhandelbar, der Ausfall ist lautlos, und die Lücke zwischen "wir kümmern uns drum" und "der Checkout macht irgendwas Komisches" ist ein einziges Datum im Kalender. Besser eine Woche im Juni investieren als einen Juli mit Aufräumen verbringen.