Shopify Functions vs Scripts: guía de migración antes del deadline de junio 2026

El plazo ya venció: Scripts dejó de ejecutarse el 30 de junio de 2026

Actualizado en octubre de 2026. Si tu tienda Shopify utilizaba Scripts para personalizar descuentos, reglas de envío o lógica de pago, el calendario de retirada ya se ha consumido entero. Shopify cumplió las dos fechas que había anunciado: desde el 15 de abril de 2026 dejó de ser posible editar o publicar Scripts, y el 30 de junio de 2026 todos los Scripts dejaron de ejecutarse por completo.

Eso significa que, a día de hoy, esto ya no es una guía preventiva: es una guía de diagnóstico y reparación. Si nadie migró esa lógica a Shopify Functions antes del verano, tu checkout lleva meses funcionando sin ella — y lo más probable es que nadie se haya dado cuenta de que falta, porque Shopify no muestra ningún error: simplemente deja de aplicar el descuento, de ocultar el método de envío o de reordenar las pasarelas de pago.

No hubo prórroga. Las personalizaciones que dependían de Scripts dejaron de funcionar, lo que afecta directamente al proceso de compra y, por tanto, a la facturación. El patrón que vemos en auditorías es siempre el mismo: la tienda sigue vendiendo, pero los descuentos por volumen, los envíos gratuitos condicionales o las restricciones de pasarela ya no se aplican, y la desviación aparece en el margen antes que en el panel de Shopify.

En este artículo explicamos qué son Shopify Functions, en qué se diferencian de Scripts, cómo detectar qué lógica se te quedó atrás y cómo ejecutar la migración de forma segura aunque llegues tarde. Si además estás revisando toda tu arquitectura de tienda, te puede interesar nuestra guía para elegir plataforma de ecommerce en 2026.

Scripts vs Functions: qué cambia y por qué

Cómo funcionaban los Scripts

Shopify Scripts permitía escribir pequeños programas en Ruby que se ejecutaban durante el proceso de checkout para modificar el comportamiento de descuentos de línea y de carrito, métodos de envío (ocultar, reordenar, modificar precios) y pasarelas de pago (ocultar, reordenar métodos de pago). Scripts se ejecutaba en un sandbox Ruby dentro de los servidores de Shopify, con acceso limitado a las APIs del checkout.

Cómo funcionan las Functions

Shopify Functions es la evolución de Scripts con diferencias fundamentales. En lugar de Ruby, se escriben en Rust, JavaScript o TypeScript. Se compilan a WebAssembly (Wasm) para ejecución ultrarrápida, con un presupuesto de instrucciones y un tamaño máximo de entrada de 128 kB por ejecución. Se despliegan como parte de una app de Shopify, no como scripts independientes. Tienen acceso a APIs más ricas y extensas, y son configurables por el comerciante desde el admin de Shopify.

El cambio de modelo es significativo: mientras Scripts eran fragmentos de código sueltos, Functions son extensiones estructuradas que forman parte del ecosistema de apps de Shopify. Esto significa mejor mantenibilidad, mejor rendimiento y mejor integración con el resto de la plataforma.

Tipos de Functions disponibles

Discount Functions

Reemplazan los line item scripts y cart scripts para descuentos. Permiten crear lógicas de descuento complejas: descuentos por volumen, descuentos por combinación de productos, descuentos condicionales basados en atributos del cliente o del carrito, descuentos escalonados, y prácticamente cualquier regla de precio que necesites.

Delivery Customization Functions

Sustituyen los shipping scripts. Permiten modificar las opciones de envío que se muestran al cliente durante el checkout: ocultar métodos de envío según condiciones, reordenar opciones, renombrar métodos de envío o añadir mensajes personalizados.

Payment Customization Functions

Reemplazan los payment scripts. Controlan qué métodos de pago se muestran al cliente: ocultar métodos de pago según el valor del carrito, el país del cliente o cualquier otra condición, y reordenar las opciones de pago.

Cart Transform Functions

Esta es una categoría nueva que no existía en Scripts. Permite transformar el contenido del carrito antes del checkout: agrupar productos automáticamente en bundles, añadir productos complementarios, o aplicar lógica de negocio sobre la composición del carrito.

Validaciones de carrito y de checkout

Tampoco existían en Scripts. Permiten bloquear el avance del checkout cuando no se cumple una condición de negocio: pedido mínimo por cliente mayorista, incompatibilidad entre dos productos, límite de unidades de un artículo en promoción, obligatoriedad de un campo. Antes esto se intentaba resolver con JavaScript en el tema, que el cliente podía saltarse; ahora la validación vive en el servidor y no se puede esquivar.

Reglas de ubicación, recogida en tienda y restricciones de fulfillment

