Migración Next.js / Astro en Barcelona

#Migrar una web en Barcelona: comercio, turismo y diseño bajo el mismo techo

Barcelona concentra tres perfiles de proyecto que rara vez coinciden en una misma ciudad. El primero es el comercio de marca: el ecosistema de moda y D2C que va de las firmas consolidadas del Eixample a las marcas nacidas en Instagram que venden desde un taller en Poblenou. Muchas montaron su tienda en Shopify cuando eso era lo rápido, y hoy hacen números con los costes por transacción, las apps de pago mensual y un checkout que no controlan; el regreso a WooCommerce con un frontend moderno delante es una conversación que tenemos cada vez más a menudo. El segundo perfil es el turismo urbano: plataformas de actividades, alojamiento y gastronomía que operan como mínimo en castellano, catalán e inglés, porque en este mercado el catalán no es un detalle simbólico sino un requisito real de clientela y, para la información al consumidor, también una obligación recogida en el Codi de consum de Catalunya. El tercero es el propio sector creativo: estudios de diseño y agencias del 22@ con webs visualmente espectaculares que suspenden Core Web Vitals porque cada proyecto del portfolio carga vídeo, WebGL y tipografías variables a la vez.

Para los tres perfiles, la migración del frontend a Astro o Next.js es una salida realista, con una condición: tratarla como una mudanza con inventario, no como una demolición. Las URLs, el posicionamiento acumulado, las tres versiones lingüísticas y la rutina del equipo editorial se llevan puestas. Así es como planteamos los proyectos de migración para empresas de Barcelona.

#Cuándo migrar y cuándo basta con arreglar lo que hay

Migrar no es sinónimo de rediseñar. Un rediseño toca la piel de la web; una migración levanta la casa entera y se lleva consigo contenidos, direcciones y la visibilidad ganada durante años. En nuestras primeras llamadas con empresas de Barcelona esa decisión se toma con una hoja de cálculo delante, no con un moodboard, y las cifras suelen salir de dos sitios: la factura mensual de la plataforma y lo que cuesta cada visita de campaña.

La migración gana cuando el propio sistema es el freno. Un theme de WordPress heredado de un freelance ilocalizable donde cada retoque rompe algo en la otra punta de la web. Una tienda que, se apile la caché que se apile, sigue pintando la página de destino tan tarde que cada euro invertido en Meta o Google rinde menos de lo que debería. Una operación Shopify donde comisiones, apps de suscripción y un checkout cerrado suman más que el coste de tener infraestructura propia. O un CMS de cara a internet con extensiones abandonadas, que a estas alturas es más un pasivo de seguridad que una herramienta de trabajo.

Quedarse y optimizar gana cuando la plataforma está sana y solo ha envejecido la fachada. Un WordPress con PHP actualizado, theme ligero y pocos plugins no pide otra arquitectura: pide una pasada seria de diseño y rendimiento. La auditoría lo dirime sin predisposición, porque cobramos por ambos caminos y solo uno de los dos encaja en cada caso.

Hay una pregunta de diagnóstico que acorta mucho esa primera conversación: ¿quién sufre la web, la redacción o los visitantes? Cuando el equipo publica a gusto y el problema lo notan solo los usuarios, basta con sustituir el frontend y dejar el CMS donde está. Cuando también quien publica pelea con el sistema cada mañana, el backend entra en la conversación.

#Astro o Next.js: la respuesta depende del tipo de página

En los proyectos reales esta decisión se resuelve con un inventario de plantillas, no con un debate de frameworks. Piense en los dos extremos que vemos en Barcelona: el portfolio de un estudio de diseño y el motor de reservas de un operador de actividades. El portfolio es contenido que cambia unas pocas veces al mes; Astro lo convierte en HTML plano durante el build y el navegador recibe páginas ya terminadas, casi sin JavaScript, sin servidor que pueda caerse y con muy poco que atacar. El motor de reservas es lo contrario: cada visitante ve fechas, plazas y disponibilidad propias de su sesión, y ese trabajo por usuario es el terreno natural de Next.js.

