Shopify Scripts termina el 30 de junio de 2026: Cómo migrar tus descuentos sin un desarrollador

Shopify Scripts dejan de ejecutarse el 30 de junio de 2026, y todas las reglas personalizadas de descuentos, envíos o pagos que construiste en el Script Editor dejarán de aplicarse en esa fecha. El reemplazo es Shopify Functions, que ejecuta tu lógica del lado del servidor dentro del checkout. Tienes tres formas de llegar: contratar un desarrollador para escribir Functions, pagar a una agencia para hacerlo, o reconstruir lógica de descuentos basada en reglas en una aplicación de Functions sin código. La parte urgente es que el fallo es silencioso. Un Script que deja de ejecutarse, o una regla migrada que no coincide con un carrito, no genera error y no te notifica. Solo carga silenciosamente el precio completo hasta que un cliente se queja.

Esta guía explica qué hacían los Scripts, por qué Shopify los está retirando, qué son realmente las Functions, por qué "migrar mi Script" es en realidad hasta tres migraciones separadas, la trampa de fallo silencioso y exactamente cómo probarla, qué puede y no puede cubrir una aplicación sin código, y un desglose honesto de cuándo aún necesitas un desarrollador.

¿Qué está sucediendo con Shopify Scripts y cuándo?

Shopify Scripts se están retirando. Según la documentación para desarrolladores de Shopify, "Shopify Scripts se retirarán el 30 de junio de 2026. Todos los Scripts existentes de Shopify dejarán de funcionar después de esta fecha." Hay dos fechas que importan, y la primera ya pasó:

• 15 de abril de 2026: la edición y publicación de nuevos Scripts de Shopify ya no es posible. Según el registro de cambios de desarrolladores de Shopify, después de esta fecha no puedes crear ni cambiar un Script en absoluto.
• 30 de junio de 2026: todos los Scripts de Shopify dejan de ejecutarse completamente. Cualquier lógica de descuento, envío o pago que viva en un Script simplemente deja de ejecutarse.

Si tu tienda aún dependía de un Script el 1 de julio de 2026, esa lógica ya está sin conexión mientras lees esto. Las personalizaciones no generaron error ni revirtieron a un valor seguro predeterminado. Se callaron. Esa es la cosa más importante de entender sobre esta fecha límite: no es un fallo ruidoso que notarás por una alerta del panel. Es una ausencia.

Shopify también envía una herramienta para ayudarte a alcanzar el trabajo. El informe de personalizaciones de Scripts de Shopify te ayuda a identificar cuál de tus personalizaciones actuales puede transicionarse a Functions o aplicaciones públicas. Si aún no lo has ejecutado, ese es el paso uno.

MARCADOR DE IMAGEN (Imagen 1): La línea de tiempo de retiro de Scripts

Visualización sugerida: Una línea de tiempo horizontal limpia 16:9 en un fondo blanco con tres marcadores de hito en violeta y oro profundo. Marcador uno, "15 de abril de 2026 - la edición termina" en oro. Marcador dos, "30 de junio de 2026 - Scripts dejan de ejecutarse" en violeta con una pequeña etiqueta roja "silencioso". Una flecha final etiquetada "Shopify Functions" continúa más allá del último marcador. Etiquetas limpias, minimalistas, sans-serif, sin fotografía.

¿Qué hacían Shopify Scripts y por qué Shopify los está retirando?

Shopify Scripts eran pequeños programas Ruby que se ejecutaban en la aplicación Script Editor y personalizaban tres partes del flujo de compra: descuentos de carrito y artículos de línea, tasas de envío y métodos de pago. Un comerciante en Shopify Plus podría escribir un Script que diera un descuento escalonado, ocultara una opción de envío para ciertas direcciones, o reordenara métodos de pago en el checkout. Los Scripts eran poderosos precisamente porque eran código arbitrario: si podías expresarlo en Ruby, podías hacerlo.