Este grupo cubre la parte logística: qué almacén o tienda física atiende cada pedido, qué puntos de recogida se ofrecen al cliente, cuánto se cobra por la recogida local y qué restricciones de preparación se aplican. Para una tienda con red física o con varios almacenes es la parte más valiosa del catálogo de Functions, y es donde más claramente se ve que Functions no es un reemplazo uno a uno de Scripts, sino una capa de extensibilidad bastante más amplia.

Qué sigue estando fuera del alcance de Functions

Functions actúa en puntos concretos del flujo de compra, no en cualquier lugar. No sirve para modificar el escaparate, no reemplaza a las apps que necesitan interfaz propia, y no puede hacer llamadas a servicios externos durante su ejecución: todo lo que necesite decidir tiene que venir en la entrada que Shopify le pasa, o estar almacenado en metafields. Si tu lógica de precios dependía de consultar un ERP en tiempo real durante el checkout, Functions no es la pieza que lo resuelve — ese dato tiene que estar sincronizado previamente en Shopify, lo que normalmente implica montar una integración entre la tienda y el ERP.

Guía de migración paso a paso

Paso 1: Inventario de Scripts activos

Accede a tu panel de Shopify y revisa todos los Scripts activos. Para cada uno, documenta qué hace exactamente (la lógica de negocio que implementa), cuándo se activa (condiciones), y cuál es su impacto en el negocio (qué dejaría de funcionar si desaparece). Este inventario es tu mapa de migración.

Paso 2: Mapear cada Script a su Function equivalente

Cada Script tiene un equivalente en Functions. Los discount scripts migran a Discount Functions, los shipping scripts a Delivery Customization Functions, y los payment scripts a Payment Customization Functions. La lógica es similar pero la implementación es diferente.

Paso 3: Desarrollo de la app con Functions

Las Functions se despliegan como parte de una app de Shopify. Si no tienes una app propia, necesitas crear una usando el Shopify CLI — el proceso completo, con el stack recomendado, lo detallamos en nuestra guía para desarrollar una app de Shopify. El proceso típico incluye inicializar la app con Shopify CLI, crear las Functions necesarias dentro de la app, implementar la lógica en Rust, JavaScript o TypeScript, configurar la interfaz de usuario para que el comerciante pueda gestionar las reglas, testear en un entorno de desarrollo, y desplegar la app en la tienda.

Paso 4: Testing en paralelo

Antes de desactivar los Scripts, activa las Functions en paralelo durante un período de prueba. Verifica que el comportamiento es idéntico: mismos descuentos aplicados, mismas opciones de envío mostradas, mismos métodos de pago disponibles. Cualquier discrepancia debe ser investigada y corregida antes de la migración definitiva.

Paso 5: Desactivación de Scripts

Una vez verificado que las Functions replican correctamente el comportamiento de los Scripts, desactiva los Scripts y monitoriza la tienda durante unos días para detectar cualquier anomalía. Es buen momento para revisar también el rendimiento del propio checkout, porque las Functions se ejecutan dentro de él.

Errores comunes en la migración

Los problemas más frecuentes que encontramos son diferencias sutiles en el cálculo de descuentos (redondeos, orden de aplicación), condiciones que funcionaban en Scripts pero necesitan adaptación en Functions (acceso a datos diferentes), y rendimiento: Functions con Wasm es más rápido, pero una implementación ineficiente puede generar timeouts. Si tu tienda ya arrastraba problemas de velocidad, conviene cruzarlo con una revisión de rendimiento de la tienda Shopify antes de culpar a la Function.

Qué hacer ahora que el plazo ya ha pasado

El calendario original de este artículo — inventario en marzo-abril, testing en paralelo en abril-mayo, migración definitiva en mayo-junio — ya no es aplicable: esas ventanas se cerraron. Si llegas a esta guía después del 30 de junio de 2026, el orden de prioridades cambia, porque ya no estás previniendo una caída, estás midiendo una que lleva meses en marcha.

El primer paso sigue siendo el inventario, pero con una vuelta de tuerca: los Scripts ya no se ejecutan, así que no puedes observar su comportamiento en vivo para documentarlo. Tienes que reconstruirlo desde tres fuentes: el informe de personalizaciones que Shopify puso a disposición de los comerciantes durante la transición, el histórico de pedidos anteriores a julio de 2026 (donde sí verás los descuentos y métodos de envío que se aplicaban) y, si existe, el control de versiones del equipo que escribió esos Scripts en Ruby.

El segundo paso es cuantificar el agujero. Compara los pedidos de un mes anterior a la retirada con los de un mes posterior y busca desviaciones en descuento medio por pedido, reparto de métodos de envío elegidos y reparto de pasarelas de pago. Si antes el 30% de los pedidos llevaba un descuento por volumen y ahora ninguno lo lleva, has encontrado la Function que falta. Este mismo cruce de datos es el que montamos en una auditoría técnica cuando una tienda nos llega con «algo raro en el margen».

