Migración de SFRA a PWA Kit sin frenar las ventas

Migrar de SFRA a PWA Kit no es una decisión binaria que se resuelve en un solo sprint de planificación. Es una transición que, mal gestionada, pone en riesgo la facturación, el SEO y la salud del equipo. La razón es simple: la tienda no puede dejar de vender mientras la arquitectura cambia por debajo. La respuesta práctica no es "todo de golpe". Es coexistencia controlada entre el monolito y el headless durante un periodo definido, con criterios de salida claros.

Este artículo no trata PWA Kit como sinónimo automático de mejor rendimiento. Lo trata como un cambio de arquitectura con un costo real: mantenimiento duplicado, complejidad de enrutamiento y riesgo de SEO. Ese costo solo se justifica cuando la ganancia en rendimiento y velocidad de entrega supera el esfuerzo. El objetivo aquí es darle al Tech Lead argumentos y un plan para defender la decisión correcta con datos, no con entusiasmo por lo headless.

¿Por qué la migración "big bang" casi siempre fracasa?

Reemplazar SFRA por PWA Kit de una sola vez significa reescribir PDP, PLP, carrito, checkout, búsqueda y cuentas de cliente. También significa migrar cada integración: ERP, OMS, pagos y envíos. Todo tiene que estar listo para producción antes de que salga algo a producción. En la práctica, esto congela el roadmap de negocio durante meses. Para un Tech Lead sin autoridad para hacer crecer el equipo, un roadmap congelado significa deuda técnica acumulándose en paralelo, mientras nadie entrega ninguna funcionalidad nueva.

El riesgo no es solo el plazo. Es la regresión: un checkout nuevo, probado únicamente en staging, sale a producción de golpe. Cualquier bug de caso límite (lógica de cupones, pago dividido, envío internacional) se convierte en un incidente de producción sin ruta de rollback. Este tipo de exposición, muy asociado a picos de tráfico mal previstos, es exactamente lo que analizamos en nuestro artículo sobre límites de plataforma SFCC. La migración incremental existe precisamente para eliminar esta apuesta de todo o nada.

Aplicar el patrón strangler a SFCC

El patrón strangler funciona estrangulando el monolito pieza por pieza: reemplaza funcionalidad una unidad a la vez hasta que el sistema viejo queda redundante. Es la estrategia más defendible para migrar de SFRA a PWA Kit porque permite:

• Validar PWA Kit en producción con tráfico real antes de migrar una página crítica (el checkout, por ejemplo);

• Revertir una ruta específica a SFRA sin revertir todo el proyecto;

• Distribuir el esfuerzo del equipo a lo largo de meses en vez de concentrar el riesgo en una sola ventana de go-live.

En la práctica, esto significa que SFRA sigue sirviendo parte del catálogo mientras PWA Kit se hace cargo de otra parte. Ambos stacks corren en simultáneo durante un tiempo. Aquí es donde la mayoría de las guías de migración se quedan cortas: describen la arquitectura final pero se saltan el estado intermedio. Ese estado intermedio es exactamente donde vive el Tech Lead en el día a día.

Guías técnicas de la comunidad SFCC, como la Realm Split Guide for Migrating an SFCC Site (Rhino Inquisitor), documentan un razonamiento equivalente para migraciones de realm. La idea central es separar lo que cambia de lo que permanece estable, tratando la transición como un proyecto de arquitectura con fases nombradas en lugar de un corte único. El mismo principio aplica a migrar el renderizado (SFRA) a headless (PWA Kit): la unidad de migración no es "el sitio", es la ruta.

Enrutamiento basado en rutas: la pieza que hace posible la coexistencia

El mecanismo que habilita el patrón strangler aquí es el enrutamiento basado en rutas (o en patrones de URL) en la capa de edge/CDN. Este decide, por cada request, si la respuesta viene de SFRA o de PWA Kit.