Entre ambos extremos, la mayoría de los proyectos barceloneses acaba en una arquitectura mixta: web de marca, blog y fichas de producto como build de Astro, y el área de reservas o de cliente como aplicación Next.js, conviviendo en el mismo dominio con el enrutado como frontera. Forzar todo hacia un lado tiene coste: montarlo todo sobre Next.js significa pagar servidores para entregar páginas que podrían ser ficheros estáticos, y encajarlo todo en Astro obliga a simular una aplicación con piezas que no nacieron para eso.

El criterio que menos aparece en los comparadores es la plantilla humana. Un build de Astro alimentado por Markdown o por un CMS lo mantiene sin apuros un equipo pequeño; una aplicación Next.js necesita a alguien que sepa React, en nómina o contratado. Por eso cada asignación de tipo de página queda escrita junto con su porqué: la documentación debe sobrevivir a las personas que tomaron la decisión. El razonamiento completo, sin la capa local, está en la comparativa de Astro y Next.js.

#URLs, SEO y el catalán: hreflang para tres idiomas

El tráfico orgánico no se pierde por estrenar framework; se pierde por dejar direcciones huérfanas durante la mudanza. La mecánica general del inventario, que cruza el rastreo del sitio, Search Console y los logs del servidor para cazar también las direcciones que ya solo los humanos visitan, está descrita en nuestra metodología de migración. Cada entrada de ese inventario acaba en una de tres casillas: se queda donde está, viaja con un 301 o se retira con acta de defunción, es decir, con el código de estado correcto y una línea en la documentación.

En Barcelona este capítulo tiene una capa más que en la mayoría de los mercados: el multiidioma con catalán. Una web típica de aquí opera en castellano, catalán e inglés, y cada versión tiene su propio árbol de URLs, sus propios slugs y su propia historia de redirecciones. El error clásico de las migraciones baratas es tratar el catalán como una traducción decorativa: se migra con mimo la versión en castellano y las URLs en catalán acaban apuntando a destinos en otro idioma o directamente a errores 404. El resultado tarda en verse, porque un hreflang roto no tira la web, solo va erosionando la visibilidad de la versión afectada semana a semana. Nuestro proceso trata las tres versiones como ciudadanos de primera: inventario por idioma, destino 301 en el mismo idioma para cada dirección antigua y reconstrucción del mapa hreflang completo es/ca/en, comparado de forma automatizada entre sistema antiguo y nuevo antes del corte.

A la conservación del SEO pertenecen también los datos estructurados que hasta ahora emitía un plugin de SEO y que el frontend nuevo tiene que reproducir pieza a pieza, los sitemaps por idioma, los canonicals y el enlazado interno. Todo eso entra en la comparación automatizada previa al corte, para que las desviaciones aparezcan en el entorno de pruebas y no en producción.

#La redacción sigue publicando: WordPress como backend

Antes de hablar de frameworks, casi todos los equipos preguntan lo mismo: ¿tenemos que dejar de publicar? No. WordPress no se toca como herramienta editorial: sigue siendo el sitio donde la redacción escribe, aprueba y programa, con sus roles y permisos intactos. Lo que cambia es el destino de ese contenido: en lugar de renderizarlo un theme, lo recoge el frontend nuevo a través de la REST API o de WPGraphQL y lo convierte en las páginas que ve el visitante.

De ahí se derivan varias cosas que en la práctica pesan más que cualquier benchmark. La congelación de contenidos se reduce a las horas alrededor del corte, no a semanas de parón editorial. Nadie tiene que reaprender su herramienta, porque para quien publica el sistema es el mismo de ayer. Y el riesgo se reparte: contenido y frontend viajan en camiones separados, así que un tropiezo en uno no bloquea al otro.

Para las tiendas el mismo principio se aplica al catálogo: productos, existencias y pedidos siguen en WooCommerce y el frontend nuevo se construye delante. En los proyectos de vuelta desde Shopify, la exportación de productos, clientes e histórico de pedidos hacia WooCommerce es una fase propia, con su propia validación, antes de que el frontend entre en escena. Si su fundamento WordPress también necesita trabajo de fondo, la migración encaja con el desarrollo WordPress en Barcelona como un solo proyecto con un solo interlocutor.

