Migración Next.js / Astro en Madrid

#Migrar en Madrid: un punto de partida propio

Los proyectos de migración que llegan desde Madrid rara vez empiezan en un folio en blanco. La ciudad acumula tres herencias digitales que en otros mercados no suelen coincidir. La primera es corporativa: Madrid concentra sedes de grandes grupos de banca, seguros y energía, y esas sedes arrastran ecosistemas web construidos por proveedores distintos a lo largo de una década, con un CMS por filial, plantillas duplicadas y nadie que tenga el mapa completo. La segunda es editorial: buena parte de los medios digitales en español se produce desde Madrid, y un medio vive de picos de tráfico que multiplican por cien la carga en minutos, algo que un CMS monolítico con caché de plugin encaja mal. La tercera es la herencia de agencia: en el eje que va de Gran Vía a Chamberí se montaron durante años tiendas sobre PrestaShop 1.6 y portales sobre Joomla que hoy siguen en producción con módulos congelados y versiones de PHP fuera de soporte.

A eso se suma una particularidad que convierte a Madrid en un caso especial dentro de Europa: desde aquí se sirve a un mercado hispanohablante global. Una petición desde Ciudad de México o Bogotá hacia un servidor alojado en Madrid cruza el Atlántico dos veces por cada recurso sin caché, y esa física se nota en cada campaña dirigida a América Latina. Un frontend estático generado con Astro o Next.js y distribuido en el edge responde desde el nodo más cercano al lector, no desde la Castellana. Para muchas empresas madrileñas ese argumento pesa tanto como la seguridad o el coste de mantenimiento.

#Cuándo migrar en vez de rediseñar

Los dos términos se mezclan a menudo y designan cosas distintas. Un rediseño renueva la capa visual y los contenidos dentro del sistema existente. Una migración cambia la base técnica y se lleva consigo contenidos, URLs y visibilidad en buscadores. Elegir entre ambos no es una cuestión de gusto sino de cálculo.

A favor de la migración habla que el propio sistema sea el problema: instalaciones Joomla cuya ruta de actualización costaría más que reconstruir el frontend, themes de WordPress en los que cada cambio provoca efectos secundarios en lugares inesperados, tiendas cuyos tiempos de carga no bajan del umbral a partir del cual Google y los clientes pierden la paciencia por muchos plugins de caché que se apilen, o situaciones de seguridad en las que un CMS expuesto con extensiones sin soporte es un riesgo que ningún contrato de mantenimiento puede seguir tapando.

A favor de renovar dentro del sistema habla que la plataforma esté sana y solo la fachada haya envejecido. Un WordPress cuidado, con PHP actual, theme ligero y lista de plugins depurada, no necesita otra arquitectura sino buen diseño. Lo evaluamos en la auditoría sin decisión previa: trabajamos en ambos caminos, pero solo uno es el correcto para su caso. Un indicador honesto que usamos en las primeras reuniones: si su equipo editorial está cómodo con el CMS y solo los visitantes sufren la web, separar backend y frontend es la solución más elegante. Si la redacción también pelea a diario contra el sistema, la pregunta por el backend entra en la mesa.

#Astro o Next.js: la decisión se toma por ruta

La pregunta por el framework se plantea a menudo como cuestión de fe. En los proyectos es una tabla con tipos de página. Astro renderiza las páginas en tiempo de build como HTML estático y solo entrega JavaScript donde un componente lo pide expresamente. Para páginas de contenido, es decir webs corporativas, medios, documentación y landings, es la arquitectura más eficiente disponible: entrega rápida, ningún servidor en la ruta de la petición y una superficie de ataque mínima. Next.js muestra su fuerza cuando las páginas deben verse distintas para cada usuario: portales de clientes, productos configurables, buscadores con filtros complejos, contenido personalizado.

La respuesta honesta para la mayoría de las empresas madrileñas es por tanto: ambos, pero en sitios distintos. La web de marketing y la revista corporativa como build de Astro, el área privada como aplicación Next.js, las dos bajo el mismo dominio y separadas de forma limpia por enrutado. Quien lo construye todo en Next.js por sistema paga para sus páginas de contenido una infraestructura de servidores que el HTML estático no necesita. Quien lo fuerza todo en Astro retuerce aplicaciones interactivas en un modelo que no está pensado para ellas.

