He liderado alrededor de 40 migraciones de CMS en los últimos cinco años, y la pregunta que me hacen más que ninguna otra es: "¿Cuánto tiempo va a tardar esto realmente?" No la versión del discurso de ventas. La respuesta real.

El caso es que la respuesta real casi siempre es más larga de lo que quieres, pero más corta que tus peores temores. ¿Un sitio de marketing pequeño? Estás mirando entre 3 y 6 semanas. ¿Una empresa mediana con un blog, e-commerce e integraciones personalizadas? Planifica de 2 a 4 meses. ¿Una empresa con más de 10.000 páginas, múltiples idiomas y sistemas heredados? Prepárate para entre 4 y 8 meses.

Pero esos rangos no tienen sentido sin contexto. Déjame desglosar exactamente qué sucede en cada fase, dónde los equipos pierden tiempo y cómo evitar que tu migración se convierta en una de esas historias de terror que se prolongan durante un año.

Tabla de contenidos

CMS Migration Timeline: WordPress to Next.js in 2026

¿Por qué migrar de WordPress a Next.js en 2026?

Seré directo: no todos los sitios de WordPress necesitan migrar. Si gestionas un blog personal o un sitio de pequeña empresa que funciona bien, WordPress sigue siendo perfectamente capaz. Pero hay razones reales y medibles por las que los equipos están migrando a Next.js con un CMS headless en 2026:

  • Rendimiento: Los sitios de Next.js con generación estática y renderizado en el edge obtienen de forma constante más de 90 puntos en Core Web Vitals. Los sitios de WordPress promedian alrededor de 50-65 sin un trabajo de optimización significativo.
  • Seguridad: Desacoplar el frontend del CMS elimina los vectores de ataque más comunes de WordPress. En 2025, Sucuri informó que WordPress representó el 96,2% de los sitios CMS infectados.
  • Experiencia del desarrollador: La arquitectura de componentes basada en React significa una iteración más rápida y una contratación más sencilla. La cantera de talento PHP para WordPress está disminuyendo — la encuesta de Stack Overflow de 2025 mostró que PHP cayó al puesto 14 en popularidad de lenguajes.
  • Escalabilidad: Los sitios de Next.js desplegados en el edge en Vercel o Cloudflare manejan picos de tráfico sin necesidad del enfoque de "añadamos más servidor".

Si tienes problemas de rendimiento, preocupaciones de seguridad o un equipo de desarrollo que teme tocar tu código base de WordPress, la migración tiene sentido. Cubrimos el enfoque técnico en detalle en nuestra página de capacidades de desarrollo Next.js.

Resumen del cronograma de migración por tamaño del sitio

Aquí está el desglose honesto. Estos cronogramas asumen un equipo dedicado (no personas que dividen su tiempo con otros proyectos) y partes interesadas razonablemente disponibles.

Tamaño del sitio Páginas Complejidad típica Cronograma Tamaño del equipo
Pequeño (Marketing/Folleto) 5-50 Baja — pocas integraciones, contenido estándar 3-6 semanas 2-3 personas
Mediano (Empresa) 50-500 Media — blog, formularios, algunas integraciones, múltiples plantillas 8-16 semanas 3-5 personas
Grande (Mercado medio) 500-5.000 Alta — e-commerce, múltiples autores, flujos de trabajo complejos 3-5 meses 4-7 personas
Empresa 5.000+ Muy alta — múltiples idiomas, integraciones heredadas, cumplimiento normativo 4-8 meses 6-12 personas

Estos son cronogramas de desarrollo, no cronogramas de calendario. El tiempo en calendario siempre es mayor debido a las revisiones de las partes interesadas, los ciclos de retroalimentación y las inevitables dos semanas en las que el VP de Marketing está de vacaciones durante la fase de aprobación del diseño.

Fase 1: Descubrimiento y auditoría

Duración: 1-3 semanas

Aquí es donde la mayoría de las agencias se apresuran y la mayoría de las migraciones se tuercen. El descubrimiento no es simplemente "mirar el sitio de WordPress y hacer una lista". Es un trabajo forense.

