Migré mi sitio 47 de WordPress la semana pasada. La regla de decisión que nunca me ha fallado: si pasas más tiempo lidiando con WordPress que construyendo funcionalidades, vete.

Sé que suena reduccionista. Pero después de años construyendo en WordPress — y años sacando proyectos de él — he destilado la pregunta "¿debería quedarme o irme?" en algo más estructurado. Un marco de cinco preguntas que te da una respuesta honesta y cuantificable. Sin intuiciones. Sin lealtad tribal a PHP o React. Solo una lista de verificación que se asigna a puntos de dolor reales.

Permíteme que te lo explique, y luego hablaremos sobre dónde ir, qué cuesta, y los errores que arruinarán tu migración si no tienes cuidado.

Tabla de contenidos

El marco de 5 preguntas: ¿Deberías dejar WordPress?

He usado este marco con clientes, con mis propios proyectos, y con equipos de desarrollo evaluando su stack. Cinco preguntas de sí o no. Cada una se dirige a una categoría específica de dolor en WordPress — inflación de plugins, costo, seguridad, rendimiento, y velocidad.

1. ¿Tienes más de 20 plugins activos?

Veinte es el número. No porque haya algo mágico en ello, sino porque ese es el umbral donde WordPress deja de ser un CMS y se convierte en un monstruo de Frankenstein sostenido por hooks add_filter y plegarias.

Cada plugin es una dependencia que no controlas. Cada actualización de plugin es un cambio potencialmente importante. Y en 2026, el ecosistema de plugins de WordPress tiene un problema de seguridad que es difícil de ignorar: Patchstack reportó más de 11,300 CVEs de plugins en 2025 solo, un aumento del 42% respecto al año anterior. Más plugins significa más superficie de ataque.

Ve y cuenta tus plugins activos ahora mismo. Esperaré.

Si estás en 30+, casi con seguridad estás ejecutando plugins que duplican funcionalidad, entran en conflicto entre sí, o existen solo porque WordPress no hace de forma nativa algo que los frameworks modernos manejan de serie — cosas como optimización de imágenes, caché, etiquetas SEO, o manejo de formularios.

2. ¿Estás pagando más de $100/mes por hosting administrado?

WordPress es software "gratuito" que de alguna manera cuesta una fortuna de alojar bien. Si estás en WP Engine, Kinsta, o Flywheel, probablemente estés pagando $30-$115/mes por un sitio único. Escala eso a 5-10 sitios y estás buscando $300-$600/mes.

Mientras tanto, un sitio generado estáticamente en Vercel o Netlify? El nivel gratuito maneja la mayoría de los sitios de marketing. Incluso una configuración headless CMS + Next.js en Vercel Pro es $20/mes. No es una comparación directa (WordPress incluye una base de datos, UI de administración, etc.), pero ese es el punto — estás pagando por infraestructura que tal vez no necesites.

Si tu factura de hosting te hace muecas, esa es una señal.

3. ¿Has sido hackeado o has tenido tiempo de inactividad en los últimos 12 meses?

Esta es una pregunta binaria y importa más de lo que la mayoría de desarrolladores admiten. WordPress impulsa ~40% de la web, lo que lo convierte en el objetivo más grande para ataques automatizados. Intentos de fuerza bruta de login, inyección SQL a través de plugins desactualizados, malware inyectado mediante temas nulos — he visto todo.

Si has sido hackeado, conoces el procedimiento: escaneo de Sucuri, limpieza de base de datos, rotaciones de contraseña, pánico del cliente. Si has tenido tiempo de inactividad porque una actualización de plugin rompió tu sitio a las 2 AM, también sabes esa sensación.

Los sitios estáticos modernos y las aplicaciones renderizadas en servidor sin panel administrativo público simplemente no tienen esta superficie de ataque. No hay /wp-admin para ataque de fuerza bruta. No hay xmlrpc.php para explotar. El modelo de seguridad es fundamentalmente diferente.

4. ¿Están fallando tus Core Web Vitals en dispositivos móviles?