Hay un segundo punto que se pasa por alto: quién trabajará con el sistema después de la migración. Los proyectos Astro con contenidos en Markdown o conectados a un CMS son mantenibles para equipos pequeños. Las aplicaciones Next.js exigen experiencia en React, que debe existir en el equipo o contratarse. Documentamos la decisión por ruta con su justificación, para que dentro de dos años siga siendo comprensible aunque cambien las personas. La comparación general, independiente de la ciudad, está en nuestra página de migración a Next.js y Astro.

#Preservación de URLs y SEO: donde se gana o se pierde el proyecto

Cuando una migración cuesta tráfico orgánico, casi nunca es por el framework nuevo y casi siempre por URLs perdidas. Por eso cada proyecto empieza con un inventario completo de URLs a partir de tres fuentes: un rastreo del sistema antiguo, los datos de rendimiento de Search Console y los logs del servidor de los últimos meses. Los logs son la fuente infravalorada: muestran también las direcciones que ningún rastreador encuentra ya pero que los visitantes siguen abriendo, enlaces de newsletters antiguas, marcadores, referencias desde foros y documentos PDF.

Cada dirección del inventario recibe una decisión: sigue viva bajo la misma URL, se redirige con un 301 a su sucesora, o se despide de forma consciente con el código de estado correcto. Consciente significa documentado, no olvidado. En sistemas con historia salen a la luz familias enteras de URLs que nadie tenía en el radar: en los Joomla madrileños son las direcciones con parámetros de index.php indexadas en paralelo a sus versiones amigables, en las tiendas PrestaShop los identificadores numéricos de producto que conviven con las rutas reescritas. La migración es la oportunidad de limpiar ese lastre en vez de arrastrarlo.

Preservar el SEO es más que el mapeo de redirecciones. Los datos estructurados que el sistema antiguo generaba por plugin deben reconstruirse en el frontend nuevo y compararse de forma automatizada, o perderá resultados enriquecidos sin darse cuenta. Y para una web madrileña que sirve a España y a América Latina, el andamiaje hreflang entre variantes de español es parte del inventario, no un extra: una etiqueta que apunte a una URL antigua tarda semanas en aparecer en los informes. Sitemaps, canonicals y enlazado interno completan la lista de comprobación, y antes del corte un cotejo automatizado recorre el inventario entero contra el sistema nuevo.

#La operación editorial no se detiene

La preocupación que más veces aparece en las primeras reuniones no es técnica sino operativa: ¿podemos seguir publicando durante la migración? La respuesta es sí, y la arquitectura es el motivo. En la mayoría de nuestros proyectos WordPress permanece íntegro como backend editorial. Su equipo trabaja en la interfaz de siempre, con los mismos flujos, roles y aprobaciones. El frontend nuevo obtiene los contenidos por la REST API o WPGraphQL y construye con ellos las páginas que se entregan.

Esto tiene tres consecuencias prácticas. Primera: no hay congelación de contenidos de semanas. Hasta el corte, lo nuevo aparece en el frontend antiguo; después, en el nuevo. El día del traslado cuesta a la redacción unas horas, no un sprint. Segunda: la formación casi desaparece, porque la herramienta del equipo no cambia, solo lo que ven los visitantes. Tercera: el riesgo del proyecto baja, porque contenidos y frontend se mudan por separado y un problema en uno no arrastra al otro. Para un medio que publica decenas de piezas al día, esta separación no es una comodidad, es la condición para que el proyecto sea siquiera planteable.

Con las herencias Joomla y PrestaShop el camino es otro, porque allí el backend suele ser parte del problema. Extraemos los contenidos de la base de datos, los depuramos y los llevamos a un backend WordPress fresco o, con volúmenes manejables, directamente a contenidos Markdown versionados en el proyecto Astro. Para redacciones que vienen de Joomla, el cambio al editor de WordPress es en nuestra experiencia un alivio, no un obstáculo.