Qué ocurre realmente

  • Inventario de contenido: Catalogar cada tipo de contenido, taxonomía, campo personalizado y activo multimedia. Uso Screaming Frog para rastrear el sitio existente y exportar un mapa completo de URLs. Para un sitio de 2.000 páginas, solo esto lleva un día completo para organizarlo correctamente.
  • Auditoría de plugins: Documentar cada plugin activo y lo que hace. El sitio de WordPress promedio tiene entre 20 y 30 plugins. Cada uno representa funcionalidad que debes replicar, reemplazar con una herramienta SaaS o descartar intencionalmente.
  • Mapeo de integraciones: ¿Los formularios van a HubSpot? ¿Procesamiento de pagos a través de WooCommerce? ¿Analítica a través de Google Tag Manager con eventos personalizados? Dibuja el panorama completo.
  • Línea base de SEO: Exportar todos los metatítulos, descripciones, URLs canónicas, datos estructurados y patrones de enlazado interno. No puedes permitirte perder capital de SEO durante la migración.
  • Entrevistas con las partes interesadas: Habla con las personas que realmente usan el CMS a diario. Editores de contenido, especialistas en marketing, quien gestione el blog. Sus flujos de trabajo importan más que la arquitectura técnica.

Entregables del descubrimiento

  • Documento del modelo de contenido
  • Mapa de dependencias de integración
  • Plan de migración de SEO
  • Registro de riesgos (cosas que podrían hacer explotar el cronograma)
  • Recomendación preliminar de arquitectura

Saltarse o apresurar el descubrimiento es la principal causa de desbordamientos en el cronograma. He visto una "migración rápida de 6 semanas" convertirse en un calvario de 5 meses porque nadie documentó que el sitio de WordPress tenía 47 Gravity Forms personalizados con lógica condicional que enviaba datos a tres CRM diferentes.

CMS Migration Timeline: WordPress to Next.js in 2026 - architecture

Fase 2: Arquitectura y planificación

Duración: 1-2 semanas

Con los datos del descubrimiento en mano, tomas las grandes decisiones.

Elegir tu CMS headless

Next.js es tu framework de frontend, pero aún necesitas un backend de gestión de contenido. Las principales opciones en 2026:

CMS Ideal para Precios (2026) Curva de aprendizaje
Sanity Modelos de contenido complejos, colaboración en tiempo real Nivel gratuito, luego $99-$949/mes Moderada
Contentful Equipos empresariales, gobernanza sólida Desde $300/mes Moderada
Storyblok Edición visual, equipos de marketing Nivel gratuito, luego €106-€399/mes Baja
Payload CMS Orientado al desarrollador, control self-hosted Gratuito (código abierto), Cloud desde $50/mes Alta
WordPress (Headless) Equipos que quieren mantener el admin de WordPress Costos de hosting existentes Baja (familiar)

Sí, puedes usar WordPress como CMS headless con WPGraphQL o la API REST. Algunos equipos hacen esto para mantener a sus editores de contenido en un entorno familiar mientras obtienen Next.js en el frontend. Es un enfoque válido, aunque heredas cierta carga de mantenimiento de WordPress.

Ayudamos a los equipos a evaluar estas opciones como parte de nuestro trabajo de desarrollo de CMS headless. La elección correcta depende en gran medida del nivel de comodidad técnica de tu equipo editorial.

Decisiones de arquitectura

  • Estrategia de renderizado: ¿Generación de sitio estático (SSG), Regeneración estática incremental (ISR) o renderizado del lado del servidor (SSR)? La mayoría de los sitios en 2026 utilizan un enfoque híbrido — ISR para páginas de contenido, SSR para páginas personalizadas o en tiempo real.
  • Hosting: Vercel es la opción predeterminada para Next.js, pero Netlify, Cloudflare Pages y AWS Amplify son todas viables. El plan Pro de Vercel a $20/usuario/mes cubre a la mayoría de los equipos.
  • Arquitectura de API: ¿Usarás la API nativa del CMS, construirás una capa de middleware o utilizarás algo como tRPC para llamadas a la API con seguridad de tipos?
  • Autenticación: Si tienes contenido restringido o áreas para miembros, planifica esto con antelación. NextAuth.js (ahora Auth.js v5) gestiona la mayoría de los patrones.

