iPhone Duo goes on sale on October 23, 2026. Online stores don't need a dedicated app or a custo…
Fin de vida de Shopify Scripts el 30 de junio: guía para marcas Plus
El 30 de junio de 2026, Shopify Scripts deja de funcionar. Si eres una marca Plus que ajusta la lógica de pagos, envíos o líneas de pedido mediante Scripts, después de esa fecha tus Scripts activos desaparecerán. La edición ya se detuvo el 15 de abril. Esto ya no se mide en semanas, sino en días. Este artículo explica por qué la migración forzosa a Functions es el momento adecuado para desenredar toda tu arquitectura de personalización de una vez, en lugar de limitarte a cambiar un Script por una Function.
Qué ocurre el 30 de junio
Shopify ha marcado la baja con claridad. Desde el 15 de abril de 2026, los Scripts ya no se pueden editar ni publicar. Los Scripts existentes siguen ejecutándose hasta el 30 de junio de 2026, fecha a partir de la cual dejan de funcionar (shopify.dev/changelog). El plazo, fijado originalmente para agosto de 2025, se aplazó una vez a junio de 2026. Shopify ha sido explícito: no se volverá a mover.
Afecta a toda marca Plus con Scripts activos en el Script Editor: lógica de descuentos, reglas de envío, ordenación de métodos de pago, precios de bundles. El sucesor oficial es Shopify Functions junto con Checkout Extensibility. La migración es obligatoria, no opcional.
Por qué la mayoría de los equipos acota demasiado el alcance de la migración
La respuesta obvia es una migración uno a uno: cada Script se convierte en una Function y todo lo demás se queda igual. Eso cumple con el plazo, pero deja intacta la pregunta de fondo.
La mayoría de las marcas Plus han acumulado con los años una maraña de personalización compuesta por tres capas que ya nadie supervisa por completo:
- Ajustes del theme en Liquid para la presentación y la lógica de página
- Scripts para las reglas de checkout (las que ahora desaparecen)
- Apps de checkout y app blocks para todo lo que el theme y los Scripts no podían hacer
Estas tres capas se entrelazan, a menudo con lógica duplicada. Una regla de envío vive mitad en un Script, mitad en una app. Un mecanismo de descuento está hardcodeado en Liquid aunque exista un Script para ello. La migración a Functions te obliga a tocar al menos una de estas capas. Ese es el momento de ordenar también las otras dos, en lugar de arrastrar la maraña a la siguiente generación.
El verdadero cuello de botella es el frontend
Aquí está el punto que la mayoría de las guías de migración pasan por alto. Shopify Functions resuelve limpiamente el backend de checkout. No resuelve la razón por la que las marcas Plus viven su frontend como un freno.
El frontend de una tienda Shopify Plus ya madura existe en dos estados prácticos, ambos con lock-in:
- Liquid theme: una pila de page builder remendada con app blocks y código a medida. El rendimiento depende del mantenimiento del theme y de las apps, marketing espera las revisiones de PR del theme, y la accesibilidad queda fragmentada.
- Hydrogen más Oxygen: una pila moderna en React, pero el frontend tiene que estar completamente desacoplado. Oxygen impone un presupuesto de 50 ms de CPU por worker, sin WebSockets, y un CI/CD limitado a GitHub. El checkout sigue pasando por las comisiones de pago de Shopify.
Ambos caminos te atan a una infraestructura de frontend específica de Shopify. Si ahora solo migras los Scripts a Functions y aplazas la cuestión del frontend, cierras una obra y dejas abierta la más grande.
La tercera opción: Functions en el backend, el frontend como capa propia
Existe un camino que resuelve ambos problemas de una sola vez. Migras la lógica de checkout a Shopify Functions, que es donde debe estar, y al mismo tiempo desacoplas el frontend en su propia capa de gestión. Shopify sigue siendo el backend y el motor de comercio, la Storefront API (GraphQL) entrega los datos. El frontend se vuelve intercambiable.
Esta es la tesis central de la Frontend Management Platform: la capa donde las tiendas se componen, localizan y entregan no pertenece dentro de cada backend, sino a un nivel propio por encima del backend. En el caso concreto de Shopify:
- Laioutr se conecta a la Shopify Storefront API. Integración estándar, sin código de conexión a medida.
- Las reglas de checkout que de todos modos estás migrando a Functions se quedan en Shopify. Functions es el lugar correcto para ellas.
- El frontend se ejecuta como un Composable Headless Frontend sobre una base de código Nuxt, no como un theme de Liquid ni como Hydrogen sobre Oxygen.
- Multi-brand y multi-locale se ejecutan sobre una sola base de código, en lugar de n tiendas Shopify paralelas con licencias de apps duplicadas.
El punto decisivo: la migración a Functions y el desacople del frontend no chocan entre sí. Se complementan. Functions es la respuesta correcta para el backend de checkout, y un frontend desacoplado es la respuesta correcta para el cuello de botella de marketing y rendimiento.
La migración como inventario de arquitectura: 4 pasos
Si de todos modos tienes que afrontar el plazo, aprovéchalo como un inventario estructurado en lugar de una migración de emergencia.
1. Mapea las capas de personalización
Enumera qué vive hoy dónde: qué lógica está en el theme de Liquid, cuál en Scripts, cuál en apps de checkout. Marca la lógica duplicada y las rutas muertas. Este mapa es el requisito previo para cualquier decisión limpia.
2. Traslada la lógica de checkout a Functions
La lógica de pagos, envíos y descuentos pertenece a Shopify Functions. Esta es la parte obligatoria con plazo. Mantén las Functions ligeras y bien documentadas en lugar de arrastrar la vieja complejidad de los Scripts uno a uno.
3. Separa la lógica de frontend del checkout
Todo lo que tiene que ver con la presentación, la composición de páginas, la personalización y el contenido de marketing no pertenece a Functions ni a una maraña de app blocks. Eso es responsabilidad del frontend. Aquí se decide si sigues atado a Liquid o a Hydrogen, o si desacoplas la capa.
4. Evalúa el camino del desacople
Comprueba si una capa de frontend dedicada por encima de la Storefront API es viable para ti. La pregunta no es académica: decide si tu próxima discusión de replatforming en 24 meses se convierte en un proyecto greenfield de 18 meses o en un refactor de frontend con el backend en marcha.
Qué ganas
Dimensión | Migración uno a uno a Functions | Functions más desacople del frontend |
|---|---|---|
Reglas de checkout | limpias en Functions, plazo cumplido | limpias en Functions, plazo cumplido |
Cuello de botella del frontend | se mantiene (lock-in de Liquid o Hydrogen) | resuelto, capa Nuxt sobre la Storefront API |
Time-to-market de landing pages | revisión de PR del theme, de días a semanas | editor de Studio con vista previa en vivo, horas |
Multi-brand | n tiendas, n licencias de apps | una base de código, n themes de marca |
Hosting en la UE | proveedor en EE. UU., con la reserva de Schrems II | región de la UE seleccionable en la capa de frontend |
Preguntas frecuentes
¿Tengo que desacoplar el frontend antes del 30 de junio?
No. El plazo estricto solo afecta a los Scripts. Functions es la parte obligatoria. El desacople del frontend es la opción estratégica que el inventario te abre, no algo que haya que forzar bajo presión de tiempo. Pero el mapa de personalización ya está sobre la mesa de todos modos.
¿Pierdo Shopify como backend si desacoplo el frontend?
No. Shopify sigue siendo el motor de comercio y el backend de checkout. Las Functions que estás migrando ahora siguen ejecutándose en Shopify. Solo se desacopla la capa de frontend por encima de la Storefront API.
¿Qué pasa con mi checkout de Shopify?
Se queda. El checkout de Shopify sigue funcionando por defecto, incluidas las Functions migradas. Un checkout headless es opcional para flujos B2B o de varios pasos, no un requisito previo.
Próximos pasos
Si de todos modos estás afrontando el plazo de Functions y quieres ver cómo se ve en la práctica una capa de frontend desacoplada sobre tu Shopify Storefront API: reserva una demo. Te mostramos en una configuración real cómo el backend se queda con Shopify y el frontend vuelve a tus manos.
Más sobre la plataforma Laioutr
Lecturas relacionadas: Calendario de fin de vida de Magento 2.4.x: versiones y fechas y Fin de vida de SAP Accelerator: migrar a un frontend Composable sin hacer replatforming del backend.