Shopware 6.7 salió a finales de 2024 con lo que la documentación oficial califica de «major release with multiple breaking changes». Para las tiendas en 6.6, la migración es obligatoria a término — Shopware solo mantiene en paralelo la última versión estable y la versión anterior, por lo que quedarse en 6.5 o 6.6 demasiado tiempo corta el acceso a los parches de seguridad. Para los plugins desarrollados en 6.6, varias API críticas han cambiado de signatura o han sido suprimidas entre 6.6 y 6.7.
Este artículo es un retorno de experiencia directo sobre la migración 6.6 → 6.7 que hemos llevado a cabo en varias tiendas en 2025-2026, con las verdaderas trampas técnicas que hemos encontrado y los parches que hemos tenido que producir para adaptar nuestros propios plugins y los de terceros. El objetivo: evitar a otros equipos el mes de debugging que hemos pasado en ciertas regresiones silenciosas.
Lo que cambia realmente en Shopware 6.7
Más allá del marketing de release, aquí los cambios 6.7 con impacto concreto en los plugins existentes.
Refundición de la API Payment Handler. La interfaz AsynchronousPaymentHandlerInterface se suprime en 6.7. Todo plugin de pago que implementaba esta interfaz en 6.6 debe migrar hacia AbstractPaymentHandler. Los métodos pay() y finalize() tienen una signatura diferente: la struct AsyncPaymentTransactionStruct es reemplazada por PaymentTransactionStruct, más minimalista y orientada DDD.
Tags de servicio modificados. El tag shopware.payment.method.async que distinguía los pagos síncronos y asíncronos se suprime en favor de un tag unificado shopware.payment.method. Si tus services.xml usaban el antiguo tag, el payment handler ya no se declara correctamente y el modo de pago desaparece del checkout sin error visible.
Migración admin Vue 2 → Vue 3. El admin Shopware 6.7 está portado en Vue 3 (mientras que 6.6 estaba en Vue 2 con compat layer). Los componentes sw-* (legacy) están siendo reemplazados por los componentes mt-* (Meteor design system). Muchos componentes sw-* están marcados como deprecated y serán suprimidos en una release 6.x ulterior. Los plugins admin que usaban los componentes sw-* deben migrar.
Sistema de traducción admin modificado. Los métodos $tc() (translation choice, gestión del plural) han sido reemplazados por $t() con gestión nativa del plural. Tus templates admin que hacían {{ $tc('mi.plugin.label') }} deben pasar a {{ $t('mi.plugin.label') }}.
Build admin vía Vite. El admin compila ahora vía Vite con un manifest.json estructurado de manera diferente al de 6.6. Los plugins que inyectaban su JS admin vía el mecanismo histórico deben adaptar su build pipeline para generar el buen manifest, sino el admin carga un JS vacío en lugar de tu código.
Storefront: Bootstrap 5.3 generalizado. El paso a Bootstrap 5.3 en el storefront activa el soporte nativo de data-bs-theme, lo que simplifica las implementaciones de modo oscuro — tema de nuestro plugin DataFirefly Dark Mode que explota esta convención. Los temas custom basados en Bootstrap 5.2 o anterior pueden tener variables SCSS que ya no mapean.
Compatibilidad PHP y MySQL. 6.7 exige PHP 8.2+ (PHP 8.1 salido de EOL, PHP 8.3 recomendado) y MySQL 8.0+ o MariaDB 11.4 LTS. Los hostings todavía en MySQL 5.7 o MariaDB 10.x deben migrar su DB antes del upgrade aplicativo.
Los breaking changes plugin por plugin que hemos encontrado
En las tiendas que hemos migrado, aquí los bugs concretos descubiertos al upgrade 6.6 → 6.7.
MoptWorldline (pago Worldline / SaferPay). El plugin de pago Worldline en versión 6.6 implementaba AsynchronousPaymentHandlerInterface. Al paso a 6.7, el plugin ya no carga correctamente, y los métodos de pago Worldline desaparecen del checkout. El parche exige migrar hacia AbstractPaymentHandler y reescribir los métodos pay() y finalize() con la nueva signatura PaymentTransactionStruct. Trabajo estimado: 2-4 días para un dev Shopware experimentado.
Plugins admin custom con componentes sw-*. En nuestros plugins MySmartBook y otros, varios componentes admin custom usaban sw-card, sw-button, sw-text-field, etc. En 6.7, estos componentes existen todavía pero están marcados como deprecated. Los componentes mt-card, mt-button, mt-text-field los reemplazan. La migración es mecánica pero exige una revisión exhaustiva de todos los archivos admin.
Snippets y traducciones. Los archivos de snippets en 6.6 usaban a veces la estructura pluralizada que $tc() consumía. En 6.7 con $t(), ciertas estructuras de snippets ya no funcionan de manera idéntica. A probar sistemáticamente, sobre todo en los snippets con contadores («1 producto» / «N productos»).
Custom field customer y sincronización. Nuestro plugin Dark Mode para Shopware almacena la preferencia usuario en un custom field df_dark_mode_preference en la entidad customer. La migración 6.7 ha conservado la compatibilidad custom fields, pero la API de sincronización tiene una signatura ligeramente diferente. A probar sistemáticamente tras el upgrade.
OpenSearch 2.19+ obligatorio. Si tu tienda usa la búsqueda fulltext con OpenSearch (antes Elasticsearch en las versiones Shopware anteriores), 6.7 exige OpenSearch 2.19 mínimo. Las versiones OpenSearch 1.x ya no están soportadas. Migración cluster OpenSearch a prever antes del upgrade aplicativo.
El checklist de migración en 8 etapas
Para una migración 6.6 → 6.7 dominada, aquí el orden que seguimos internamente.
Etapa 1 — Auditoría de los plugins instalados. Lista todos los plugins activados en tu tienda. Para cada uno, verifica en el store o en GitHub si existe una versión compatible 6.7. Los plugins no actualizados son riesgos mayores: a desactivar temporalmente, o a parchar internamente, o a reemplazar.
Etapa 2 — Auditoría del tema custom. Si usas un tema custom (y no el tema Storefront nativo), verifica la compatibilidad con Bootstrap 5.3, los cambios de estructura base layout, y el sistema Vite admin si tu tema inyecta JS admin custom.
Etapa 3 — Actualización entorno infraestructura. PHP 8.2+, MySQL 8 o MariaDB 11.4 LTS, OpenSearch 2.19+ si se usa, Node.js reciente (18+ o 20 LTS). A hacer antes del upgrade aplicativo Shopware.
Etapa 4 — Backup completo. Base de datos + carpeta files + archivos config/. Es la etapa que tendemos a descuidar hasta el momento en que el upgrade rompe irremediablemente algo. A hacer sistemáticamente antes de todo cambio.
Etapa 5 — Migración en entorno de staging. Clonar la prod en un staging idéntico, hacer el upgrade 6.7 en el staging, validar exhaustivamente antes de tocar la prod. No es una opción — en las tiendas que hemos migrado, el 30 % han tenido bugs críticos descubiertos únicamente en staging.
Etapa 6 — Upgrade aplicativo Shopware. Vía el SUM (Shopware Update Manager) en CLI: bin/console system:update:prepare, luego bin/console system:update:finish. Leer bien la documentación oficial para las opciones (skip-asset-build, etc.). Contar 30 min a 2 h según el tamaño de la base.
Etapa 7 — Recompilación tema y admin. Tras el upgrade core, recompilar el tema (bin/console theme:compile) y rebuild el admin (bin/build-administration.sh). En Shopware 6.7, el admin se compila vía Vite; el comando histórico theme:compile ya no basta para el admin.
Etapa 8 — Test exhaustivo post-upgrade. Recorrido completo: navegación catálogo, ficha producto, añadir al carrito, checkout, pago (cada método de pago probado individualmente), espacio cliente, admin (cada módulo instalado). En las tiendas B2B, probar también presupuestos, cuentas jerárquicas, precios por cliente.
Las trampas silenciosas que hemos encontrado en la realidad
Más allá de los breaking changes documentados, aquí los bugs sutiles que no se ven inmediatamente tras el upgrade.
El payment handler que ya no se declara. Como mencionado más arriba, un plugin de pago con antiguo tag shopware.payment.method.async ya no se registra en 6.7. El modo de pago desaparece del checkout, pero ningún error se levanta — el payment_method_id correspondiente existe todavía en base, simplemente el handler ya no se instancia. Síntoma lado cliente: el método se muestra en el admin (configuración / sales channels / payment methods) pero no aparece al checkout.
El componente admin custom que renderiza vacío. Un componente que usaba $tc() sin ninguna traducción asociada (caso de los labels hardcodeados) ya no renderiza nada en 6.7. Sin error en la consola, simplemente un placeholder vacío. A detectar por revisión manual de las pantallas admin custom tras el upgrade.
El manifest Vite que no se genera. Si tu plugin admin custom era buildeado con un script personalizado en 6.6 (webpack o rollup directo), este build puede no generar el manifest.json esperado por Shopware 6.7. Síntoma: el admin carga pero tu JS plugin no se ejecuta. Solución: adaptar el build para exportar un manifest compatible Vite.
Los snippets pluralizados que ya no se traducen. Si tenías snippets con estructura {count} | una cosa | {count} cosas consumidos por $tc(), el paso a $t() exige una sintaxis diferente. Los snippets no migrados muestran la cadena template bruta en lugar de la traducción.
El custom field que ya no existe en API. Algunas modificaciones de la API DAL (Data Abstraction Layer) en 6.7 han cambiado la serialización de ciertos custom fields complejos (multi-select, JSON). Los valores en base existen todavía, pero se leen de manera diferente. A probar en los custom fields críticos.
Conclusión: una migración necesaria pero a anticipar
La migración Shopware 6.6 → 6.7 no es una simple update menor. Introduce breaking changes significativos que exigen un trabajo real en los plugins (pago notablemente), el admin custom, y la infraestructura. Las tiendas que hacen esta migración en 1 día «porque acabamos de clicar en Update» descubren los bugs en producción semanas más tarde, a veces con impacto directo en el CA (pago roto, admin inutilizable).
La inversión tiempo realista para una tienda con 5-10 plugins de terceros y un tema custom es de 5 a 15 días-hombre para un desarrollador Shopware experimentado, más algunos días de recepción. Anticipar el tema, hacer el upgrade en staging, probar exhaustivamente antes de la prod, es lo que distingue una migración dominada de una migración en crisis.
Para los temas técnicos conexos, recorre nuestras categorías Actualidad e-commerce y Performance & Core Web Vitals. Y si buscas plugins Shopware 6.7 franceses, performance-first y bien mantenidos, nuestro plugin Dark Mode es compatible Shopware 6.7 desde la salida e ilustra los patterns técnicos alineados con la nueva arquitectura (anti-FOUC, custom field customer, eventos JS para sincronización terciaria).