Fase 3: Modelado de contenido y configuración del CMS

Duración: 1-3 semanas

Aquí es donde construyes tu estructura de contenido en el nuevo CMS. No te limites a replicar tu estructura de WordPress — esta es tu oportunidad de corregir años de deuda de contenido acumulada.

Diseño del modelo de contenido

WordPress tiende a fomentar un modelo de contenido plano: entradas, páginas y un desorden de campos personalizados mediante ACF o Meta Box. Un CMS headless te permite pensar en contenido estructurado.

// Ejemplo: Modelo de contenido de Blog Post en Sanity
export default defineType({
  name: 'blogPost',
  title: 'Blog Post',
  type: 'document',
  fields: [
    defineField({
      name: 'title',
      type: 'string',
      validation: (Rule) => Rule.required().max(70),
    }),
    defineField({
      name: 'slug',
      type: 'slug',
      options: { source: 'title' },
    }),
    defineField({
      name: 'author',
      type: 'reference',
      to: [{ type: 'author' }],
    }),
    defineField({
      name: 'body',
      type: 'portableText', // Contenido enriquecido estructurado
    }),
    defineField({
      name: 'seo',
      type: 'seoFields', // Objeto SEO reutilizable
    }),
  ],
})

El contenido estructurado significa que el cuerpo de tu entrada de blog no es solo un bloque de HTML. Son bloques estructurados que tu frontend puede renderizar como quiera — web, aplicación móvil, boletín por correo electrónico, lo que sea.

Configuración del CMS

  • Configurar roles y permisos
  • Configurar la funcionalidad de vista previa (la vista previa en vivo en Next.js es esencial para la adopción por parte de los editores)
  • Construir componentes de entrada personalizados o reglas de validación
  • Configurar webhooks para activar reconstrucciones cuando cambia el contenido

Fase 4: Desarrollo del frontend

Duración: 2-8 semanas (la mayor variable)

Aquí es donde va la mayor parte del tiempo en calendario. Construir el frontend de Next.js implica:

Diseño y sistema de componentes

Si estás rediseñando durante la migración (lo cual hace aproximadamente el 70% de nuestros clientes), añade de 2 a 4 semanas. Si estás replicando el diseño existente, puedes avanzar más rápido.

// Ejemplo de arquitectura orientada a componentes
export default function BlogPost({ post }: { post: BlogPostType }) {
  return (
    <article>
      <PageHeader title={post.title} date={post.publishedAt} />
      <AuthorCard author={post.author} />
      <PortableText 
        value={post.body} 
        components={customComponents} 
      />
      <RelatedPosts posts={post.related} />
      <NewsletterSignup />
    </article>
  )
}

Recomiendo encarecidamente construir primero una biblioteca de componentes y luego ensamblar las páginas. Al principio parece más lento, pero resulta enormemente beneficioso cuando estás construyendo tu plantilla de página número 15.

Tareas clave de desarrollo

  • Plantillas de página para cada tipo de contenido
  • Enrutamiento dinámico y rutas catch-all
  • Navegación (incluidos los mega menús si corresponde)
  • Funcionalidad de búsqueda (Algolia, Meilisearch o la integrada en Next.js)
  • Implementaciones de formularios (reemplazando Gravity Forms, Contact Form 7, etc.)
  • Integraciones de terceros (analítica, widgets de chat, conexiones con CRM)
  • Optimización de imágenes (componente Image de Next.js con el CDN de imágenes de tu CMS)
  • Generación de sitemap
  • Feeds RSS
  • Mapeo de redirecciones 301

