Migración Next.js / Astro en Leeds

Movemos sitios existentes desde WordPress o un CMS más antiguo hacia una arquitectura headless con frontend en Next.js o Astro. El backend de contenido puede quedarse (WordPress como fuente headless vía REST o GraphQL) o cambiar, según quién edite los contenidos en el día a día. No reconstruimos proyectos que salen más baratos si se arreglan donde están.

De forma incremental por defecto. El nuevo frontend asume una sección cada vez mientras el resto sigue funcionando en el sistema antiguo, con un reverse proxy o reglas en el edge repartiendo el tráfico hasta terminar. Un cambio de golpe solo tiene sentido en sitios pequeños, donde mantener dos stacks en paralelo cuesta más que un corte limpio.

Mapeamos todas las URLs antiguas antes de empezar y las emparejamos una a una en el sitio nuevo, con redirecciones 301 allí donde cambia una dirección. Títulos, meta, datos estructurados y canónicos se trasladan, y tras el lanzamiento vigilamos Search Console para detectar caídas de indexación pronto. Cualquier cambio de dirección queda por escrito de forma deliberada, no como efecto colateral.

Es un compromiso, no una cuestión de fe. Elijo Astro para sitios con mucho contenido (blogs, webs corporativas, documentación) porque envía cero JavaScript por defecto; Next.js cuando hay interactividad real, un área con login o renderizado en servidor para datos dinámicos. Dejo la recomendación por escrito para poder revisar el razonamiento un año después.

Protegemos los Core Web Vitals con un presupuesto de rendimiento en CI, de modo que una regresión en LCP o CLS tumba el build antes de llegar a producción. El código se entrega con documentación, convenciones y un pipeline de despliegue que tu equipo puede asumir sin nosotros. La entrega incluye el repositorio, las variables de entorno y una guía breve para publicar cambios.