¿Cuánto tarda una migración a WordPress headless en 2026?
De seis a dieciséis semanas para proyectos típicos. La forma son cuatro fases: descubrimiento, alcance, construcción y cutover, ajuste. Las variables que estiran o comprimen el cronograma son el tamaño del catálogo, el número de integraciones, la preservación de URLs y la disposición del equipo editorial, no la elección del framework.
Este artículo se ancla en el pilar de servicios de WordPress headless y se acompaña de la matriz de decisión Next.js vs Astro por el lado del framework y de Cloudflare Workers y WordPress en el edge para la capa de runtime.
TL;DR
- Sitios solo editoriales de menos de cincuenta páginas: cuatro a seis semanas.
- WooCommerce de hasta unos miles de SKU con integraciones estándar: diez a catorce semanas.
- Multi-región o multilingüe con integraciones a medida: catorce a dieciséis semanas, a veces más.
- Las semanas caras son el alcance (semanas uno y dos) y el cutover (último fin de semana), no la construcción en sí.
- El precio es individual por proyecto; publicamos el cronograma, no el precio.
Las cuatro fases en tiempo real
Las fases no son etiquetas de un diagrama de Gantt; se mapean a modos de trabajo distintos que requieren a personas diferentes en la sala.
Fase 1, descubrimiento (semana cero a dos)
Las partes interesadas, el equipo editorial, el responsable de analítica y el contacto técnico pasan por tres a cinco sesiones a lo largo de una a dos semanas. Los entregables son una auditoría del modelo de contenido, una baseline de rendimiento tomada del sitio en producción (TTFB, TTI, LCP por plantilla), un inventario de plugins e integraciones y un borrador del mapa de migración SEO.
El resultado del descubrimiento es input de decisión, no arquitectura. El equipo que se salta el descubrimiento para “ahorrar tiempo” paga el coste en la semana ocho, cuando aflora una integración no declarada y la capa de datos necesita un rediseño.
Fase 2, alcance (semana dos a tres)
Decisión de arquitectura: Astro 5+ o Next.js 15, elección de rendering por ruta, patrón de obtención de datos (REST o GraphQL), estrategia de invalidación de caché. El mapa de redirecciones se firma aquí, no más tarde. El flujo editorial se cierra: previsualizaciones, borradores, publicaciones programadas, flujos con varios autores.
El alcance termina con un engagement letter por escrito y una lista cerrada de entregables. Cualquier cosa que falte aquí será una change order en la semana diez, que es el momento más caro para negociar el alcance.
Fase 3, construcción y cutover (semana tres a doce)
La construcción avanza en sprints de dos semanas con una demo semanal. Cada demo es en staging, no en localhost, para que el equipo vea cómo se comporta de verdad la cara editorial en el nuevo stack. El primer sprint es el design system y una sola plantilla de extremo a extremo; los siguientes sprints se abren por tipo de plantilla.
El cutover en sí es una ventana de cuarenta y ocho a setenta y dos horas, planificada de forma deliberada. Funcionan dos patrones: cambio de DNS (más limpio, rollback más lento) y cutover por reverse proxy (rollback más rápido, más piezas en movimiento). El mapa de redirecciones se aplica en el edge, no en PHP.
La ventana de medición en paralelo corre una a dos semanas antes del cutover. Captura regresiones en etiquetas de tracking, validación de schema y Core Web Vitals antes de que lleguen a producción.
Fase 4, ajuste y retainer (semana doce a dieciséis)
Los TTLs de caché en el edge se afinan por ruta. La observabilidad (Cloudflare Logpush, pruebas sintéticas, alertas sobre TTFB y tasas 5xx) queda cableada. La entrega al retainer cubre trabajo de nuevas funcionalidades, revisiones trimestrales de Tech Radar y un roadmap para las necesidades cambiantes del equipo editorial.
Esta es la fase que más se omite. Omitirla cuesta seis meses de incidentes de bajo nivel que el equipo no puede diagnosticar porque nada está instrumentado.
Qué estira el cronograma
Tres patrones empujan un proyecto de seis semanas a doce, y un proyecto de doce semanas a veinte.
Descubrimiento tardío de integraciones. Una pasarela de pago a medida, una integración de ERP heredado por SOAP, un plugin de nicho sin superficie REST. Cada uno suma un adaptador hecho a medida. Cada adaptador añade dos a cuatro semanas de construcción, más la negociación contractual si un tercero posee el sistema upstream.
Preservación de URLs. Un sitio con treinta patrones únicos de URL es trabajo mecánico. Un sitio con trescientos patrones más una reestructuración de permalinks es un proyecto en sí mismo. El mapa de 301 se firma en el alcance, no se improvisa en la semana diez.
Reestructuración del modelo de contenido. Cuando el contenido WordPress existente está estructurado alrededor de las plantillas del tema en lugar de campos estructurados, el frontend no puede consumirlo de forma determinista. Reconstruir el modelo de contenido añade dos a seis semanas y exige una disponibilidad del equipo editorial que la mayoría de los equipos subestima.
Qué comprime el cronograma
Cuatro condiciones acortan el calendario de forma constante.
Modelo de contenido limpio. Custom post types, grupos de campos ACF o Meta Box, o un cambio reciente al editor de bloques con patrones estructurados. El frontend lee datos estructurados y renderiza de forma determinista. Ahorra dos a cuatro semanas.
Design system preexistente. Una biblioteca en Figma, un set de tokens o una librería de componentes que el equipo ya haya usado. Ahorra una a dos semanas de trabajo de cimientos en el primer sprint.
Disponibilidad del equipo editorial. Cuando el equipo editorial puede asistir a previsualizaciones semanales y aprobar flujos, la construcción no se atasca esperando aclaraciones. Ahorra una a dos semanas a lo largo del proyecto.
Equipo sénior a ambos lados. Un senior product owner por parte del cliente reduce a la mitad el ciclo de pregunta y respuesta. La agencia no puede fabricar esto; tiene que venir del comprador.
Cuándo la respuesta de seis semanas es errónea
Una tienda WooCommerce con tres mil SKU y un checkout a medida no migra en seis semanas. Quien cotice ese plazo está vendiendo otro alcance y renegociará después. La respuesta honesta para este perfil son doce a catorce semanas.
Un sitio multi-región con cinco locales y flujos de comercio específicos por locale tampoco es un proyecto de seis semanas. Flujos de traducción, validación de hreflang, estrategias de caché específicas por locale e integraciones de pago por región añaden cuatro a seis semanas incluso sobre una baseline saludable.
Cuándo la respuesta de dieciséis semanas es errónea
Un sitio editorial pequeño, una instalación de WordPress recién creada, un modelo de contenido limpio y un equipo sénior pueden entregar en cinco semanas. Cotizar dieciséis para ese perfil es alcance inflado.
Un sitio headless greenfield (sin componente de migración, solo un nuevo frontend sobre un WordPress nuevo) se salta la mayor parte de la fase uno y acorta la fase tres. Seis a ocho semanas en total.
Cómo es el precio
El precio es individual por proyecto. No publicamos precios de servicios en el sitio público. El engagement letter ata las horas a las cuatro fases anteriores, con un techo fijo en la fase uno (está acotada por el número de entrevistas, no por algo que escale) y time-and-materials o fixed-scope en la fase tres (según lo estable que sea el alcance tras el alcance).
Facturamos en EUR o USD, jurisdicción UE, contrato B2B. Consulta el pilar de servicios de WordPress headless para el modelo de colaboración.
Cluster reading
Los artículos de apoyo del clúster, por tema.
- Cloudflare Workers y WordPress en el edge sobre la capa de runtime del nuevo stack.