El mapeo de redirecciones por sí solo puede llevar días en un sitio grande. Cada URL que cambia necesita una redirección, o estarás tirando por la borda el capital de SEO.

Fase 5: Migración de contenido

Duración: 1-4 semanas

La migración de contenido es trivialmente simple o pesadillescamente compleja. No hay término medio.

Migración automatizada

Para el contenido estructurado (entradas de blog, productos, miembros del equipo), escribe scripts de migración:

// Script simplificado de migración de WordPress a Sanity
import { createClient } from '@sanity/client'
import { wpClient } from './wordpress-api'

const sanity = createClient({
  projectId: 'your-project',
  dataset: 'production',
  token: process.env.SANITY_WRITE_TOKEN,
  apiVersion: '2026-01-01',
})

async function migratePosts() {
  const wpPosts = await wpClient.posts().perPage(100).get()
  
  for (const post of wpPosts) {
    await sanity.create({
      _type: 'blogPost',
      title: post.title.rendered,
      slug: { current: post.slug },
      // Transformar el HTML de WordPress a Portable Text
      body: htmlToPortableText(post.content.rendered),
      publishedAt: post.date,
    })
  }
}

El paso htmlToPortableText es donde las cosas se complican. El contenido de WordPress está lleno de shortcodes, estilos en línea y marcado específico de plugins que no se mapea limpiamente a contenido estructurado. Reserva tiempo para la limpieza.

Trabajo manual de contenido

Parte del contenido simplemente necesita atención humana:

  • Páginas con diseños complejos construidos en Elementor, Divi o WPBakery
  • Contenido con shortcodes incrustados de plugins desactivados
  • Medios que necesitan reoptimización o texto alternativo
  • Enlaces internos que necesitan actualización

Para un sitio de 500 páginas, planifica entre 40 y 80 horas de trabajo manual de contenido. Sí, en serio.

Fase 6: QA y pruebas

Duración: 1-3 semanas

No escatimes en esto. He visto lanzamientos retrasados meses porque el QA fue tratado como una ocurrencia tardía.

Lista de verificación de QA

  • Pruebas funcionales: Cada formulario, cada elemento interactivo, cada función dinámica
  • Pruebas entre navegadores: Chrome, Firefox, Safari, Edge. Safari siempre tiene algo raro.
  • Pruebas en dispositivos móviles: Dispositivos reales, no solo Chrome DevTools. Prueba en iPhones y dispositivos Android reales.
  • Verificación de contenido: Revisar al menos el 20% del contenido migrado en busca de problemas de formato
  • Auditoría de SEO: Comparar las metaetiquetas antiguas con las nuevas. Verificar los datos estructurados. Probar todas las redirecciones.
  • Pruebas de rendimiento: Puntuaciones de Lighthouse, Core Web Vitals en el campo, pruebas de carga con herramientas como k6
  • Accesibilidad: Cumplimiento de WCAG 2.2 AA. Ejecuta axe-core, pero también realiza pruebas de navegación solo con teclado.
  • Verificación de analítica: Asegúrate de que el seguimiento se dispara correctamente en todos los eventos

Pruebas de redirecciones

Esto merece su propio apartado. Exporta cada URL del sitio antiguo. Mapea cada una a su nueva URL. Prueba cada redirección individual. Para sitios empresariales con miles de URLs, usa pruebas automatizadas:

# Probar redirecciones con curl
while IFS=, read -r old_url new_url; do
  status=$(curl -o /dev/null -s -w "%{http_code}" -L "$old_url")
  final=$(curl -o /dev/null -s -w "%{url_effective}" -L "$old_url")
  echo "$old_url -> $final (Status: $status)"
done < redirects.csv

Fase 7: Lanzamiento y post-lanzamiento

Duración: 1-2 semanas

Día del lanzamiento

Prefiero lanzar un martes o miércoles por la mañana. Nunca el viernes (no quieres depurar durante el fin de semana) y nunca el lunes (la gente todavía está poniéndose al día del fin de semana).