Shopify los está reemplazando con Shopify Functions. Según la documentación de migración, "Con Shopify Functions, estas personalizaciones ahora se manejan a través de APIs de Function dedicadas que ofrecen mejor rendimiento y flexibilidad." Las Functions se ejecutan en la propia infraestructura de Shopify dentro del pipeline de checkout, lo que las hace más rápidas y escalables que el modelo antiguo de Scripts, y significa que la misma lógica se aplica ya sea que un comprador haga checkout en la página del carrito, la página de checkout, o una billetera acelerada como Shop Pay.

La compensación es que las Functions no son un cuadro de texto en el que pegas Ruby. Son artefactos de desarrollador: los andamios con Shopify CLI, escribes la lógica en Rust o JavaScript, defines una consulta de entrada GraphQL e implementas a través de una aplicación. Ese cambio, de "el comerciante escribe un Script" a "el desarrollador envía una Function", es toda la razón por la que esta migración es un proyecto y no una casilla de verificación.

¿Qué son Shopify Functions y por qué generalmente necesitan un desarrollador?

Shopify Functions te permiten extender o reemplazar partes de la lógica de backend de Shopify con código personalizado que se ejecuta durante el checkout. Hay APIs de Function dedicadas para las cosas que los Scripts solían hacer, incluyendo una Discount Function API, una Delivery Customization API, y una Payment Customization API.

Dos propiedades de las Functions importan para tu plan de migración.

Las Functions se ejecutan del lado del servidor, una vez

Una Function se ejecuta dentro del checkout de Shopify, no en tu tema. Esa es una mejora genuina sobre los métodos de descuento que calculan un total en JavaScript del tema en la página del carrito y luego no concuerdan con lo que cobra el checkout. Porque la Function es la única fuente de verdad, la vista previa del carrito y el cargo final son el mismo cálculo. Por eso también una Function correctamente construida se aplica idénticamente en Shop Pay, Apple Pay y Google Pay, que omiten la página del carrito completamente.

Las Functions se construyen, no se configuran, por defecto

Escribir una Function desde cero es una tarea de desarrollador. Necesitas Shopify CLI, una cadena de herramientas de lenguaje, y familiaridad con la consulta de entrada de la Function y la forma del resultado. Hay un matiz que vale la pena conocer sobre la disponibilidad de planes: según la documentación de disponibilidad de Functions de Shopify, "Las tiendas en cualquier plan pueden usar aplicaciones públicas distribuidas a través de la Shopify App Store y que contienen functions. Solo las tiendas de Shopify Plus pueden usar aplicaciones personalizadas que contengan Shopify Function APIs." En términos simples: una aplicación pública de la App Store puede traer Functions a cualquier plan, pero una Function personalizada hecha a medida es una ruta solo para Plus. Esa distinción es lo que hace que una aplicación de Functions sin código sea atractiva para comerciantes que no son Plus y que solían depender de un desarrollador.

La buena noticia es que una vez que se implementa una Function dentro de una aplicación, el comerciante la configura desde el administrador sin tocar código. Como lo expresó Shopify cuando Functions se lanzó, "los usuarios finales comerciantes nunca tienen que tocar una línea de código al modificar sus personalizaciones." El código se escribe una vez; la configuración vive en el administrador.

¿Por qué "migrar mi Script" es en realidad tres migraciones separadas?

Aquí está el detalle que sorprende a la gente, y viene directamente de cómo los comerciantes describen el trabajo en los foros de la comunidad de Shopify. Un único archivo de Script podría tocar lógica de descuentos, envíos y pagos a la vez. Las Functions deliberadamente dividen eso en tipos de Function separados e independientes.