El tercer paso es reconstruir, y aquí la recomendación original se mantiene intacta: la migración puede parecer sencilla para Scripts básicos, pero las lógicas complejas requieren tiempo de desarrollo y testing que no deberías comprimir. Con el plazo ya vencido la tentación es desplegar la Function directamente en producción para recuperar el descuento cuanto antes. No lo hagas: una Discount Function mal calculada no deja de aplicar un descuento, aplica el equivocado, y eso es peor que no tener ninguno.

Requisitos de plan: apps públicas, apps personalizadas y Shopify Plus

Hay un detalle de licenciamiento que condiciona toda la migración y que conviene tener claro antes de presupuestar nada: no todas las vías de acceso a Functions están abiertas en todos los planes.

Cualquier tienda, en cualquier plan, puede instalar desde la Shopify App Store una app pública que contenga Functions. Si tu lógica de descuentos es relativamente estándar — escalados por cantidad, packs, umbrales de envío gratuito — es muy probable que exista una app que ya la resuelva, y esa es la ruta más rápida y barata.

En cambio, las apps personalizadas que utilizan las APIs de Shopify Functions requieren plan Shopify Plus. Es decir: si tu lógica es lo bastante particular como para necesitar código propio, necesitas Plus. Esto deja a algunas tiendas en una posición incómoda: tenían Scripts (que históricamente también fue una característica de Plus), no están en Plus hoy, y descubren que su sustituto a medida tampoco está disponible. Las salidas realistas son adaptar la lógica para que encaje en una app pública, simplificarla hasta poder resolverla con las funciones nativas de descuentos de Shopify, o valorar el salto de plan. Lo analizamos en detalle en la comparativa de Shopify frente a Shopify Plus y cuándo merece la pena migrar.

Hay además capacidades concretas dentro del propio catálogo de Functions que siguen siendo exclusivas de Plus. Antes de prometer una funcionalidad a negocio, verifica en qué plan está disponible el tipo de Function que necesitas, no solo que el tipo exista.

Límites técnicos de Functions que condicionan el diseño

Functions no es «Scripts pero más rápido»: es un entorno de ejecución con un presupuesto medido, y ese presupuesto decide cómo tienes que escribir la lógica. Conviene conocerlo antes de diseñar, porque los límites no se notan en desarrollo con un carrito de tres líneas, se notan en producción con un carrito de ciento treinta.

La entrada que Shopify entrega a cada Function tiene un tamaño máximo de 128 kB (se amplió desde los 64 kB originales precisamente para dar margen a carritos con muchas líneas). Si tu consulta de entrada pide demasiados campos de demasiados objetos, puedes superar ese límite con un carrito grande y la Function falla. La disciplina aquí es pedir solo los campos que realmente usas: cada campo que añades a la consulta se paga en todos los carritos, no solo en los que lo necesitan.

Además hay un presupuesto de instrucciones por ejecución. Shopify permite escribir Functions en cualquier lenguaje que compile a WebAssembly, y ofrece plantillas y librerías para Rust y JavaScript o TypeScript, pero recomienda expresamente Rust como la opción más eficiente para evitar fallos con carritos grandes. En la práctica esto se traduce en una regla sencilla: para lógica sencilla y volúmenes normales, JavaScript o TypeScript es perfectamente razonable y el equipo lo mantiene sin fricción; para lógica con muchos bucles anidados sobre líneas de carrito, o para tiendas B2B con pedidos de cientos de referencias, Rust deja de ser una preferencia estética y pasa a ser un requisito.

El tercer límite es conceptual y es el que más sorpresas da: la Function no tiene red. No puede llamar a una API, ni leer una base de datos, ni consultar un microservicio. Decide con lo que tiene en la entrada. Todo dato externo que necesite — un tramo de precio negociado, un crédito de cliente, un stock de un almacén concreto — tiene que estar ya en Shopify en forma de metafield antes de que el cliente llegue al checkout.

El resto del calendario de Shopify que te afecta en 2026

La retirada de Scripts no viaja sola. Si estás revisando tu tienda por este motivo, merece la pena cerrar de una vez el resto de los frentes abiertos, porque todos tocan la misma zona del flujo de compra.

checkout.liquid y los additional scripts. Las páginas de Información, Envío y Pago dejaron de admitir checkout.liquid en agosto de 2024. Las páginas de Gracias y Estado del pedido se retiraron en agosto de 2025 para tiendas Plus, y el 26 de agosto de 2026 se aplicó lo mismo al resto de tiendas. Si todavía tenías píxeles de conversión o lógica de postventa en additional scripts, ya no se ejecutan: hay que rehacerlos como extensiones de checkout o mediante Web Pixels.

