Shopify y Vercel están reconstruyendo Hydrogen como una base abierta y agnóstica al runtime. Hydroge…
Migración del frontend de commercetools paso a paso (guía 2026)
Una migración del frontend de commercetools no es una actualización de tema con extras. Es un proyecto en sí mismo, con fases, stakeholders, riesgos y un plan de transición claro. Quien conoce las fases evita los errores típicos y puede desplegar el proyecto de forma controlada incluso en pasos pequeños.
Esta guía presenta seis fases, cada una con sus objetivos, su duración habitual y sus trampas más frecuentes.
Fase 0: preparación antes de que el proyecto arranque oficialmente
Objetivo: tener claridad sobre el objetivo de negocio, los stakeholders, el presupuesto y el horizonte temporal. Duración habitual: de 1 a 2 semanas.
En esta fase se fija el «porqué»: velocidad de marketing, opcionalidad de backend, poner fin al lock-in de Frontastic, cumplimiento de la BFSG o una combinación de todo ello. Del porqué se deriva la priorización y, con ella, dónde se pone el foco del proyecto.
Identifique a dos stakeholders clave: un arquitecto técnico (idealmente con experiencia en el stack de ct) y un responsable de marketing o de marca. Sin este liderazgo dual, el proyecto acaba paralizándose en cualquier dirección.
Error frecuente: iniciar la migración porque «Composable está de moda». Sin un objetivo de negocio claro no hay éxitos medibles.
Fase 1: discovery y arquitectura
Objetivo: inventario técnico, decisión de arquitectura y selección de proveedor. Duración habitual: de 3 a 5 semanas.
Inventaríe su stack de ct actual: setup multiproyecto, stores activas, Customer Groups, Cart Discounts, Custom Objects, Custom Fields, configuración B2B. ¿Cuáles de estas estructuras necesita el frontend y cuáles se quedan en el backend?
Tome la decisión de frontend: ¿sigue con un desarrollo propio, cambia a Frontastic o apuesta por una FMP como Laioutr? Esta cuestión se resuelve en detalle en Frontastic vs. Laioutr.
Error frecuente: la lógica personalizada específica de ct se pasa por alto en la auditoría. Los Custom Objects que sostienen un configurador o los Custom Fields críticos para determinados flujos de trabajo deben documentarse desde el principio.
Fase 2: setup e integración
Objetivo: poner en marcha la plataforma de frontend, establecer la conexión con ct e integrar los sistemas de terceros. Duración habitual: de 2 a 4 semanas.
Con Laioutr configura Studio, conecta la API de commercetools (REST y GraphQL), configura los setups multiproyecto si los hay, engancha las integraciones de apps (reseñas, búsqueda, personalización) e integra sistemas de terceros a través de la App Store.
Error frecuente: las credenciales de la API de ct se definen de forma demasiado restrictiva o con muy pocos scopes. Ampliarlas después exige coordinación con el equipo de administración de ct. Es mejor planificar con generosidad desde el principio.
Fase 3: construcción de componentes y tema
Objetivo: construir la storefront real: página de producto, listado, home, landing pages y portales B2B si los hay. Duración habitual: de 4 a 10 semanas, según la profundidad del branding y la lógica personalizada.
Aquí se ve si su elección de plataforma cumple con el time to launch. Con la biblioteca de UI de Laioutr (más de 70 componentes) y un tema, no empieza desde cero. Los ajustes de marca, los componentes propios y la lógica específica de ct (solicitudes de presupuesto B2B, configuradores, flujos de aprobación) se construyen sobre esa base existente.
Error frecuente: el sistema de diseño y los componentes se desarrollan en paralelo a la storefront en lugar de antes. Eso genera trabajo duplicado y componentes inconsistentes.
Fase 4: migración de datos y transferencia de contenidos
Objetivo: trasladar de forma segura los contenidos existentes (blog, páginas estáticas, contenido SEO). Duración habitual: de 2 a 3 semanas.
En una migración desde Frontastic: se inventarían las páginas de Studio existentes, los componentes personalizados y las configuraciones de plugins, y se reconstruyen en Laioutr. En una migración desde un desarrollo propio: las plantillas, los contenidos estáticos y las entradas de blog se trasladan a Studio.
Error frecuente: olvidar las URL del blog y el contenido SEO. Entonces se pierde el tráfico orgánico acumulado durante años.
Fase 5: transición SEO y redirecciones
Objetivo: salvar los rankings existentes, conservar los backlinks y registrar limpiamente la nueva arquitectura en Google. Duración habitual: 1 semana, en paralelo a la fase 4.
Tres piezas tienen que encajar:
Primera: un mapa completo de redirecciones 301. Cada URL antigua recibe una nueva. Preste especial atención a las URL de categoría, los parámetros de filtro, la paginación y las URL multitienda (las ct Stores generan estructuras de URL propias por tienda).
Segunda: etiquetas hreflang y canonical impecables, sobre todo si opera en varios mercados con ct Stores.
Tercera: volver a implementar el marcado de Schema.org: Organization, Product, BreadcrumbList, FAQPage. Los datos estructurados son un factor de posicionamiento directo.
Error frecuente: olvidar el sitemap.xml antiguo, con lo que Google indexa durante días una mezcla de URL antiguas y nuevas. Es mejor desindexar de forma controlada y volver a enviar el sitemap.
Fase 6: go live, monitorización e iteración
Objetivo: salir a producción y asegurarse de que nada se rompe. Duración habitual: go live en un día laborable, estabilización de 2 a 3 semanas.
No salga a producción un viernes. Hágalo un martes o un miércoles, con ingeniería, marketing y atención al cliente presentes. Durante las primeras 72 horas vigile especialmente: tasa de conversión, tasa de rebote, Core Web Vitals, latencias de la API de ct y anomalías en Search Console.
Error frecuente: salir a producción sin plan de rollback. Si algo importante falla, debe poder volver atrás en 30 minutos. Es decir: el stack de frontend antiguo tiene que poder reactivarse en caso de emergencia.
Cronograma total habitual
Para un proyecto de ct de tamaño medio, con un branding claro y sin lógica personalizada exótica: de 10 a 18 semanas desde el kickoff hasta el go live. Con un setup multimarca, funcionalidad B2B o integraciones ERP amplias, el plazo aumenta en consecuencia.
Qué partners pueden apoyarle
Migrar por cuenta propia es posible, pero rara vez es el camino más rápido. En Alemania, para proyectos de frontend de commercetools con Laioutr han dado especialmente buen resultado: valantic para setups Composable de nivel enterprise y migraciones desde Frontastic. Encontrará la lista completa en el apartado Partners.
Conclusión: migrar es trabajo de arquitectura
Una migración de frontend a commercetools rara vez fracasa por la tecnología. Fracasa por objetivos poco claros, por la falta de un responsable de arquitectura o por una fase SEO que se aborda demasiado tarde. Quien recorre las seis fases con rigor consigue una transición controlada, no un proyecto de riesgo.
Si está planificando una migración concreta, realizamos con usted una auditoría honesta, con un plan de fases concreto y un calendario realista para su setup.
Recursos adicionales: Composable Headless Frontend, Headless Frontend para commercetools y Content Management.