• Lógica de descuentos (precios escalonados, BOGO, descuentos de pedido y producto, reglas de apilamiento) se asigna a la Discount Function API. La Discount Function API unificada de Shopify puede aplicar ahorros en las tres clases de descuento, producto, pedido y envío, desde una única función.
• Lógica de envío y entrega (renombrar, reordenar u ocultar opciones de entrega) se asigna a la Delivery Customization Function API, una función completamente separada.
• Lógica de pago (renombrar, reordenar u ocultar métodos de pago) se asigna a la Payment Customization Function API, una tercera función separada.

Entonces la frase "Necesito migrar mi Script" a menudo significa migrar hasta tres cosas diferentes, configuradas e implementadas independientemente. Una aplicación de descuentos sin código puede reconstruir el primer cubo. No llega a los cubos de envío y pago, que es exactamente por qué tienes que inventariar tu Script antiguo antes de asumir que una sola herramienta lo cubre. Divide el trabajo por superficie primero, luego elige una ruta para cada superficie.

MARCADOR DE IMAGEN (Imagen 2): Un Script se convierte en tres Functions

Visualización sugerida: Un diagrama 16:9. En la izquierda, una única caja etiquetada "One Shopify Script (Ruby)" en pizarra. Tres flechas se abren hacia la derecha en tres cajas separadas: "Discount Function" en violeta, "Delivery Function" en oro, "Payment Function" en azul pizarra, cada una con un pequeño pie "deployed independently". Vector plano limpio, colores de marca violeta y oro, sin fotografía.

El peligro del fallo silencioso y cómo probarlo

Esta es la parte que cuesta dinero real a los comerciantes, y merece su propia sección porque se aplica tanto a la fecha límite en sí como a cada regla que reconstruyes.

Una Function de Shopify es bien formada y en ejecución, o está mal configurada y silenciosa. No hay un estado intermedio visible. Una Function cuyas condiciones no coinciden con un carrito dado no se ejecuta, no genera error y no te alerta. Eso es por diseño: el mismo silencio que obtienes de una Function que funciona correctamente (correctamente no hizo nada para un carrito que no debería calificar) es el silencio que obtienes de una Function que está rota (un error tipográfico en un umbral, una regla enfocada en la colección incorrecta, un nivel que nunca se activa).

Los comerciantes trabajando en esta migración describen la misma experiencia en los foros de la comunidad de Shopify: una regla silenciosamente deja de aplicar un descuento, y el comerciante solo se entera porque un cliente se queja de ser cobrado precio completo. Sin error, sin alerta, nada en los registros de pedidos. La tienda había estado funcionando en una configuración rota durante semanas antes de que alguien lo notara.

La única defensa confiable es probar ambas direcciones antes de confiar en una regla en vivo:

1. Construye un carrito que debe dispararse. Ensambla un carrito real que cumpla cada condición de la regla, coloca un pedido de borrador o prueba, y lee línea por línea el resumen del checkout. Confirma que el descuento exacto que esperas está presente, en la cantidad que esperas.
2. Construye un carrito que no debe dispararse. Ensambla un carrito que deliberadamente no califica, por ejemplo un artículo por debajo de tu umbral de cantidad, y confirma que el descuento se mantiene correctamente apagado.

Una Function que se ejecuta cuando no debería es tan costosa como una que nunca se ejecuta silenciosamente. No terminas de probar hasta que hayas visto la regla tanto aplicarse como declinar correctamente. Ejecuta también el carrito que debe dispararse a través de Shop Pay, para que confirmes que la ruta acelerada concuerda con el checkout estándar.

Un paso más de preservación mientras estás aquí: guarda tu fuente de Script antiguo ahora. Una vez que el Script Editor se retira completamente, su código almacenado se vuelve irrecuperable de Shopify. Exporta o copia tu fuente de Script hoy, incluso si aún no estás listo para reconstruirlo, para que tengas una referencia para lo que sea que lo reemplace.

¿Puede una aplicación sin código migrar mis Scripts? Lo que cubre y lo que no