Cuentas de cliente clásicas. Quedaron oficialmente obsoletas el 26 de febrero de 2026: las tiendas nuevas ya no pueden usarlas y Shopify dejó de darles mantenimiento. La fecha de apagado definitivo no está anunciada, solo que llegará «más adelante en 2026». Si tu tienda sigue en cuentas clásicas, migrar a las nuevas cuentas de cliente es trabajo que conviene planificar ya y no esperar al anuncio.

B2B fuera de Plus. Desde el 2 de abril de 2026 las capacidades B2B fundamentales están disponibles también en los planes Basic, Grow y Advanced. No es una fecha límite, es una oportunidad: tiendas que descartaron el canal mayorista por el coste de Plus pueden replantearlo. Lo tratamos a fondo en el artículo sobre funcionalidades B2B enterprise de Shopify.

Si el inventario te lleva a la conclusión de que Shopify ya no encaja con lo que necesitas, también es un momento legítimo para evaluar alternativas: tenemos documentada la ruta de migración de Shopify a WooCommerce y una revisión de las novedades de Shopify en 2026 para que la decisión no se tome solo por el enfado del momento.

Preguntas frecuentes

¿Se puede recuperar el código de un Script que ya no se ejecuta?

Depende de cuándo lo intentes. La edición y publicación se cerraron el 15 de abril de 2026 y la ejecución el 30 de junio, pero eso no es lo mismo que la eliminación del registro. Lo prudente es no apostar a que el código siga siendo recuperable desde el panel: si tu equipo no tiene el Ruby en un repositorio, trata la lógica como perdida y recupérala desde el histórico de pedidos y la documentación funcional.

¿Puedo seguir sin migrar si mis Scripts eran poco importantes?

Puedes, pero conviene que sea una decisión consciente y no un olvido. Lo que no es defendible es no saber qué hacían. Un Script que «solo» ocultaba una pasarela de pago para pedidos por encima de cierto importe puede estar costándote comisiones todos los días desde julio.

¿Las Functions son más rápidas de verdad?

Sí, y la diferencia es real: WebAssembly se ejecuta cerca del rendimiento nativo frente al sandbox de Ruby interpretado. Pero «más rápido» no significa «imposible de romper»: una Function con un bucle cuadrático sobre las líneas del carrito agota el presupuesto de instrucciones y falla, mientras que una bien escrita no se nota. El rendimiento es consecuencia del diseño, no del cambio de tecnología.

¿Necesito Shopify Plus obligatoriamente?

Solo si necesitas una app personalizada con Functions propias. Si tu lógica cabe en una app pública de la App Store o en los descuentos nativos de Shopify, no necesitas Plus. La mayoría de las tiendas que creían necesitar código a medida descubren, al hacer el inventario con honestidad, que dos de sus tres Scripts eran estándar.

¿Qué pasa con las apps de terceros que yo tenía instaladas y usaban Scripts?

Es responsabilidad del desarrollador de la app haberlas migrado. Revisa el changelog de cada app crítica de tu checkout y, si alguna lleva sin actualizarse desde antes de 2026, asume que puede estar aportando menos de lo que crees. Esto forma parte del mantenimiento de módulos de ecommerce que casi nadie hace hasta que algo falla.

Conclusión

La retirada de Shopify Scripts es un buen ejemplo de un riesgo que no avisa cuando se materializa. No hubo caída, ni error 500, ni correo de alerta: simplemente, un día de julio de 2026 las reglas de negocio que alguien escribió en Ruby hace años dejaron de aplicarse y la tienda siguió vendiendo como si nada, un poco peor cada día.

Si ya migraste, el trabajo que queda es de disciplina: revisar que las Functions desplegadas siguen cubriendo los casos reales, vigilar el presupuesto de instrucciones a medida que crecen los carritos y cerrar los otros frentes del calendario de 2026. Si no migraste, el orden es inventario, cuantificación del impacto y reconstrucción — en ese orden, y sin saltarse el testing en paralelo por la prisa de recuperar el descuento.

Y hay una lección transversable a cualquier plataforma: la lógica de negocio crítica que vive en un rincón del panel de administración, sin repositorio, sin documentación y sin nadie que la vigile, es deuda técnica con fecha de caducidad. El mismo principio de control de cambios y revisión periódica que aplicamos en los controles técnicos de ISO 27001 para desarrollo seguro es el que habría convertido esta retirada en un ticket de mantenimiento rutinario en lugar de una sorpresa.

Cómo puede ayudarte Keliam

En Keliam desarrollamos y mantenemos apps privadas de Shopify, incluyendo la migración de Scripts a Functions. Si necesitas recuperar la lógica que se quedó en el camino, desarrollo de Functions personalizadas, mantenimiento de tu tienda Shopify o una revisión completa del checkout, contacta con nuestro equipo.