Los Core Web Vitals de Google son lo básico para SEO en 2026. Y los sitios de WordPress consistentemente luchan aquí. Un análisis de HTTP Archive de 2025 mostró que aproximadamente el 71% de los orígenes de WordPress fallaron la evaluación de CWV móvil — comparado con tasas de aprobación significativamente mejores para sitios construidos en frameworks como Next.js y Astro.

¿El culpable? CSS de bloqueo de renderizado de temas y plugins. Imágenes sin optimizar servidas sin formatos modernos. Tamaño excesivo del DOM desde constructores de páginas. JavaScript que no era necesario en primer lugar. Puedes lanzar plugins de caché al problema, pero estás tratando síntomas, no causas.

Ejecuta tu sitio a través de PageSpeed Insights. Si tu LCP móvil está por encima de 2.5 segundos y tu CLS está fallando, WordPress mismo podría ser el cuello de botella.

5. ¿Quiere tu equipo enviar funcionalidades más rápido de lo que WordPress permite?

Esta es la pregunta que más importa a los equipos de ingeniería. El modelo de desarrollo de WordPress — plantillas PHP, el loop, hooks y filters, la API de bloque Gutenberg — es una forma específica de construir. No es mala. Pero es lenta comparada con el desarrollo basado en componentes con React, Vue, o Svelte.

Si tu equipo pasa más tiempo:

  • Lidiando con la arquitectura React-pero-no-realmente del Block Editor
  • Escribiendo PHP personalizado para trabajar alrededor de limitaciones de tema
  • Depurando conflictos de plugins después de actualizaciones
  • Esperando invalidación de caché de página completa

...que en realidad construyendo funcionalidades que tus usuarios quieren, esa es tu respuesta.

Los frameworks modernos te permiten enviar más rápido. Eso no es opinión — es física. Las arquitecturas basadas en componentes con hot module reloading, TypeScript, y contenido impulsado por API superan el loop de desarrollo de WordPress en velocidad de iteración cada vez.

Calificando tus respuestas

Aquí está la matriz de decisión. Simple a propósito:

Respuestas de sí Recomendación Justificación
0-1 Quédate en WordPress Tus problemas son manejables. Optimiza lo que tienes.
2 Quédate, pero planifica Comienza a prototipizar alternativas. Estás acercándote al punto de inflexión.
3 Comienza a migrar El dolor es real y no va a desaparecer. Comienza a planificar tu salida.
4-5 Vete ahora WordPress te está costando activamente tiempo, dinero, y seguridad. Prioriza la migración.

He aplicado esto a probablemente 60+ proyectos en este punto. Nunca me ha dado un falso positivo. ¿Los clientes que puntuaron 3+ y se quedaron en WordPress? Volvieron 6-12 meses después, y la migración fue más difícil y cara para entonces.

A dónde migrar (asignado por caso de uso)

Aquí es donde la mayoría de artículos "dejar WordPress" se caen. Te dirán que uses Next.js para todo, o listarán 15 opciones de CMS sin decirte cuál se ajusta a tu situación. Déjame ser específico.

Sitios de marketing y blogs

Stack recomendado: Astro + un CMS headless (Sanity, Storyblok, o Contentful)

Astro fue básicamente diseñado para reemplazar WordPress para sitios de contenido. Envía cero JavaScript por defecto, genera HTML estático, y soporta hidratación parcial para componentes interactivos. Tus puntuaciones de lighthouse pasarán de "decepcionante" a "perfecta" de la noche a la mañana.

Construimos muchos de estos en Social Animal — nuestras capacidades de desarrollo de Astro están fuertemente orientadas hacia exactamente esta ruta de migración. Empareja Astro con Sanity Studio y tus editores de contenido obtienen una experiencia de autoría mejor que la que WordPress nunca les dio.

Comercio electrónico

Stack recomendado: Next.js + Shopify (headless) o Medusa.js

Si estás ejecutando WooCommerce, ya sabes el dolor. WooCommerce es potente pero frágil bajo carga, lento sin infraestructura seria de caché, y caro de personalizar. La API de Storefront de Shopify con un frontend de Next.js te da funcionalidad de carrito, checkout, y gestión de inventario sin ejecutar tu propia base de datos.