#Medición, ventana de observación y vuelta atrás

Al corte solo se llega con el billete de vuelta comprado. La reversión se documenta y se ensaya antes del cambio, no se improvisa la noche del estreno: el traslado va por DNS o por enrutado mientras el sistema antiguo sigue encendido, de modo que deshacer el cambio cuesta minutos y el diagnóstico del fallo puede hacerse con calma en el entorno de pruebas, en lugar de en producción y de madrugada.

El momento del corte se elige mirando el calendario de la ciudad. Para una plataforma orientada a visitantes o a eventos, la semana del Mobile World Congress en febrero es el peor momento imaginable para estrenar frontend, igual que los meses de temporada alta lo son para el turismo urbano. Planificamos el cambio en valle de tráfico y así la siguiente punta llega con el sistema ya medido y estable.

Después llega la parte menos vistosa y más importante: varias semanas, normalmente entre cuatro y ocho, mirando datos. Indexación y rastreo en Search Console, posiciones de las consultas que traen negocio en cada uno de los tres idiomas, Core Web Vitals medidos sobre visitantes reales y los errores que asoman en la capa de redirecciones. Las dos primeras semanas siempre bailan un poco; la señal que cuenta es la tendencia del conjunto. El sistema antiguo no se apaga hasta que esa tendencia iguala o supera el punto de partida, y entonces se congela y se archiva. Y si más adelante quiere servir también las redirecciones y la entrega desde el borde de la red, ese paso está descrito en Cloudflare en el borde de la red.

#Protección de datos: APDCAT, AEPD y lo que debe quedar escrito

La empresa privada barcelonesa responde ante la AEPD, y quien trabaja para la Generalitat, ayuntamientos o el resto del sector público catalán tiene además a la APDCAT como autoridad de control propia; en los pliegos de ese segundo grupo las preguntas sobre tratamiento de datos ya no son un anexo opcional. Nuestro planteamiento es que la web migrada salga del proyecto con esas respuestas por escrito, no pendientes para más adelante.

En la práctica eso se concreta en tres entregables. El primero, un mapa de dónde ocurre cada cosa: en qué región se ejecutan los builds, desde qué nodos se entrega el HTML y por dónde pasan los envíos de formularios, con el procesamiento dentro de la UE allí donde la plataforma lo permite parametrizar. El segundo, una purga de incrustaciones: las webs con años de historia acumulan píxeles, widgets y fuentes externas que nadie recuerda haber contratado y que siguen recibiendo visitas; la migración es el momento natural de cortarlas, y en una web es/ca/en también de comprobar que el aviso de cookies y las capas de consentimiento dicen lo mismo en los tres idiomas. El tercero, documentación utilizable: los flujos nuevos descritos de manera que quien lleve el registro de actividades pueda actualizarlo leyendo, no reconstruyendo la arquitectura a base de preguntas al proveedor.

Hay además un beneficio lateral que conviene nombrar: con un frontend estático el visitante recibe ficheros sin base de datos detrás, y el CMS deja de estar a la vista de internet, con lo que buena parte de los vectores clásicos de ataque a WordPress sencillamente desaparece. Para empresas que ya han pasado un susto con plugins viejos, ese argumento pesa tanto como el rendimiento.

#Tres patrones de proyecto en Barcelona

Los nombres y algunos detalles están cambiados; las situaciones se repiten trimestre tras trimestre en nuestras conversaciones con empresas de aquí.

La marca de moda que vuelve de Shopify: una firma D2C con la operación montada en Shopify hizo cuentas al cerrar el año: comisiones por transacción, una columna de apps de pago mensual que no dejaba de crecer y un checkout que no podía adaptar a cómo vende en realidad. La vuelta se hizo por fases: primero la exportación de catálogo, clientes e histórico de pedidos a WooCommerce con su propia validación; después el frontend en Astro con las páginas de producto y de campaña servidas como HTML estático; el corte, fuera de temporada de rebajas, con las URLs de producto antiguas redirigidas una a una. El resultado operativo: control del checkout, costes previsibles y una velocidad de página que dejó de penalizar las campañas de pago. En proyectos así trabajamos codo a codo con el desarrollo WooCommerce en Barcelona.

