Dibuja el customer journey de automoción y casi siempre obtienes la misma diapositiva: descubrimient…
¿Big bang o progresiva? Por qué tu estrategia de migración decide tu riesgo de temporada
Toda migración de frontend tiene una fecha de cutover en mente. La única pregunta es si hay una o muchas. Un cutover big bang pone el nuevo storefront en producción en un momento fijo y apaga el antiguo. Un enfoque progresivo va moviendo page types o rutas uno tras otro. Ambos llegan al mismo destino, pero reparten el riesgo de formas completamente distintas, y ese reparto decide lo peligrosa que resulta una migración cerca de la temporada alta. Este artículo muestra por qué la estrategia es una decisión de dirección, no solo técnica.
Qué arriesga de verdad un cutover big bang
En un big bang todo el riesgo de la migración se acumula en un único momento. Todo tiene que funcionar a la vez: routing, checkout, tracking, señales SEO, caching, redirecciones. Si algo falla, afecta a la tienda entera, no a un page type. El rollback es binario, se vuelve al sistema antiguo o no. No hay un estado intermedio en el que ajustar de forma controlada.
El problema rara vez es solo la tecnología. Es la simultaneidad. Un bug en el renderizado de la página de producto, un conjunto hreflang roto, una regresión en Core Web Vitals: por separado, cada uno sería manejable. El día del cutover llegan juntos y con todo el tráfico en producción, y el diagnóstico se hace bajo la máxima presión.
Por qué la temporada agudiza el riesgo
El calendario convierte un riesgo manejable en uno existencial. Si el cutover cae en las semanas previas al Q4 o directamente en la fase promocional, cualquier caída se encuentra con el tráfico más rentable del año. El coste de un mal día escala con el volumen de ese día.
Luego está el freeze. Muchas organizaciones congelan deliberadamente todos los cambios en el storefront entre noviembre y enero. Un plan big bang que se retrase aunque sea un poco choca con esa ventana. O fuerzas la fecha, o retrasas toda la migración medio año. Las dos opciones son caras.
El camino progresivo: strangler, no una fecha única
El enfoque progresivo sigue el patrón strangler: el nuevo storefront va tomando el relevo ruta por ruta mientras el antiguo sigue sirviendo el resto. En lugar de una gran apuesta hay muchas pequeñas, cada una con un radio de impacto limitado. Si la migración empieza por un page type de contenido con tráfico moderado, un error ahí es molesto pero no crítico para el negocio. El equipo aprende con tráfico real sin poner en peligro el checkout.
La diferencia decisiva es que puedes pausar. Si una ruta migrada muestra una regresión, paras, la corriges y sigues, sin revertir la tienda completa. El riesgo no ha desaparecido, pero está partido en trozos digeribles.
Cómo un layer de frontend desacoplado hace posible la migración progresiva
Para que "algunas rutas nuevas, otras antiguas" sea más que una intención, hace falta un layer que reparta el tráfico de forma deliberada. Eso es exactamente lo que aporta una Frontend Management Platform (FMP): un layer composable frontend desacoplado por encima de tu backend, que decide ruta por ruta si renderiza el nuevo storefront o el existente.
En la práctica, un layer de routing reparte las peticiones según el patrón de ruta. /magazine/* ya pasa por el nuevo frontend, /product/* todavía por la tienda antigua. Para usuarios y motores de búsqueda sigue siendo un solo dominio, una experiencia coherente. Como layer operado, frontend as a service, este nivel se encarga del deployment, el caching y la observabilidad, de modo que cambiar una ruta es una operación controlada y no un salto al vacío.
Cortar por page types y rutas
El oficio de una migración progresiva está en el corte. Una secuencia sensata: primero las páginas de contenido y las landing pages de bajo tráfico, después las páginas de categoría y de listado, luego el detalle de producto y por último el área cercana al checkout. Cada paso da una referencia real para el siguiente.
Dos aspectos merecen atención temprana. Primero, los Core Web Vitals: cada ruta migrada debería medirse contra la misma baseline de rendimiento, para que el nuevo layer sea mediblemente mejor y no solo distinto. Segundo, la continuidad SEO, canonical, redirecciones y hreflang tienen que mantenerse coherentes en la frontera entre lo antiguo y lo nuevo. El layer de frontend es el sitio natural para derivar esas señales de una única fuente.
Planificar alrededor de los picos de temporada
Las ventanas de freeze no son un obstáculo para la migración progresiva, son su mayor ventaja. Como cada ruta es un hito pequeño en sí mismo, el plan se puede colocar con precisión alrededor del pico: migra los page types no críticos antes del freeze y deja las rutas cercanas al ingreso para después de la ventana. Cuando llega el freeze, el sistema está en un estado intermedio estable en lugar de a medio reconstruir.
Un plan big bang no tiene ese estado estable. Se está antes o después del cutover, y si la fecha se cuela en el freeze no hay un lugar seguro donde detenerse.
Cuándo el big bang sigue siendo defendible
Lo progresivo no es automáticamente lo correcto siempre. Una tienda pequeña con pocos page types, con distancia clara respecto a la temporada y con un equipo capaz de asumir el cutover en una semana tranquila puede salir más rápido y más barato con un big bang, porque desaparece el coste de coordinación de un doble layer en paralelo. La pregunta honesta para decidir es: cuánto vale el ingreso por hora de caída y cuán cerca está la fecha del pico. Cuanto más altos sean ambos valores, más fuerte es el argumento para el camino progresivo.
Próximos pasos
Si tienes una migración a la vista y el calendario aprieta, merece la pena mirar el layer que reparte el tráfico. Descubre cómo el composable frontend de Laioutr hace posible la migración progresiva ruta por ruta.
Más de la plataforma
Sobre el autor: Marcel Thiesies es Co-Founder de Laioutr y trabaja cada día en cómo los equipos de e-commerce modernizan su stack de frontend sin poner en peligro la operación en producción ni la temporada alta. Más en LinkedIn.
Todos los datos se basan en información públicamente disponible, en aprendizajes de conversaciones comerciales con marcas de e-commerce de la región DACH y en pruebas propias de nuestra plataforma. Datos a julio de 2026. Las funcionalidades de producto mencionadas pueden haber evolucionado desde entonces.