Para equipos que quieren control total y auto-alojamiento, Medusa.js ha madurado significativamente en 2026 y vale la pena evaluar.

Aplicaciones web (dashboards, portales, SaaS)

Stack recomendado: Next.js (App Router) + CMS headless para secciones de contenido + tu propia API

Si has estado hackeando WordPress en una aplicación con tipos de post personalizados, ACF, y puntos finales REST API... detente. WordPress nunca fue pensado para ser un framework de aplicación. Next.js con server components, server actions, y middleware te da una arquitectura de aplicación real.

Sitios editoriales de alto contenido

Stack recomendado: Next.js o Astro + Sanity o Strapi

Los equipos editoriales necesitan modelado de contenido estructurado, vistas previas de borradores, y edición colaborativa. Aquí es donde un CMS headless brilla. La colaboración en tiempo real de Sanity está años por delante del editor Gutenberg de WordPress. Strapi te da una opción auto-alojada con un panel administrativo limpio.

Caso de uso Frontend recomendado CMS recomendado Alojamiento Costo mensual estimado
Sitio de marketing / blog Astro Sanity o Contentful Vercel / Netlify $0-$20
Comercio electrónico Next.js API de Storefront de Shopify Vercel $29-$79 (Shopify) + $20 (Vercel)
Aplicación web Next.js Sanity (para contenido) Vercel / AWS $20-$100
Editorial / publicación Next.js o Astro Sanity o Strapi Vercel $0-$99

Compara eso con tu factura actual de WordPress. Para la mayoría de equipos, los costos de infraestructura caen entre 30-60%.

Timeline y costo de migración (números reales)

Te voy a dar los números que nadie quiere publicar porque tienen miedo de asustar a los clientes. Estos se basan en migraciones reales que hemos hecho y observado en 2025-2026.

Sitio pequeño (menos de 50 páginas, blog simple)

  • Timeline: 3-5 semanas
  • Costo: $5,000-$12,000 (agencia) / 40-80 horas (in-house)
  • Tareas clave: Exportación y reestructuración de contenido, reconstrucción de plantillas en Astro/Next.js, configuración de CMS, mapeo de redirecciones, cambio de DNS
  • Parte más difícil: Extrayendo contenido de shortcodes de page builder. Si tu contenido está lleno de blobs [vc_row] o JSON de Elementor, presupuesta tiempo extra para limpieza de contenido.

Sitio mediano (50-200 páginas, múltiples tipos de contenido)

  • Timeline: 6-10 semanas
  • Costo: $15,000-$35,000 (agencia) / 120-250 horas (in-house)
  • Tareas clave: Todo lo anterior, más modelado de contenido en el CMS headless, desarrollo de componentes personalizados, migraciones de formularios, reconfiguración de integración de terceros (análisis, marketing por correo, CRM)
  • Parte más difícil: Reconstruyendo grupos de campos ACF personalizados y relaciones en un nuevo modelo de contenido. Aquí es donde la mayoría de estimaciones de timeline explotan.

Sitio grande (200+ páginas, comercio electrónico, funcionalidad personalizada)

  • Timeline: 12-20 semanas
  • Costo: $40,000-$80,000+ (agencia) / 400-800+ horas (in-house)
  • Tareas clave: Auditoría completa de contenido, estrategia de migración en fases, scripts de migración de datos, migración de plataforma de comercio electrónico, migración de cuenta de usuario, preservación de SEO (redirecciones, sitemap, datos estructurados)
  • Parte más difícil: No romper SEO. Los sitios grandes han acumulado años de backlinks, páginas indexadas, y autoridad de búsqueda. Un mapa de redirecciones metido puede hundirte en tráfico orgánico durante meses.

Estos números podrían parecer altos, pero compáralos con el costo total de propiedad de quedarse en WordPress por otros 3 años: hosting administrado ($100-$300/mes × 36 = $3,600-$10,800), licencias de plugins premium ($500-$2,000/año × 3 = $1,500-$6,000), respuesta a incidentes de seguridad ($2,000-$10,000 por incidente), y tiempo de desarrollador gastado en mantenimiento en lugar de funcionalidades.

