Tu equipo de desarrollo abre el admin de WordPress y exporta 847 posts, 12 tipos de post personalizados y 3.200 archivos de medios. El dump de la base de datos alcanza 4.2GB. Alguien pregunta cuánto tiempo tarda realmente esta migración, no la estimación pulida del deck de inicio, sino el cronograma que cuenta con shortcodes rotos, desajustes de campos ACF y el mapa de redirecciones que crece de 200 filas a 1.800 en la segunda semana. He liderado más de 40 migraciones de CMS en cinco años, la mayoría de WordPress a Next.js. La respuesta depende de cuatro variables que la mayoría de agencias no mencionan hasta que ya estás dentro. Aquí está lo que realmente determina si entregas en 3 semanas o 6 meses.

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

Pero esos rangos son inútiles sin contexto. Déjame desglosar exactamente qué sucede en cada fase, dónde los equipos pierden tiempo y cómo mantener tu migración sin que se convierta en una de esas historias de horror que se arrastran durante un año.

Tabla de Contenidos

Cronograma de Migración CMS: WordPress a Next.js en 2026

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

Séame directo: no todos los sitios de WordPress necesitan migrarse. Si ejecutas 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 se están moviendo a Next.js con un CMS headless en 2026:

  • Rendimiento: Los sitios Next.js con generación estática y renderizado edge consistentemente alcanzan 90+ en Core Web Vitals. Los sitios WordPress promedian alrededor de 50-65 sin trabajo de optimización significativo.
  • Seguridad: Desacoplar el frontend del CMS elimina los vectores de ataque más comunes de WordPress. En 2025, Sucuri reportó que WordPress representaba el 96.2% de los sitios CMS infectados.
  • Experiencia del desarrollador: La arquitectura de componentes basada en React significa iteración más rápida y contratación más fácil. El grupo de talento PHP de WordPress está disminuyendo -- la encuesta de 2025 de Stack Overflow mostró que PHP cayó al 14º lugar en popularidad de lenguajes.
  • Escalabilidad: Los sitios Next.js implementados en edge en Vercel o Cloudflare manejan picos de tráfico sin el enfoque de "veamos si echamos más servidor".

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

Cronograma de Migración por Tamaño de Sitio

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

Tamaño del Sitio Páginas Complejidad Típica Cronograma Tamaño del Equipo
Pequeño (Marketing/Brochure) 5-50 Baja -- pocas integraciones, contenido estándar 3-6 semanas 2-3 personas
Mediano (Negocios) 50-500 Mediana -- blog, formularios, algunas integraciones, múltiples plantillas 8-16 semanas 3-5 personas
Grande (Mid-Market) 500-5.000 Alta -- e-commerce, multi-autor, flujos de trabajo complejos 3-5 meses 4-7 personas
Empresa 5.000+ Muy Alta -- múltiples idiomas, integraciones heredadas, cumplimiento 4-8 meses 6-12 personas

Estos son cronogramas de construcción, no cronogramas de calendario. El tiempo de calendario siempre es más largo debido a revisiones de partes interesadas, ciclos de retroalimentación y las inevitables dos semanas donde el VP de Marketing está de vacaciones durante la fase de aprobación de diseño.

Fase 1: Descubrimiento y Auditoría

Duración: 1-3 semanas

Este es el punto donde la mayoría de agencias se apuran y donde la mayoría de migraciones se descarrilan. El descubrimiento no es solo "mira el sitio de WordPress y haz una lista". Es un trabajo forense.

Qué Sucede Realmente

  • Inventario de contenido: Cataloga todos los tipos de contenido, taxonomías, campos personalizados y archivos de medios. Uso Screaming Frog para rastrear el sitio existente y exportar un mapa completo de URL. Para un sitio de 2.000 páginas, esto solo toma un día completo para organizarlo adecuadamente.
  • Auditoría de plugins: Documenta todos los plugins activos y qué hacen. El sitio de WordPress promedio tiene 20-30 plugins. Cada uno representa funcionalidad que necesitas 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? ¿Analytics a través de Google Tag Manager con eventos personalizados? Dibuja la imagen completa.
  • Línea base SEO: Exporta todos los títulos meta, descripciones, URLs canónicas, datos estructurados y patrones de enlaces internos. No puedes permitirte perder equidad SEO durante la migración.
  • Entrevistas de partes interesadas: Habla con las personas que realmente usan el CMS diariamente. Editores de contenido, vendedores, quien sea que maneje el blog. Sus flujos de trabajo importan más que la arquitectura técnica.