#Ventana de medición y reversión: la parte que genera confianza

Un corte sin camino de vuelta no es valentía, es imprudencia. Por eso cada proyecto incluye un plan de reversión documentado y ensayado antes del corte. El traslado se hace mediante cambio de DNS o de enrutado, el sistema antiguo queda intacto y plenamente operativo. Si en producción aparece un problema que no se resuelve en poco tiempo, el cambio se revierte en minutos y el análisis se hace sin presión en el entorno de pruebas.

Tras el corte empieza la ventana de medición, normalmente de cuatro a ocho semanas. Se observan el estado de indexación y el comportamiento de rastreo en Search Console, las posiciones de las búsquedas importantes, los Core Web Vitals con datos de usuarios reales y las tasas de error de la capa de redirecciones. Pequeños movimientos en las dos primeras semanas son normales, porque los buscadores procesan las señales nuevas de forma gradual; lo que decide es la tendencia sobre la ventana completa. Solo cuando las métricas se estabilizan en el nivel de partida o por encima se congela el sistema antiguo, se archiva y se apaga. La copia de archivo se conserva: la pregunta por un contenido de hace seis años llega siempre cuando nadie la espera.

#RGPD, AEPD y geografía de datos

Una migración cambia los flujos de datos, y eso pertenece a la planificación del proyecto, no a los remiendos posteriores. En España el listón lo pone la Agencia Española de Protección de Datos, una de las autoridades más activas de Europa en régimen sancionador, y una web corporativa que pasa por un proceso de migración debería salir de él con los deberes hechos, no con incógnitas nuevas.

Tres cuestiones se resuelven de serie. Primera: dónde se construye y se entrega. Los builds estáticos pueden generarse y servirse desde ubicaciones europeas, y en plataformas distribuidas globalmente configuramos el tratamiento para que los datos personales se procesen en la UE. Segunda: qué pasa con formularios y servicios incrustados. El traslado es el momento de inventariar las integraciones heredadas, porque en instalaciones de diez años aparecen con regularidad terceros que ya nadie usa pero que siguen cargando y enviando datos. Tercera: el registro de actividades de tratamiento. Tras la migración documentamos los flujos nuevos de forma que su delegado de protección de datos pueda actualizar el registro sin tener que hacer ingeniería inversa de la arquitectura.

Hay un efecto colateral que en conversaciones con empresas madrileñas inclina a menudo la balanza: un frontend estático sin CMS expuesto públicamente reduce la superficie de ataque de forma drástica. El backend queda tras una restricción de acceso y las páginas entregadas no contienen ninguna conexión a base de datos que pueda comprometerse. Para organizaciones cuyos últimos incidentes vinieron de extensiones sin actualizar, esto no es un detalle.

#Madrid y América Latina: la latencia como argumento de negocio

Para una empresa de Berlín, el edge es una mejora; para una de Madrid con audiencia en América Latina, es la diferencia entre una web que responde y una que se arrastra. La física no negocia: cada petición dinámica desde Santiago o Buenos Aires hasta un servidor en un centro de datos español paga el peaje transatlántico, y una página de tienda o de medio dispara decenas de peticiones.

Un frontend estático cambia el planteamiento. Las páginas generadas en el build se distribuyen a los nodos de la red de entrega y responden desde Ciudad de México, Bogotá o Lima, no desde Madrid. El origen solo interviene donde hay sesión o transacción. Nuestra propia plataforma funciona así en producción, con más de siete mil páginas estáticas servidas desde el edge, de modo que lo que proponemos lo operamos a diario. Quien quiera llevar también la lógica de redirecciones y la protección frente a bots al borde de la red encontrará el siguiente paso en nuestro servicio de desarrollo edge con Cloudflare.

#Tres patrones de caso en proyectos madrileños

Anonimizados, pero representativos de los puntos de partida que nos encontramos en esta ciudad.