Lista de verificación para el lanzamiento:

  • Cambios de DNS (el TTL debe reducirse 48 horas antes)
  • Verificación del certificado SSL
  • Calentamiento de la caché del CDN
  • Monitorear las tasas de error durante las primeras 4 horas
  • Verificar Google Search Console en busca de errores de rastreo
  • Comprobar que todas las integraciones de terceros están funcionando

Post-lanzamiento (2 semanas)

  • Monitorear Core Web Vitals en Google Search Console
  • Estar atento a errores 404 y añadir las redirecciones faltantes
  • Hacer seguimiento del rendimiento de búsqueda orgánica diariamente durante el primer mes
  • Recopilar comentarios de los editores de contenido sobre el nuevo CMS
  • Abordar cualquier caso límite que se haya escapado durante el QA

Una caída temporal del tráfico orgánico del 5-15% es normal después de una migración importante. Debería recuperarse en 2-4 semanas si las redirecciones y el SEO se gestionan correctamente. Si no se recupera, algo salió mal con el mapeo de redirecciones o la paridad de contenido.

Retrasos comunes y cómo evitarlos

Después de docenas de migraciones, estos son los verdaderos asesinos del cronograma:

Expansión del alcance durante el desarrollo: "Ya que estamos, ¿podemos añadir también un portal para clientes?" Sí, pero eso es un proyecto aparte. La expansión del alcance añade en promedio entre 3 y 6 semanas a las migraciones.

Disponibilidad de las partes interesadas: Revisiones de diseño que permanecen en la bandeja de entrada de alguien durante dos semanas. Presupuesta el tiempo de calendario en consecuencia y establece SLAs claros para las rondas de retroalimentación.

Brechas de funcionalidad de plugins: Ese oscuro plugin de WordPress que hace algo crítico y que nadie documentó. El descubrimiento debería detectar esto, pero a veces las cosas se escapan.

Formación de los editores de contenido: Si tu equipo no puede usar el nuevo CMS, no has terminado la migración. Presupuesta 1-2 días para la formación y la documentación.

Perfeccionismo en la migración de contenido: Parte del contenido no vale la pena migrar. ¿Entradas de blog de 2014 con cero tráfico? Déjalas ir. Configura una redirección al índice del blog y sigue adelante.

Expectativas de costos para 2026

Déjame darte números honestos. Las tarifas de las agencias para este trabajo en 2026:

Tamaño del sitio Cronograma Costo estimado (Agencia) Costo estimado (Freelancer)
Pequeño 3-6 semanas $15.000-$35.000 $8.000-$18.000
Mediano 8-16 semanas $40.000-$90.000 $25.000-$55.000
Grande 3-5 meses $80.000-$200.000 $50.000-$120.000
Empresa 4-8 meses $150.000-$500.000+ Raramente apropiado

Estos rangos reflejan lo que hemos visto en el mercado. La variación es enorme porque "sitio mediano" puede significar cosas muy diferentes. Un sitio de 200 páginas con un blog simple y un formulario de contacto es muy diferente de un sitio de 200 páginas con contenido multilingüe, e-commerce y un portal de membresía.

Si quieres hablar sobre tu situación específica, nuestra página de precios describe nuestros modelos de colaboración, o puedes contactarnos directamente para obtener una estimación detallada.

Preguntas frecuentes

¿Cuánto tiempo lleva una migración simple de WordPress a Next.js? Un sitio de marketing pequeño (menos de 50 páginas) con tipos de contenido estándar e integraciones mínimas generalmente tarda entre 3 y 6 semanas desde el inicio hasta el lanzamiento. Esto asume un equipo de 2 a 3 desarrolladores trabajando sin cambios importantes de diseño. Si también estás rediseñando, añade de 2 a 3 semanas para la fase de diseño.