Entregables de Descubrimiento

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

Saltar o apresurarse en el descubrimiento es la causa número uno de ampliaciones de cronograma. He visto una migración "rápida de 6 semanas" convertirse en un ordeal de 5 meses porque nadie documentó que el sitio de WordPress tenía 47 Gravity Forms personalizados con lógica condicional canalizando datos hacia tres CRM diferentes.

Cronograma de Migración CMS: WordPress a Next.js en 2026 - arquitectura

Fase 2: Arquitectura y Planificación

Duración: 1-2 semanas

Con los datos de descubrimiento en mano, tomas las decisiones importantes.

Elegir Tu CMS Headless

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

CMS Mejor 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, fuerte gobernanza $300/mes y más Moderada
Storyblok Edición visual, equipos de marketing Nivel gratuito, luego €106-€399/mes Baja
Payload CMS Orientado a desarrolladores, control auto-alojado Gratuito (código abierto), Cloud desde $50/mes Mayor
WordPress (Headless) Equipos que quieren mantener el admin de WordPress Costos de hosting existentes Baja (familiar)

Sí, puedes usar WordPress como un 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 algo de sobrecarga de mantenimiento de WordPress.

Ayudamos a los equipos a evaluar estas opciones como parte de nuestro trabajo de desarrollo de CMS headless. La opción correcta depende en gran medida de la 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 sitios en 2026 usan un híbrido -- ISR para páginas de contenido, SSR para páginas personalizadas o en tiempo real.
  • Hosting: Vercel es el predeterminado para Next.js, pero Netlify, Cloudflare Pages y AWS Amplify son todas viables. El plan Pro de Vercel a $20/usuario/mes cubre la mayoría de equipos.
  • Arquitectura de API: ¿Usarás la API nativa del CMS, construirás una capa de middleware, o irás con algo como tRPC para llamadas API type-safe?
  • Autenticación: Si tienes contenido bloqueado o áreas de miembros, planifica esto temprano. NextAuth.js (ahora Auth.js v5) maneja la mayoría de patrones.

Fase 3: Modelado de Contenido y Configuración CMS

Duración: 1-3 semanas

Aquí es donde construyes tu estructura de contenido en el nuevo CMS. No solo repliques tu estructura de WordPress -- esta es tu oportunidad para arreglar años de deuda de contenido acumulada.

Diseño de Modelo de Contenido

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

// Ejemplo: modelo de contenido 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 estructurado rico
    }),
    defineField({
      name: 'seo',
      type: 'seoFields', // Objeto SEO reutilizable
    }),
  ],
})

El contenido estructurado significa que el cuerpo de tu blog post no es solo un blob de HTML. Son bloques estructurados que tu frontend puede renderizar como quiera -- web, app móvil, boletín de correo, lo que sea.

Configuración CMS

  • Configura roles y permisos
  • Configura funcionalidad de vista previa (la vista previa en vivo en Next.js es esencial para la adopción del editor)
  • Construye cualquier componente de entrada personalizado o reglas de validación
  • Configura webhooks para activar reconstrucciones en cambios de contenido

Fase 4: Construcción Frontend

Duración: 2-8 semanas (la variable más grande)

Aquí es donde va la mayoría del tiempo de calendario. La construcción del frontend de Next.js implica:

Diseño y Sistema de Componentes

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

// Ejemplo: arquitectura impulsada por 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 una biblioteca de componentes primero, luego ensamblar páginas. Se siente más lento inicialmente pero paga enormemente cuando estás construyendo tu plantilla de página número 15.

Tareas Clave de Construcción

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