Enrutamiento por path. /product/ y /category/ van a PWA Kit apenas estén listas; /checkout/ y /my-account/ se quedan en SFRA hasta que se migren. Es simple de implementar, pero exige disciplina para evitar URLs "huérfanas", rutas que existen en ambos sistemas con respuestas divergentes.

Enrutamiento por feature flag o header. Útil para un rollout gradual dentro de la misma ruta (por ejemplo, el 10% del tráfico de la PLP va a PWA Kit). Esto permite comparar rendimiento y tasa de conversión lado a lado antes del corte final.

Enrutamiento por dominio o subcarpeta temporal. Menos elegante para el usuario final, pero reduce la complejidad de configuración de CDN al inicio del proyecto. Es útil cuando el equipo es pequeño y necesita priorizar velocidad de entrega sobre elegancia arquitectónica.

El trade-off aquí es directo: cuanto más granular el enrutamiento, más control tienes sobre el riesgo. A cambio, crece la complejidad de configuración, junto con la superficie de bugs de enrutamiento. Es un problema silencioso que no aparece en pruebas funcionales, solo en producción bajo carga.

Esto no es solo teoría de arquitectura. En un proyecto internacional para un retailer de salud y belleza en Reino Unido e Irlanda, ejecutamos una migración siguiendo exactamente este razonamiento. Primero migramos el CMS a Amplience, construyendo los componentes y las páginas de contenido. Luego configuramos la capa de firewall/edge del dominio para enrutar esas páginas de contenido específicamente a PWA Kit, mientras el resto de la navegación seguía siendo servido por el sitio legacy.

Las rutas restantes fueron absorbidas por PWA Kit en secuencia, en fases técnicamente controladas. Cada fase se validaba en producción antes de habilitar el siguiente corte de tráfico. La ganancia práctica de esta fase por fase no fue solo técnica. Le dio al equipo de negocio visibilidad real del avance, sin necesidad de un único go-live de alto riesgo.

Sesión y autenticación: donde falla la coexistencia

Uno de los errores más comunes en migraciones incrementales es subestimar la sincronización de sesión entre SFRA y PWA Kit. SFRA usa sesiones tradicionales del lado del servidor; PWA Kit consume SLAS (Shopper Login and API Access Service) vía token. Si un comprador navega entre una ruta de SFRA y una de PWA Kit dentro del mismo carrito, nunca debería percibir el cambio de sistema. El carrito, el login y las preferencias tienen que persistir.

Este es exactamente el tipo de problema técnico que aborda la documentación de la comunidad sobre SLAS Session Sync in SFRA and SiteGenesis (Rhino Inquisitor). El foco ahí es mantener tokens y sesiones coherentes entre el mundo de sesión de servidor y el mundo de tokens headless. Ignorar esto durante la planificación es la causa más común de "logout fantasma" y carritos perdidos durante los periodos de coexistencia. Es también el tipo de bug que erosiona la confianza del negocio en la migración, incluso cuando la arquitectura en sí es correcta.

La migración de tokens en general merece un escrutinio propio en este tipo de transición. Cubrimos un caso relacionado en profundidad en nuestro artículo sobre migración de token UUID a JWT en Salesforce Commerce Cloud, que recorre los riesgos operativos de cambiar cómo se representa la identidad en una tienda SFCC, un problema que rima muy de cerca con lo que ocurre durante el traspaso de sesión de SFRA a PWA Kit.

La sesión y la autenticación no son la única pieza de estado que necesita sobrevivir al cambio de stack. El contexto del comprador (geolocalización, moneda, segmentación de audiencia) también tiene que persistir cuando una ruta migra de SFRA a PWA Kit. Esta es la pieza que PWA Kit consume vía el Commerce SDK para mantener la personalización consistente entre ambos stacks durante la coexistencia, sin depender de la sesión del servidor.

SEO durante la transición: lo que no puede romperse

El SEO es el activo más frágil en una migración de renderizado, porque Google reindexa con retraso y penaliza la inconsistencia. Puntos no negociables:

• Redirects 301 antes del corte de tráfico, no después. Si la estructura de URL cambia entre SFRA y PWA Kit, el redirect tiene que existir en el momento en que la ruta vieja deja de responder. Nunca después.