El medio con picos de tráfico: un medio digital sufría caídas en cada jornada electoral y cada noticia de última hora, justo cuando más lectores llegaban. El CMS renderizaba cada portada bajo demanda y la caché de plugin se invalidaba con cada actualización de la redacción. La solución fue un frontend Astro con builds incrementales: las piezas se publican en WordPress como siempre, el HTML estático aguanta el pico sin servidor de por medio y el origen queda protegido. El pico dejó de ser un incidente y pasó a ser una métrica de audiencia.

El corporativo multiidioma: un grupo con sede en Madrid y filiales en varios países operaba seis webs nacionales sobre instalaciones distintas, con plantillas divergentes y proveedores diferentes. La migración se planteó por etapas: primero una web piloto como build Astro contra un backend consolidado, con el mapeo 301 y el andamiaje hreflang como entregables centrales, después la incorporación de cada país con su calendario propio. El departamento de compras exigió homologación de proveedor, documentación de seguridad y facturación intracomunitaria, y ese circuito formó parte del plan desde la primera semana, no de las sorpresas del final.

La tienda con herencia PrestaShop: un comercio llevaba años sobre PrestaShop 1.6 con módulos congelados y un rediseño imposible de abordar dentro de la plataforma. En lugar de un traslado a lo grande, la migración fue por fases: catálogo y páginas de contenido pasaron primero a un frontend estático rápido, el checkout permaneció en el sistema probado hasta después de la campaña fuerte del año, y la decisión sobre la plataforma de venta definitiva se tomó con datos en la mano. Para esta clase de proyectos, la migración y el desarrollo WooCommerce en Madrid van de la mano.

#Cuándo no conviene migrar

La sección que suele faltar en las webs de agencia. Una migración es la respuesta equivocada cuando el problema real está en el contenido: textos desactualizados y falta de mantenimiento no mejoran con otro framework, solo se entregan más rápido. Es también la respuesta equivocada para instalaciones WordPress sanas con buen hosting y theme cuidado, cuyos tiempos de carga están en verde; ahí la optimización dentro del sistema logra la mayor parte del efecto por una fracción del esfuerzo. Y es prematura cuando nadie en la organización puede asumir la responsabilidad de la arquitectura nueva y tampoco hay un socio de operación previsto, porque un frontend moderno sin cuidado envejece igual que uno antiguo.

El calendario también puede jugar en contra: quien quiera migrar tres semanas antes de su campaña más importante no debería hacerlo. Lo decimos abiertamente en la auditoría aunque eso aplace el proyecto. Una migración forzada por fechas y sin ventana de medición cobra sus atajos más tarde, y con intereses.

#Cómo trabajamos con empresas de Madrid

Trabajamos con clientes madrileños en remoto y en español, como agencia establecida en la UE, con contratos europeos, facturación intracomunitaria y los circuitos de compras corporativas que las grandes organizaciones exigen: alta como proveedor homologado, cuestionarios de seguridad, acuerdos de confidencialidad y documentación de tratamiento de datos. Para los departamentos de compras de la banca, los seguros o la energía ese papeleo no es un trámite menor, y lo tratamos como parte del proyecto.

El trabajo avanza por etapas que se aceptan una a una. Al principio está la auditoría de migración: inventario del sistema antiguo, inventario de URLs, evaluación de contenidos y una recomendación argumentada, incluso si concluye que usted no necesita migrar. Después vienen la decisión de framework por ruta, la construcción en paralelo contra el backend en funcionamiento, el corte con vuelta atrás ensayada y la ventana de medición con informe. Cada etapa termina con un resultado que se sostiene por sí mismo y con una decisión sobre si se continúa. El presupuesto es individual y se estima por etapa, no como tarifa cerrada sobre un proyecto cuyas incógnitas nadie puede cifrar con seriedad al principio.

Al final está la entrega: documentación de la arquitectura, de la capa de redirecciones y de los procesos de build, formación de su equipo y, si lo desea, un modelo de operación continua. El objetivo es un sistema que su organización entienda y pueda evolucionar, no una dependencia nueva. Y si su fundamento WordPress necesita manos antes o después de la migración, el desarrollo WordPress en Madrid es el punto de entrada natural. El primer paso no compromete a nada: una auditoría con recomendación clara y una estimación con la que decidir internamente.

Última actualización: 10 de julio de 2026