Si quieres hablar de detalles específicos para tu proyecto, nuestra página de precios explica cómo abordamos esto, y siempre puedes comunicarte directamente.

Los 3 errores que matan las migraciones de WordPress

He visto estos matar migraciones de muerto. No "causar retrasos" — matarlas. Como en, el equipo se rinde y vuelve a WordPress, habiendo malgastado meses y decenas de miles de dólares.

Error 1: Migrar contenido sin reestructurarlo

El error más grande es tratar la migración como un trabajo de copiar-pegar. Exportas tus posts y páginas de WordPress, los importas a un nuevo CMS, y reconstruyes las mismas plantillas. Esto te da la misma arquitectura de contenido desordenada en una caja más brillante.

El punto completo de migrar es reestructurar. WordPress fomenta un modelo de contenido plano: posts, páginas, y tipos de post personalizados con campos ACF pegados. Un CMS headless te permite definir modelos de contenido adecuados con campos tipados, referencias, y validación.

Dedica tiempo a auditar tu contenido antes de escribir una sola línea de código. ¿Qué tipos de contenido realmente necesitas? ¿Qué campos importan? ¿Qué páginas pueden consolidarse o eliminarse? He visto sitios de WordPress de 200 páginas reducidos a 60 páginas de contenido bien estructurado durante la migración — sin pérdida de valor.

Error 2: Ignorando el mapa de redirecciones

Las URLs de WordPress siguen un patrón específico (/2024/03/post-title/, /category/uncategorized/, etc.). Tu nuevo sitio tendrá patrones de URL diferentes. Cada URL antigua necesita redirigir a su equivalente nueva, o pierdes el valor de SEO que esas páginas han acumulado.

Este es trabajo tedioso e ingrato. Es también la tarea técnica más importante en toda la migración. Usa una herramienta de rastreo como Screaming Frog para exportar cada URL indexada, asigna cada una a su nuevo destino, e implementa redirecciones 301.

// next.config.js — ejemplo de mapeo de redirecciones
const nextConfig = {
  async redirects() {
    return [
      {
        source: '/2024/03/old-post-slug/',
        destination: '/blog/new-post-slug',
        permanent: true,
      },
      {
        source: '/category/:slug',
        destination: '/topics/:slug',
        permanent: true,
      },
      // ... potencialmente cientos de estos
    ];
  },
};

Para sitios grandes, querrás generar estos programáticamente desde tu exportación de contenido en lugar de asignarlos a mano.

Error 3: No darle a los editores un CMS antes del lanzamiento

A los desarrolladores les encantan las migraciones. A los editores de contenido las odian. Estás quitando la herramienta que conocen (WordPress) y entregándoles algo desconocido. Si no involucras a tus editores temprano — entrenándolos en el nuevo CMS, obteniendo su retroalimentación en el flujo de trabajo de autoría de contenido, asegurándote de que puedan publicar sin ayuda de desarrollador — se rebelarán.

He visto una migración ser cancelada dos semanas antes del lanzamiento porque el equipo de marketing dijo "no podemos trabajar con esto". El equipo de desarrollo había construido un hermoso sitio Astro con Sanity Studio, pero nadie había mostrado a los editores cómo funcionaba Sanity hasta la semana del lanzamiento.

Trae tu equipo de contenido en la semana 2, no en la semana 10. Déjales crear contenido de prueba en el nuevo CMS. Escucha sus quejas. Ajusta la configuración del estudio. Esto es lo que hace o rompe la adopción.

Preguntas frecuentes

¿Cómo sé que es hora de dejar WordPress?

Usa el marco de cinco preguntas anterior. Si respondes "sí" a tres o más de las preguntas — más de 20 plugins, hosting superior a $100/mes, incidentes de seguridad, Core Web Vitals fallando, o tu equipo no puede enviar lo suficientemente rápido — es hora. El marco no se trata de odiar WordPress. Se trata de evaluar honestamente si la plataforma te está ayudando o frenando. ¿Dos o menos? WordPress probablemente sigue siendo correcto para tus necesidades, y deberías enfocarte en optimizar lo que tienes.

¿Cuál es la alternativa de WordPress más barata?

