Shopify Scripts stoppen op 30 juni. Als je niet naar Functions bent overgestapt, breekt de checkout.

Als je winkel maatwerklogica bij de checkout draait, is er n datum die je op de muur wilt hebben: 30 juni 2026. Dat is de dag waarop Shopify Scripts stoppen met draaien. Niet uitgefaseerd-maar-nog-strompelend. Gestopt. Welke korting, verzend- of betalingsregel je ook in een Script hebt gebouwd, die draait er gewoon niet meer na.

Wat hier mensen verrast, is dat er niets dramatisch gebeurt. Er is geen foutpagina, geen waarschuwingsbanner, geen e-mail die ochtend. De korting die je verwacht wordt gewoon niet toegepast. De B2B-klant die betalingstermijnen zou moeten overslaan kan dat ineens niet meer. Je hoort het via een supportticket of een verbaasde blik op de cijfers van de dag, wat de slechtste manier is om erachter te komen.

Als je al gemigreerd bent, kun je dit tabblad sluiten. Als je niet zeker weet of je gemigreerd bent, is die onzekerheid het probleem dat het deze maand waard is om op te lossen. Dit is wat er daadwerkelijk verandert en hoe je het werk inschat zonder in paniek te raken.

Twee data, en de tweede is de afgrond

Er zijn twee deadlines, en het is makkelijk om ze door elkaar te halen. De eerste is al gepasseerd. Op 15 april 2026 zette Shopify de Script Editor op slot. Je kunt geen nieuw Script meer schrijven of een bestaand Script bewerken. De Scripts die je had bleven draaien, dus voor veel winkels veranderde er zichtbaar niets en gleed de deadline van de radar.

De tweede datum is degene die bijt. Op 30 juni 2026 stopt elk Script met draaien. Deze deadline is al n keer verschoven, van augustus 2025, dus er is een verleiding om aan te nemen dat hij weer opschuift. Plan alsof dat niet gebeurt. Een tweede uitstel zou een prettige verrassing zijn, geen strategie.

n detail maakt de overgang makkelijker dan het klinkt: Scripts en Functions kunnen tot de deadline naast elkaar draaien. Je hoeft niet alles in n weekend om te zetten. Je kunt n regel herbouwen als Function, hem testen tegen het Script dat hij vervangt, bevestigen dat hij zich gedraagt, en dan door naar de volgende. De klok is het enige dat het tempo forceert.

Wat er echt breekt

Scripts dreven de checkout-logica aan die niet in Shopify's standaardinstellingen past. Als je een Plus-merchant bent, is een deel hiervan waarschijnlijk dragend voor je omzet. De categorien die op 30 juni op zwart gaan:

• Kortingen. Automatische promoties, gelaagde en volumeprijzen, koop-X-krijg-Y, regels op winkelwagenniveau. Als een Script bepaalt wie welke korting krijgt, wordt die beslissing niet meer genomen.
• Verzending. Maatwerk voor tarieflogica, methoden verbergen of herordenen, regels gekoppeld aan winkelwageninhoud of bestemming. Het Script dat het juiste tarief toont verdwijnt, en klanten zien wat er overblijft.
• Betalingen. Betaalmethoden filteren of hernoemen, bepaalde opties verbergen voor bepaalde winkelwagens. Als het Script stopt, stopt de filtering, en opties die je had verborgen komen weer in beeld.
• B2B en beperkingen. Groothandelsregels gebouwd op klantlabels, aantallimieten, productbeperkingen, regiogating. Dit is de categorie die het meest waarschijnlijk een regel verbergt die niemand zich herinnert geschreven te hebben.

De faalmodus die je zou moeten verontrusten is niet de korting die geruisloos stopt en je een paar conversies kost. Het is de beperking die geruisloos stopt. Een aantallimiet waardoor iemand je voorraad kan leegkopen, een regiogate waardoor een bestelling doorkomt die je niet kunt vervullen, een betalingsfilter dat een methode heropent die je om fraudereden had uitgezet. Die kosten je geen verkoop. Ze creren een rommel die je later opruimt.

Functions zijn de vervanging, en het zijn niet zomaar Scripts met een nieuwe naam

Shopify Functions zijn waar je naar overstapt. Technisch zijn ze een echte upgrade. Scripts waren Plus-only Ruby die in een sandbox draaide; Functions compileren naar WebAssembly en draaien op Shopify's kerninfrastructuur, dus ze zijn sneller en gedragen zich voorspelbaarder onder belasting. Voor een founder is de snelheid niet de kop. Twee andere dingen wel.

Ten eerste zitten Functions in apps. Dat betekent dat een deel van de logica die vroeger een developer nodig had om Ruby in een editor te plakken, nu kan komen van een App Store-app die je installeert en configureert. Ten tweede, omdat ze in apps leven, zijn Functions niet beperkt tot Plus. Winkels op lagere plannen krijgen toegang tot dezelfde checkout-aanpassing die vroeger een Plus-voordeel was, wat geruisloos verandert wat mogelijk is voor kleinere merchants.

Shopify heeft ook een aantal veelvoorkomende gevallen het platform zelf in getrokken. BOGO- en volumekortingen die vroeger een Script nodig hadden, kunnen nu in de kortingsinstellingen worden opgezet zonder enige app. Dus voordat je aanneemt dat je iets moet herbouwen, is het de moeite waard om te checken wat native is geworden, want de goedkoopste migratie is de regel die je niet hoeft te herbouwen.

Hoe je de overstap inschat zonder te gokken

Shopify geeft je een Scripts-customizationsrapport dat je huidige Scripts opsomt en aangeeft welke aansluiten op een native feature of een publieke app. Draai het eerst. Het verandert een vaag "we hebben ergens wat Scripts" in een echte lijst, en voor veel winkels laat het zien dat de helft van het werk een instellingswijziging is, geen build.

Het deel dat het rapport niet voor je kan doen is de reden dat dit weken kost in plaats van een middag. Je Scripts coderen bedrijfsbeslissingen die nooit zijn opgeschreven: de klant die een speciaal tarief krijgt vanwege een deal die twee jaar geleden is gesloten, de aantallimiet die werd toegevoegd na n slechte fulfilmentweek, de regio die iemand blokkeerde om een reden die niemand precies kan reconstrueren. De Ruby vertelt je wat de regel doet. Het vertelt je niet waarom, of of het nog steeds zou moeten. Migreren is een kans om de regels te herbouwen die je nog wilt en de regels te laten vallen die pleisters waren voor problemen die je niet meer hebt.

Een verstandige volgorde: trek het rapport, sorteer elk Script in native / publieke app / heeft maatwerk-Function nodig, en pak dan de maatwerkbuilds aan terwijl er nog ruimte is om ze tegen live winkelwagens te testen. Bewaar de maatwerk-Functions voor het laatste weekend van juni en je zit checkout-logica te debuggen zonder marge, precies wanneer een gemist randgeval verandert in terugbetalingen.

Als je checkout-logica eenvoudig is, is dit een korte klus die je zelf vanuit het rapport kunt doen. Als je een Plus-winkel bent met jaren aan opgebouwde Scripts en echt geld dat er doorheen stroomt, behandel het dan als een project met een eigenaar en een deadline, niet als iets waar iemand ooit aan toekomt. De deadline is niet onderhandelbaar, de fout is geruisloos, en het gat tussen "we regelen het wel" en "de checkout doet iets geks" is n datum op de kalender. Beter een week in juni besteden dan een juli opruimen.