¿Puedo migrar de WordPress a Next.js sin perder posicionamiento en SEO? Absolutamente, pero requiere una planificación cuidadosa. Los elementos críticos son: mantener las estructuras de URL donde sea posible, implementar redirecciones 301 para cualquier URL que cambie, preservar todas las metaetiquetas y datos estructurados, y asegurarse de que el nuevo sitio tenga paridad de contenido con el antiguo. Una caída temporal del 5-15% en el tráfico orgánico es normal y debería recuperarse en 2-4 semanas. El mayor factor de riesgo son las redirecciones faltantes — un mapeo de redirecciones mal hecho puede hundir el tráfico de una sección de tu sitio.

¿Debería usar WordPress como CMS headless con Next.js o cambiar a un CMS diferente? Depende de tu equipo. Si tus editores de contenido están muy familiarizados con WordPress y son reacios al cambio, WordPress headless con WPGraphQL es un punto intermedio razonable. Obtienes los beneficios del frontend de Next.js mientras mantienes la interfaz de administración familiar. Sin embargo, sigues cargando con la carga de mantenimiento de WordPress (actualizaciones, parches de seguridad, hosting). Si estás abierto al cambio, los CMS headless diseñados específicamente para ello, como Sanity, Contentful o Storyblok, ofrecen mejor contenido estructurado, colaboración en tiempo real y menos carga operativa.

¿Cuáles son los mayores riesgos durante una migración de CMS? Los tres principales son: regresión de SEO por un mapeo deficiente de redirecciones (corregible pero costoso en tráfico perdido), desbordamiento del cronograma por un descubrimiento inadecuado (generalmente porque la complejidad oculta emerge a mitad del desarrollo) y fracaso en la adopción por parte de los editores (tu equipo se niega a usar el nuevo CMS porque es demasiado diferente o no fue construido teniendo en cuenta sus flujos de trabajo). Los tres son prevenibles con una planificación adecuada.

¿Cuánto cuesta migrar de WordPress a Next.js en 2026? Los costos de las agencias oscilan entre $15.000 para un sitio de folleto pequeño y más de $500.000 para grandes migraciones empresariales con integraciones complejas. La mediana para sitios de empresas medianas es aproximadamente $50.000-$90.000 en una agencia especializada. Las tarifas de los freelancers son típicamente un 40-60% más bajas, pero conllevan un mayor riesgo en términos de disponibilidad y gestión de proyectos. El costo está impulsado principalmente por el número de plantillas únicas, la complejidad de las integraciones y el volumen de contenido que necesita atención manual.

¿Necesito migrar todo mi contenido de una vez? No, y de hecho una migración por fases a menudo reduce el riesgo. Algunos equipos comienzan moviendo sus páginas de marketing a Next.js mientras mantienen el blog en WordPress, y luego migran el blog en una segunda fase. Puedes usar reglas de proxy inverso para servir diferentes secciones desde diferentes orígenes bajo el mismo dominio. Este enfoque añade cierta complejidad arquitectónica, pero permite lanzar más rápido y validar el enfoque antes de comprometerse por completo.

¿Cuál es la diferencia entre un replatform y un rediseño? Un replatform mueve el diseño y el contenido de tu sitio existente a una nueva tecnología (WordPress a Next.js) con cambios visuales mínimos. Un rediseño cambia el aspecto, la sensación y potencialmente la arquitectura de la información. Combinar ambos en un solo proyecto es común, pero añade entre un 30 y un 50% al cronograma. Si el presupuesto o el tiempo son limitados, recomiendo hacer primero el replatform y luego rediseñar de forma iterativa una vez que estés en la nueva plataforma.

¿Puedo usar Astro en lugar de Next.js para mi migración? Sí, y para sitios con mucho contenido y mínima interactividad, Astro puede ser una excelente elección. Astro no envía JavaScript por defecto y admite hidratación parcial ("arquitectura de islas"), lo que significa que tus páginas de contenido cargan increíblemente rápido. Next.js es mejor cuando necesitas mucha interactividad del lado del cliente, autenticación o funciones en tiempo real. Hemos realizado migraciones a ambos frameworks, y la elección correcta depende completamente de los requisitos de tu sitio.