Astro con un CMS headless de nivel gratuito (el plan gratuito de Sanity soporta 3 usuarios, el plan gratuito de Contentful soporta 5 usuarios) implementado en Netlify o nivel gratuito de Vercel. Costo total: $0/mes. En serio. Para un sitio de marketing o blog, este stack es listo para producción y funciona mejor que una configuración de WordPress administrado de $100/mes. La trampa es que necesitas un desarrollador cómodo con Astro y el CMS de tu elección — pero si estás leyendo este artículo, probablemente seas tú.

¿Cuánto tiempo lleva migrar desde WordPress?

Para un sitio típico pequeño (menos de 50 páginas), espera 3-5 semanas. Sitios medianos con 50-200 páginas y múltiples tipos de contenido ejecutan 6-10 semanas. Sitios grandes con comercio electrónico o funcionalidad personalizada compleja pueden tomar 12-20 semanas. La variable más grande no es código — es contenido. Si tu contenido es limpio y bien estructurado, la migración va rápido. Si está atrapado en shortcodes de page builder y grupos de campos ACF profundamente anidados, presupuesta tiempo extra para extracción y reestructuración.

¿Perderé SEO si migro desde WordPress?

Podrías, pero no si lo haces bien. El paso crítico es implementar un mapa completo de redirecciones 301 de cada URL antigua a su equivalente nueva. También necesitas preservar tus títulos meta, descripciones, y datos estructurados (schema markup). Rastrea tu sitio existente con Screaming Frog antes de la migración, exporta todas las URLs indexadas, y verifica que cada redirección funcione después del lanzamiento. La mayoría de migraciones bien ejecutadas ven una fluctuación temporal de 2-4 semanas en clasificaciones, seguida de mejora gracias a mejores Core Web Vitals.

¿Puedo usar WordPress como un CMS headless en lugar de migrar completamente?

Sí, y esto es un paso intermedio válido. La REST API de WordPress (o WPGraphQL) te deja usar WordPress como un backend de contenido mientras construyes un frontend moderno en Next.js o Astro. Este enfoque deja que tus editores mantengan usando el admin de WordPress que conocen mientras tu equipo de desarrollo construye un frontend más rápido. Las desventajas: aún mantienes una instalación de WordPress (con toda su seguridad y sobrecarga de actualizaciones), y la REST API puede ser lenta sin caché. Recomendaría esto como un paso intermedio, no como un destino.

¿Qué pasa con mis plugins de WordPress cuando migro?

Se van — y ese es el punto. La mayoría de plugins existen para llenar vacíos en WordPress (SEO, caché, formularios, optimización de imágenes, seguridad). En un stack moderno, estos se manejan por el framework o herramientas de construcción. Next.js tiene optimización de imágenes incorporada. Astro envía cero JS por defecto. Los formularios de contacto pueden usar servicios como Formspree o Resend. El análisis se mueve a Plausible o Vercel Analytics. Necesitarás auditar tu lista de plugins y mapear cada uno a su reemplazo en el nuevo stack.

¿Debo migrar todo a la vez o en fases?

Para sitios bajo 100 páginas, migra todo a la vez. La sobrecarga de coordinación de ejecutar dos sistemas simultáneamente no vale la pena. Para sitios grandes (200+ páginas), considera un enfoque en fases: migra primero las páginas de marketing y el blog, mantén secciones complejas (comercio electrónico, portales de usuario) en WordPress temporalmente, y usa reglas de proxy inverso para servir ambas desde el mismo dominio. Esto reduce el riesgo pero aumenta la complejidad arquitectónica.

¿Necesito una agencia para migrar desde WordPress, o puedo hacerlo yo mismo?

Depende del sitio. Un desarrollador cómodo con Next.js o Astro puede migrar un blog simple en pocos fines de semana. Pero para sitios con modelos de contenido complejos, comercio electrónico, funcionalidad personalizada, o apuestas altas de SEO, trabajar con un equipo que ha hecho esto antes ahorra tiempo y dinero reales. Hemos hecho docenas de estas migraciones — los patrones son predecibles y los peligros son bien conocidos. Revisa nuestras capacidades o comunícate directamente si quieres hablar sobre tu situación específica.