Para la superficie de descuentos específicamente, una aplicación de Functions sin código puede absorber una gran parte de lo que los comerciantes usaban Scripts. Si la lógica de tu Script se reduce a reglas, es decir, "cuando el carrito se ve como X, aplica descuento Y", una aplicación basada en configuración generalmente puede reconstruirlo sin un desarrollador. Eso cubre mucho terreno común:

• Descuentos escalonados y de volumen, como "compra 3 o más, ahorra 15 por ciento."
• Buy X Get Y y lógica BOGO, incluyendo niveles repetidos como "compra 6 obtén 2, compra 9 obtén 3."
• Reglas explícitas de apilamiento y combinación entre ofertas.
• Inicio programado, final y pausa instantánea en una campaña.

Lo que una aplicación de descuentos sin código no puede hacer es igualmente importante de decir claramente, porque asumir lo contrario es cómo las migraciones fallan silenciosamente:

• Código personalizado arbitrario. Si tu Script ejecutó una fórmula de precios personalizada o una condición única que no se reduce a una regla que cualquier constructor expone, ninguna aplicación de descuentos puede expresarla. Esa lógica aún necesita que un desarrollador escriba una Function personalizada.
• Personalizaciones de envío y pago. Esos son tipos de Function separados (entrega y pago). Una aplicación de descuentos solamente no los alcanza. Un desarrollador migra esos independientemente.
• Cualquier cosa fuera de una configuración de descuento basada en reglas. Si no era fundamentalmente "condiciones adentro, descuento afuera", una pantalla de configuración es la forma incorrecta para ello.

La prueba honesta es simple: escribe, en una oración, lo que cada parte de tu Script antiguo hacía. Si la oración es una regla sobre descuentos, una aplicación sin código es una candidata fuerte. Si es una fórmula, un cambio de envío, un cambio de pago, o algo que no puedes expresar como una regla, presupuesta un desarrollador para esa parte.

Ejecuta esta migración confiablemente con Stackable

Si la lógica de descuentos de tu Script era basada en reglas, niveles, BOGO, apilamiento y programación, Stackable reconstruye exactamente esa superficie en Shopify Functions nativas sin código, y es honesto sobre sus límites.

• Reconstruye lógica de descuentos basada en reglas, incluyendo precios de volumen y escalonados, BOGO, apilamiento de descuentos explícito, e inicio programado, final y pausa, como configuración que editas en el administrador en lugar de Ruby que mantienes.
• La matemática se ejecuta dentro de una Function de Shopify, por lo que el carrito, checkout y Shop Pay calculan un total idéntico. No hay arrastre tema-versus-checkout, que es un modo de fallo común de las configuraciones antiguas de descuentos.
• Un simulador de carrito te permite ejecutar tanto un carrito que debe dispararse como uno que no debe dispararse antes de que vayas en vivo, para que captures una mala configuración silenciosa en una vista previa en lugar de en una queja de cliente.
• Es honesto sobre el alcance. Stackable no ejecuta código personalizado arbitrario, y no toca personalizaciones de envío (entrega) o pago. La lógica genuinamente personalizada y esos dos tipos de Function separados aún necesitan un desarrollador.

Instala Stackable gratis y pasa tu lógica de descuentos por reglas a Shopify Functions antes de que te cueste una venta sin enterarte, en usestackable.com/pricing. 🚀

Ejemplo práctico: una lista de verificación de migración que puedes seguir hoy

Usa esta secuencia para convertir "mi Script se rompió" en una migración controlada. La tabla asigna un Script típico multipropósito a sus destinos.

Luego trabaja los pasos en orden:

1. Inventaría el Script antiguo antes de construir cualquier cosa

Abre el Script Editor mientras aún puedas y escribe una oración por comportamiento. Ejecuta el informe de personalizaciones de Scripts de Shopify para confirmar que nada se está ocultando. Exporta la fuente de Ruby y guárdala en un lugar seguro, porque se vuelve irrecuperable una vez que el editor se retira.

2. Divide el inventario por superficie