El mapeo de redirecciones solo puede tomar días en un sitio grande. Cada URL que cambia necesita una redirección, o estás tirando equidad SEO.

Fase 5: Migración de Contenido

Duración: 1-4 semanas

La migración de contenido es trivialmente simple o pesadillamente compleja. No hay punto medio.

Migración Automatizada

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

// Script de migración simplificado 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 },
      // Transforma HTML de WordPress a Texto Portátil
      body: htmlToPortableText(post.content.rendered),
      publishedAt: post.date,
    })
  }
}

El paso htmlToPortableText es donde las cosas se ponen espinosas. El contenido de WordPress está lleno de shortcodes, estilos inline y markup específico de plugins que no se mapea limpiamente al contenido estructurado. Presupuesta tiempo para limpieza.

Trabajo de Contenido Manual

Algo de contenido simplemente necesita atención humana:

  • Páginas con diseños complejos construidos en Elementor, Divi, o WPBakery
  • Contenido con shortcodes embebidos 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 40-80 horas de trabajo de contenido manual. Sí, en serio.

Fase 6: QA y Testing

Duración: 1-3 semanas

No escatimes en esto. He visto lanzamientos retrasados meses porque QA se trató como una idea tardía.

Lista de Verificación QA

  • Testing funcional: Cada formulario, cada elemento interactivo, cada característica dinámica
  • Testing entre navegadores: Chrome, Firefox, Safari, Edge. Safari siempre tiene algo extraño.
  • Testing móvil: Dispositivos reales, no solo Chrome DevTools. Prueba en iPhones y dispositivos Android reales.
  • Verificación de contenido: Verifica al menos el 20% del contenido migrado para problemas de formato
  • Auditoría SEO: Compara etiquetas meta antiguas con nuevas. Verifica datos estructurados. Prueba todas las redirecciones.
  • Testing de rendimiento: Puntuaciones de Lighthouse, Core Web Vitals en el campo, testing de carga con herramientas como k6
  • Accesibilidad: Cumplimiento WCAG 2.2 AA. Ejecuta axe-core, pero también haz testing de navegación solo por teclado.
  • Verificación de Analytics: Asegúrate de que el seguimiento se active correctamente en todos los eventos

Testing de Redirecciones

Esto merece su propio llamado. 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 testing automatizado:

# Testing de 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 de Lanzamiento

Prefiero lanzar un martes o miércoles por la mañana. Nunca viernes (no quieres depurar un fin de semana) y nunca lunes (la gente aún se está poniendo al día del fin de semana).

Lista de verificación de lanzamiento:

  • Cambios DNS (TTL debe reducirse 48 horas antes)
  • Verificación de certificado SSL
  • Precalentamiento de caché CDN
  • Monitorear tasas de error durante las primeras 4 horas
  • Verifica Google Search Console para errores de rastreo
  • Comprueba que todas las integraciones de terceros se están disparando

Post-Lanzamiento (2 semanas)

  • Monitorea Core Web Vitals en Google Search Console
  • Observa errores 404 y agrega redirecciones faltantes
  • Rastrea rendimiento de búsqueda orgánica diariamente durante el primer mes
  • Recopila comentarios de editores de contenido sobre el nuevo CMS
  • Aborda cualquier caso excepcional que se escapó del QA

Una caída de tráfico temporal del 5-15% en búsqueda orgánica es normal después de una migración importante. Debería recuperarse en 2-4 semanas si tus redirecciones y SEO se manejan adecuadamente. 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, aquí están los verdaderos asesinos de cronogramas:

Scope creep durante la construcción: "Mientras lo hacemos, ¿podemos también agregar un portal de clientes?" Sí, pero eso es un proyecto separado. Scope creep agrega un promedio de 3-6 semanas a las migraciones.

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

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

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

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

Expectativas de Costos para 2026

Te daré números honestos. Las tasas de agencia 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 varianza es enorme porque "sitio mediano" puede significar cosas muy diferentes. Un sitio de 200 páginas con un blog simple y 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 discutir tu situación específica, nuestra página de precios describe nuestros modelos de contratación, o puedes comunicarte directamente para una estimación definida.