El estudio creativo con un portfolio que no carga: una agencia del 22@ tenía la web que cabría esperar, visualmente impecable y técnicamente insostenible: cada pieza del portfolio cargaba vídeo de fondo, animaciones y tres familias tipográficas, y los Core Web Vitals estaban en rojo en móvil, justo donde los clientes potenciales miran el trabajo por primera vez. La migración a Astro reordenó las prioridades: las piezas visuales se cargan de forma diferida y bajo demanda, el HTML llega primero y la nota de rendimiento dejó de contradecir el mensaje de calidad del estudio. El proyecto no recortó ambición visual, recortó JavaScript que se enviaba sin necesidad.

La plataforma turística trilingüe: un operador de experiencias con la web en castellano, catalán e inglés arrastraba tres árboles de URLs crecidos de forma desigual durante años, con la versión catalana llena de redirecciones encadenadas de rediseños anteriores. El corazón del proyecto no fue el frontend sino el inventario: miles de direcciones por idioma, cada una con su destino 301 en su mismo idioma, y un mapa hreflang es/ca/en reconstruido y comparado de forma automatizada antes del corte. El cambio se programó en noviembre, en valle entre la temporada alta y las fiestas, y la ventana de medición confirmó la indexación estable de las tres versiones antes de apagar el sistema antiguo.

#Cuándo no conviene migrar

Ninguna agencia escribe este apartado en su web comercial, así que lo escribimos nosotros. Si lo que falla es el contenido, otra pila tecnológica solo servirá los mismos textos caducados con menos latencia; primero se arregla lo que se dice y luego cómo se entrega. Si su WordPress está sano, con buen hosting, theme cuidado y métricas de carga en verde, una optimización dentro del sistema captura casi todo el beneficio con una fracción del coste. Y si nadie va a hacerse cargo de la arquitectura nueva, ni en plantilla ni por contrato, el proyecto llega antes de tiempo: un frontend moderno abandonado se degrada igual que uno viejo.

El calendario manda tanto como la técnica. A quien nos pide cortar tres semanas antes de su pico de temporada le decimos que no, aunque eso suponga posponer el encargo: una migración con prisas y sin semanas de medición detrás devuelve los atajos con recargo.

#Cómo trabajamos con empresas de Barcelona

Trabajamos en remoto, en castellano o en inglés según el equipo, con interlocutores que no cambian a mitad de proyecto. La puerta de entrada es siempre la auditoría: estado del sistema actual, inventario de URLs en los tres idiomas y una recomendación razonada que puede ser perfectamente “no migre todavía”. A partir de ahí el proyecto avanza por fases cerradas: asignación de framework por tipo de página, construcción del frontend nuevo mientras el backend sigue en producción, corte con reversión ensayada y las semanas de medición con su informe final.

Cada fase se entrega completa y utilizable por sí misma, y al terminarla usted decide si la siguiente arranca. Esa estructura protege a ambas partes: su empresa nunca queda atada a un proyecto largo de resultado incierto, y nosotros trabajamos contra criterios de aceptación pactados en lugar de contra expectativas que se mueven. El presupuesto es individual y se concreta fase a fase; poner una cifra cerrada a un sistema que todavía no se ha auditado sería inventársela.

Al final recibe las llaves: arquitectura, capa de redirecciones y procesos de build documentados, el equipo formado y, si lo quiere, un acuerdo de mantenimiento continuado. Lo que buscamos dejar en Barcelona son sistemas que sus dueños entienden y hacen crecer, no clientes cautivos. Empezar cuesta poco: se pide la auditoría, se lee la recomendación y se decide en casa con números delante.

Última actualización: 10 de julio de 2026