• Canonical tags y meta tags consistentes entre ambos stacks durante la coexistencia. Si SFRA y PWA Kit generan pares de título y descripción distintos para la misma entidad de producto, en fases diferentes del rollout, eso es un problema. Google lo trata como contenido inestable, lo que afecta el ranking. Las reglas de meta tags de SFCC tienen matices documentados (Rhino Inquisitor, Deep Dive into SFCC Meta Tag Rules) que vale la pena revisar antes de replicar ese comportamiento en PWA Kit.

• Un único sitemap actualizado, que refleje qué sistema sirve cada URL en cada momento. No dos sitemaps compitiendo entre sí.

• Core Web Vitals monitoreados por ruta, no solo de forma global. Es común que PWA Kit mejore el LCP de la PLP mientras empeora el CLS de la PDP por una hidratación mal ajustada. La métrica agregada esconde esto.

El error más costoso aquí no es técnico, es de secuencia. Es migrar una ruta antes de validar que el SEO técnico del nuevo stack está al mismo nivel, o mejor, que el del monolito. Perder ranking en una categoría de alto tráfico durante la transición cuesta más en facturación que cualquier ganancia de rendimiento a mediano plazo.

El costo real del mantenimiento duplicado

Durante la coexistencia, el equipo mantiene dos stacks. Bugs de catálogo, promociones e integraciones necesitan corregirse en ambos lugares hasta que se complete la migración de la ruta correspondiente. Para un Tech Lead sin autoridad para aumentar el headcount, este es el trade-off más concreto de todo el proyecto.

Formas de mitigarlo sin fingir que el costo no existe:

• Priorizar la migración por impacto de mantenimiento, no solo por valor de negocio. Migrar primero las rutas que generan más tickets de soporte o hotfixes en el monolito reduce más rápido el costo duplicado.

• Congelar el desarrollo de nuevas funcionalidades en SFRA para rutas que ya están parcialmente enrutadas a PWA Kit, evitando que el equipo construya la misma regla de negocio dos veces.

• Fijar una fecha de apagado por fase, no una única fecha de "fin de proyecto". Cada ruta migrada debería tener una fecha de decomisión para el código SFRA correspondiente. Sin esto, el "mantenimiento temporal" se vuelve permanente.

Cómo decidir el orden de migración

El orden correcto suele seguir el riesgo decreciente, no el valor de negocio decreciente:

1. PLP y páginas de contenido: menor complejidad de estado, mayor ganancia percibida de rendimiento. Buenas para validar el stack de PWA Kit en producción con riesgo controlado.

2. PDP: más compleja (variantes, disponibilidad, personalización), pero todavía sin transacción financiera involucrada.

3. Carrito y cuenta de cliente: requiere la sincronización de sesión descrita antes.

4. Checkout: se migra al final, y solo después de que las integraciones de SLAS, sesión y pagos se hayan validado en producción en fases anteriores.

Migrar el checkout primero, porque es la página más discutida en las conversaciones sobre headless, es el error clásico. Quien hace esto está optimizando para la demo, no para el riesgo operativo.

Conclusión

Migrar de SFRA a PWA Kit es una decisión de arquitectura con trade-offs reales: rendimiento contra plazo, ganancia de experiencia contra costo de mantenimiento duplicado, velocidad de rollout contra riesgo de SEO. El patrón strangler con enrutamiento basado en rutas, una sincronización de sesión bien planificada y disciplina de SEO durante la transición no eliminan ese costo. Pero lo hacen visible, secuenciado y reversible. Eso es exactamente lo que separa una migración defendible de una apuesta.

Si tu equipo está evaluando este tipo de migración y necesita validar la estrategia antes de comprometer el roadmap, vale la pena hablar con un equipo que ya ejecutó esta transición exacta en producción, con tráfico real, sin congelar la entrega. Agenda una conversación con Develoci para discutir el plan de fases que se ajusta a tu contexto.