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. Todos los rangos de semanas de este artículo son estimaciones de nuestra propia práctica de proyectos, no un estudio de mercado; el cronograma vinculante se fija después del descubrimiento.
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.
Qué fases tiene una migración a WordPress headless
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é retrasa una migración a WordPress headless
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.
Cómo acelerar una migración a WordPress headless
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 sénior 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.
Qué revisar antes de una migración a WordPress headless
Una estimación sin inventario es una suposición. La lista siguiente se puede recorrer en el panel y en la base de datos en un día de trabajo, antes de que nadie dé una fecha. Cada punto es un lugar donde un tema clásico hacía algo gratis y un desarrollo headless tiene que reconstruirlo.
Tipos de contenido y taxonomías. Cuántos custom post types y taxonomías hay y cuáles tienen archivos propios bajo URLs que están en el índice. Cada tipo con archivo es una plantilla y una ruta propias en el frontend.
Campos ACF y meta. Grupos de campos, repetidores, flexible content, campos de relación. Hay que comprobar si están expuestos en la REST API (show_in_rest) o en el esquema de WPGraphQL. Un flexible content con una docena de layouts significa una docena de componentes.
Shortcodes y bloques de plugins. El contenido guardado en la base de datos como shortcode llega al frontend como texto en bruto entre corchetes. Conviene contar las apariciones con una consulta sobre post_content antes de decidir si se renderizan o se reescriben.
Vista previa y borradores. Un tema clásico trae la vista previa de serie. En headless hay que construirla: una petición autenticada del borrador y un modo de vista previa en el frontend. El equipo editorial nota su ausencia la primera semana. Para las peticiones REST autenticadas, WordPress ofrece contraseñas de aplicación desde la versión 5.6: funcionan con HTTP Basic, están activas por defecto solo en sitios con HTTPS y no permiten iniciar sesión en wp-admin (guía de integración de contraseñas de aplicación).
Formularios. Contact Form 7 o Gravity Forms se renderizan dentro del tema PHP. Sin el tema, un formulario necesita un endpoint, validación, protección contra spam y los textos de consentimiento del RGPD que antes añadía el plugin.
Búsqueda. El ?s= integrado desaparece junto con el tema. Las opciones son un endpoint de búsqueda en REST, un índice externo o un índice estático generado en el build. Cada opción tiene un coste de mantenimiento distinto.
Integraciones de checkout propias de cada mercado. Plugins de pasarelas de pago locales, selectores de puntos de recogida en el checkout, exportación de pedidos a herramientas de facturación. Estos plugins están escritos para un checkout que renderiza WooCommerce, así que en headless hay que verificarlos contra la API del proveedor y no contra el código PHP del plugin. Son justo las integraciones que aparecen tarde en la sección sobre lo que retrasa el proyecto.
Redirecciones. Una exportación del plugin Redirection o de las reglas de .htaccess, más las listas de URLs del sitemap y de Google Search Console. De ahí sale el mapa de 301 que se firma en la fase de alcance.
El resultado es una tabla de tres columnas: elemento, dónde vive hoy, quién lo reconstruye. Las filas sin responsable son semanas que el cronograma todavía no contiene.
Cuánto tarda migrar WooCommerce a headless
Una tienda WooCommerce con tres mil SKU y un checkout a medida no migra en seis semanas. Quién 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ánto tarda un sitio WordPress headless pequeño
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.
Cuánto cuesta una migración a WordPress headless
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.
Cómo estimar por cuenta propia la duración de una migración headless
Las variables de las que depende la duración se pueden revisar antes de que nadie prepare un presupuesto. Son las que mueven un proyecto entre seis y dieciséis semanas; el framework cambia como mucho una semana.
- Catálogo. Contar las páginas editoriales y los SKU. Un sitio de menos de cincuenta páginas sin tienda es otro perfil que un WooCommerce con unos miles de productos.
- Integraciones. Listar todo lo que intercambia datos con WordPress: ERP, pasarela de pago, plugins sin superficie REST. Cada elemento descubierto durante la construcción significa un adaptador propio.
- Patrones de URL. Exportar la lista de direcciones y agruparlas por estructura. Treinta patrones son trabajo mecánico; trescientos con una reestructuración de enlaces permanentes son un proyecto aparte.
- Modelo de contenido. Comprobar si el contenido está en custom post types y campos ACF o Meta Box, o repartido por las plantillas del tema.
- Equipo editorial. Nombrar a la persona que aprobará las vistas previas con regularidad y responderá a las preguntas del equipo.
Con esta lista, las primeras sesiones de descubrimiento sirven para verificar datos que ya existen y se ve antes a qué perfil del TL;DR corresponde el sitio.
Cómo exponer tipos de contenido y campos en la REST API y WPGraphQL
El punto de ACF de la lista tiene una causa técnica concreta. Un custom post type no aparece en la REST API hasta que se registra con show_in_rest => true. Ese argumento añade una ruta en el espacio de nombres wp/v2, y el segmento de la URL toma por defecto el nombre del tipo salvo que se defina rest_base (manual de la REST API de WordPress). Las taxonomías necesitan el mismo argumento en register_taxonomy.
WPGraphQL tiene su propio interruptor. Un tipo de contenido entra en el esquema GraphQL cuando se definen show_in_graphql y graphql_single_name (camel case, sin espacios, empezando por letra). graphql_plural_name es opcional; sin él, el campo de lista recibe el prefijo all (documentación de WPGraphQL). La misma documentación describe una trampa típica del headless: las peticiones anónimas devuelven entradas publicadas solo si public o publicly_queryable vale true. Un tipo registrado como no público porque el tema no tiene plantilla para él devuelve datos solo a usuarios con permiso de edición. La documentación recomienda entonces fijar publicly_queryable => true de forma explícita.
Por eso el inventario del descubrimiento debe anotar tres valores por cada tipo de contenido: show_in_rest, show_in_graphql y publicly_queryable. Si falta uno, el cambio va en el código de registro, no en el frontend.
Cómo preparar el mapa de redirecciones 301 en una migración headless
Google trata un cambio de URLs como un traslado de sitio y recomienda redirecciones permanentes en el servidor (301 o 308) desde cada URL antigua a su equivalente, siguiendo un mapeo preparado antes del traslado. La misma documentación advierte contra enviar muchas URLs antiguas a una sola página sin relación, como la portada. Las redirecciones deben mantenerse el mayor tiempo posible, en general al menos un año. En sitios medianos Google puede tardar unas semanas o más en mostrar las URLs nuevas en lugar de las antiguas, y la visibilidad en la búsqueda puede fluctuar en ese tiempo (Google Search Central sobre traslados de sitio con cambios de URL).
Cuando el mapa se aplica en el edge, cuenta el límite de la plataforma. El archivo _redirects de Cloudflare Pages admite hasta 2000 redirecciones estáticas y 100 dinámicas, 2100 en total, y cada regla tiene un límite de 1000 caracteres. Los mapas mayores pasan a Bulk Redirects (documentación de Cloudflare Pages). Por eso el número de patrones de URL del descubrimiento condiciona la arquitectura: treinta patrones caben como reglas dinámicas dentro del límite, mientras que miles de URLs sueltas sin patrón común necesitan otro mecanismo.
SSG, ISR o SSR y cómo el renderizado afecta a la publicación
La fase de alcance elige el renderizado por ruta, y esa elección decide cuándo aparece en el sitio un cambio guardado en el panel de WordPress. Astro prerenderiza por defecto páginas, rutas y endpoints en el build. Una página concreta pasa a renderizado bajo demanda con export const prerender = false, y output: 'server' invierte el comportamiento por defecto en todo el proyecto. Ambos casos necesitan un adaptador de servidor (documentación de Astro). En una variante puramente estática cada publicación implica un build nuevo, así que el flujo editorial necesita un disparador de build al guardar una entrada.
Next.js ofrece Incremental Static Regeneration. La exportación revalidate fija el tiempo tras el cual la siguiente petición inicia la regeneración de la página en segundo plano, y revalidatePath y revalidateTag invalidan la caché bajo demanda, por ejemplo desde un webhook lanzado al publicar. La documentación enumera los límites: ISR no funciona con una exportación estática, el soporte en adaptadores depende de la plataforma y, con varias instancias, la caché por defecto es propia de cada una, de modo que la invalidación solo llega a la instancia que recibió la llamada mientras no se configure un cache handler compartido (guía de ISR de Next.js).
Por eso la vista previa y las publicaciones programadas se acuerdan en la fase de alcance junto con el renderizado, no al final de la construcción.
Artículos relacionados
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.