Ordena cada comportamiento en descuento, envío o pago. Esto te dice inmediatamente qué piezas una aplicación de descuentos sin código puede tomar y cuáles necesitan un desarrollador. No asumar que una sola herramienta cubre las tres.

3. Reconstruye las piezas de descuentos basadas en reglas sin código

Para cada comportamiento que se reduce a "condiciones adentro, descuento afuera", recréalo en descuentos nativos de Shopify o una aplicación de descuentos basada en Functions. Establece reglas de combinación explícitamente si las ofertas están destinadas a apilarse.

4. Entrega las piezas que no son reglas a un desarrollador

Las fórmulas personalizadas, las personalizaciones de entrega y las personalizaciones de pago van a un desarrollador o agencia para construir como sus propias Functions. Dale la fuente de Script exportada como la especificación.

5. Prueba cada regla reconstruida de ambas formas

Para cada regla, ejecuta un carrito que debe dispararse y uno que no debe dispararse. Lee línea por línea el resumen del checkout. Una regla no se migra hasta que hayas visto tanto aplicarse como declinar correctamente.

6. Verifica los checkouts acelerados

Ejecuta tu carrito que debe dispararse a través de Shop Pay. Porque las Functions se calculan del lado del servidor, una regla correctamente construida se aplica idénticamente. Esta es tu última verificación de que nada depende del código del tema que las billeteras omiten.

MARCADOR DE IMAGEN (Imagen 3): Prueba ambas direcciones antes de confiar en ello

Visualización sugerida: Una ilustración dividida 16:9. Panel izquierdo etiquetado "Carrito que debe dispararse" muestra un resumen de checkout con una línea de descuento verde correctamente presente. Panel derecho etiquetado "Carrito que no debe dispararse" muestra un resumen de checkout con el descuento correctamente ausente y una marca de verificación verde. Un pie central lee "Una regla silenciosa nunca genera error - prueba ambas." Colores de marca violeta y oro, vector plano, sin fotografía.

El resultado final

• Shopify Scripts dejan de ejecutarse el 30 de junio de 2026, y la edición ya terminó el 15 de abril de 2026. Cualquier Script aún en uso ahora está sin conexión.
• El fallo es silencioso. Un Script que se detuvo, o una regla migrada que no coincide con un carrito, nunca genera error y nunca te alerta. Solo carga el precio completo.
• Las Functions son el reemplazo, ejecutándose del lado del servidor dentro del checkout, pero escribir una desde cero es una tarea de desarrollador, y las Functions personalizadas son una ruta solo para Plus.
• Un Script a menudo se convierte en tres migraciones: Discount, Delivery y Payment Functions, cada una implementada independientemente.
• Una aplicación de Functions sin código puede reconstruir lógica de descuentos basada en reglas (niveles, BOGO, apilamiento, programación). No puede hacer código arbitrario, envío o personalizaciones de pago.
• Guarda tu fuente de Script antigua ahora. Se vuelve irrecuperable una vez que el Script Editor se retira.
• Prueba cada regla reconstruida con un carrito que debe dispararse y uno que no debe dispararse, y lee línea por línea el resumen del checkout, incluyendo a través de Shop Pay.

Artículos relacionados

• Migración de Shopify Scripts: la ruta completa de rescate, qué se reconstruye sin código, y qué aún necesita un desarrollador.
• Cómo funciona el apilamiento de descuentos en Shopify: por qué nativo aplica solo el descuento más alto, y cómo combinar ofertas correctamente.
• Descuentos de volumen y saltos de cantidad: reconstruye precios escalonados que cuentan el mismo producto, no la colección completa.
• Apilamiento de descuentos, hecho bien: los tres interruptores de combinación por clase, con un simulador de carrito en vivo.
• Límite de 100 productos de Shopify en Buy X Get Y: ejecuta 3 de 2 en un catálogo completo después de migrar.
• Precios de Stackable: planes, el nivel gratuito, y qué incluye cada uno.