FAQ

¿Cuánto tiempo toma 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 típicamente toma 3-6 semanas de inicio a lanzamiento. Esto asume un equipo de 2-3 desarrolladores trabajando sin cambios importantes de diseño. Si también estás rediseñando, suma 2-3 semanas para la fase de diseño.

¿Puedo migrar de WordPress a Next.js sin perder clasificaciones de SEO?

Absolutamente, pero requiere planificación cuidadosa. Los elementos críticos son: mantener estructuras de URL donde sea posible, implementar redirecciones 301 para cualquier URL que cambie, preservar todos los meta tags y datos estructurados, y garantizar que el nuevo sitio tenga paridad de contenido con el antiguo. Una caída temporal del 5-15% en tráfico orgánico es normal y debería recuperarse en 2-4 semanas. El factor de riesgo más importante es las redirecciones perdidas -- un mapeo de redirecciones mal hecho puede afectar el tráfico de una sección de tu sitio.

¿Debo usar WordPress como un CMS headless con Next.js o cambiar a un CMS diferente por completo?

Depende de tu equipo. Si tus editores de contenido conocen profundamente WordPress y son resistentes al cambio, WordPress headless con WPGraphQL es un término medio razonable. Obtienes los beneficios del frontend de Next.js mientras mantienes la interfaz de admin familiar. Sin embargo, aún cargas con la sobrecarga de mantenimiento de WordPress (actualizaciones, parches de seguridad, hosting). Si estás abierto al cambio, CMS headless específicos como Sanity, Contentful, o Storyblok ofrecen mejor contenido estructurado, colaboración en tiempo real y menos sobrecarga operativa.

¿Cuáles son los mayores riesgos durante una migración de CMS?

Los tres principales son: regresión SEO por mapeo de redirecciones pobre (reparable pero costoso en tráfico perdido), ampliación de cronograma por descubrimiento inadecuado (usualmente porque complejidad oculta emerge a mitad de la construcción), y fracaso de adopción del editor (tu equipo se niega a usar el nuevo CMS porque es muy diferente o no se construyó pensando en sus flujos de trabajo). Los tres son prevenibles con planificación adecuada.

¿Cuánto cuesta migrar de WordPress a Next.js en 2026?

Los costos de agencia van desde $15.000 para un pequeño sitio brochure hasta $500.000+ para migraciones empresariales grandes con integraciones complejas. La mediana para sitios de negocios de tamaño medio es aproximadamente $50.000-$90.000 en una agencia especializada. Las tasas de freelancer son típicamente 40-60% menores pero vienen con mayor riesgo alrededor de disponibilidad y gestión de proyectos. El costo es impulsado principalmente por el número de plantillas únicas, complejidad de integraciones y volumen de contenido que necesita atención manual.

¿Necesito migrar todo mi contenido a la 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, luego migran el blog en una segunda fase. Puedes usar reglas de proxy inverso para servir diferentes secciones de diferentes orígenes bajo el mismo dominio. Este enfoque agrega algo de complejidad arquitectónica pero te permite lanzar más rápido y validar el enfoque antes de comprometerte completamente.

¿Cuál es la diferencia entre una replatforma y un rediseño?

Una replatforma mueve el diseño y contenido del sitio existente a nueva tecnología (WordPress a Next.js) con cambios visuales mínimos. Un rediseño cambia la apariencia, sensación e información arquitectura potencialmente. Combinar ambos en un proyecto es común pero suma 30-50% al cronograma. Si presupuesto o cronograma es ajustado, recomiendo replataformalizar primero, luego rediseñar iterativamente una vez estés en la nueva stack.

¿Puedo usar Astro en lugar de Next.js para mi migración?

Sí, y para sitios ricos en contenido con interactividad mínima, Astro puede ser una excelente opción. Astro no envía JavaScript por defecto y soporta 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 interactividad pesada del lado del cliente, autenticación, o características en tiempo real. Hemos hecho migraciones a ambos frameworks, y la opción correcta depende completamente de los requerimientos de tu sitio.