Por qué los usuarios de MODX deberían migrar a Next.js en 2026: Un análisis honesto
Tu instalación de MODX arranca en 1.2 segundos — respetable para un CMS PHP construido en 2005. Abres el panel de administración y notas que la última actualización del core fue hace once meses. El canal de Slack que solías frecuentar para pedir ayuda con snippets ahora recibe tres posts por semana, bajando de threads diarios en 2019. Tu desarrollador sugiere la idea de 'explorar opciones' durante standup, y sabes lo que eso significa.
Trabajé con MODX Evolution durante seis años. Escribí snippets personalizados, luché con variables de plantilla hasta las 2 a.m., y defendí su flexibilidad en pitches de agencia. Esta no es una crítica malintencionada. Es reconocimiento de patrones: el abandono de plugins se aceleró un 40% entre 2024 y ahora, los proveedores de hosting han deprecado silenciosamente los stacks optimizados para MODX, y la brecha entre lo que tu sitio puede hacer versus lo que esperan los prospectos se ha convertido en un abismo. La pregunta no es si migrar — es si te mueves ahora o esperas hasta que algo falle durante el lanzamiento de una campaña.
Pero aquí está el punto: el mundo del desarrollo web ha avanzado, y MODX no se ha mantenido al día. La comunidad se está reduciendo, el ciclo de lanzamiento se ha ralentizado a paso de tortuga, y el grupo de talentos se está secando más rápido que un charco en julio. Si aún ejecutas sitios de producción en MODX en 2026, necesitas considerar seriamente tu estrategia de salida. Y para la mayoría de equipos, esa salida conduce a Next.js.
Te guiaré a través de por qué — honestamente, sin el hype.
Tabla de contenidos
- El estado de MODX en 2026
- Qué MODX hizo bien (y sigue haciendo)
- Los problemas que ya no puedes ignorar
- Por qué Next.js es el objetivo natural de migración
- La ruta de migración: MODX a Next.js
- Elegir un CMS headless para reemplazar MODX
- Ganancias de rendimiento reales: Antes y después
- Qué echarás de menos (y qué no)
- Comparación de costos: Ejecutar MODX vs Next.js
- Preguntas frecuentes
El estado de MODX en 2026
Veamos los números honestamente. MODX 3.x ha estado disponible por un tiempo, pero la adopción ha sido... tibia. Los foros de MODX, una vez bulliciosos de actividad, ahora ven quizás un puñado de posts por semana. El repositorio oficial de GitHub muestra una actividad de commits cada vez más escasa. Compáralo con 2018 o 2019 cuando la comunidad seguía empujando con fuerza.
Los datos de BuiltWith desde principios de 2026 estiman que MODX alimenta aproximadamente el 0.3% de sitios web detectados por CMS, bajando de alrededor del 0.7% en 2021. WordPress sigue dominando con ~62%, y nuevos jugadores como sitios basados en Next.js (a menudo emparejados con CMS headless) están creciendo aproximadamente un 40% año tras año.
El marketplace de MODX (anteriormente el repositorio de Extras) no ha visto una extensión nueva significativa en meses. Muchas extras populares están sin mantener o solo parcialmente compatibles con MODX 3.x. Cuando el ecosistema deja de producir, eso no es una bandera roja — es una bandera blanca.
No estoy diciendo que MODX esté muerto. Sigue funcionando. Tus sitios siguen en línea. Pero "sigue funcionando" es un lugar peligroso en el desarrollo web.
Qué MODX hizo bien (y sigue haciendo)
Antes de abrumar, crédito donde se debe. MODX acertó varias cosas que la mayoría de los CMS aún entienden mal:
Verdadera flexibilidad de contenido
MODX nunca te forzó a un paradigma de "post y página". Las variables de plantilla, chunks y snippets te dieron verdadera libertad de modelado de contenido años antes de que "contenido estructurado" se convirtiera en un término de moda. Podías construir cualquier cosa.
Salida limpia
MODX no inyectó su propio marcado. Sin clases CSS misteriosas, sin divs envoltorio que no pediste. Tu HTML era tu HTML. Para desarrolladores front-end que se preocupaban por la artesanía, esto fue una revelación.
Tematización amigable para desarrolladores
Sin sistema de temas para aprender, sin jerarquía de plantillas para memorizar. Escribías plantillas. Eso era. Los chunks eran partials reutilizables. Los snippets eran lógica PHP. Modelo mental simple, resultados poderosos.
La sintaxis de etiquetas
Di lo que quieras sobre [[*pagetitle]] y [[!MySnippet]] — una vez que la aprendiste, podías construir páginas complejas rápidamente. La capa de caché con la bandera uncached ! fue elegante.
Estas fortalezas en realidad hacen que los desarrolladores de MODX sean excelentes candidatos para arquitecturas headless modernas. Si ya piensas en contenido estructurado y plantillas basadas en componentes, ya estás a mitad de camino a Next.js.
Los problemas que ya no puedes ignorar
Aquí tengo que ser blunt.
Preocupaciones de seguridad
MODX 3.x abordó muchas vulnerabilidades históricas, pero ejecutar cualquier monolito PHP con un panel de administración público es un vector de riesgo inherente. En 2025, vimos al menos dos CVEs críticos afectando instalaciones de MODX, y los parches tardaron semanas en llegar. Con un equipo de seguridad reduciéndose, los tiempos de respuesta no están mejorando.
Compáralo con un sitio Next.js desplegado en Vercel o Netlify — literalmente no hay servidor para atacar. Sin panel de administración para fuerza bruta. Sin PHP para explotar. La superficie de ataque es fundamentalmente más pequeña.
La crisis de talento
Intenta contratar un desarrollador de MODX en 2026. Adelante. Publica el anuncio de trabajo y escucha los grillos. El grupo de desarrolladores ha migrado a React, Next.js y frameworks modernos de JavaScript. Incluso el talento de PHP va a Laravel, no a MODX.
Esto no es una preocupación teórica. He hablado con agencias que tienen sitios de MODX que literalmente no pueden encontrar desarrolladores para mantener. Cuando el desarrollador original se va, el sitio se convierte en un pasivo.
Dolores de cabeza de compatibilidad con PHP 8.x
MODX 3.x se ejecuta en PHP 8, pero muchas extras no. Si has construido un sitio que depende de snippets o plugins de terceros, actualizar PHP a menudo rompe cosas. Terminas fijado a versiones anteriores de PHP, lo que vuelve al problema de seguridad.
Sin experiencia de desarrollador moderna
Sin hot module reloading. Sin arquitectura basada en componentes. Sin soporte de TypeScript. Sin optimización de imágenes integrada. Sin renderizado de edge. Sin ISR. Podría seguir.
El flujo de trabajo de desarrollo de MODX es esencialmente: editar un archivo o un chunk en el manager (o en tu IDE mediante una herramienta de sincronización), limpiar el caché, actualizar el navegador. Funciona, pero es lento comparado con la DX moderna.
Techo de rendimiento
MODX puede ser rápido — he construido sitios sub-2-segundo en él. Pero llegar ahí requiere una optimización significativa: caché de página completa, configuración de CDN, ajuste de base de datos, y arquitectura cuidadosa de snippets. Next.js te da rendimiento sub-segundo esencialmente out-of-the-box con generación estática. Luchas por rendimiento en MODX; en Next.js, luchas por arruinarlo.
Por qué Next.js es el objetivo natural de migración
Podrías preguntar: ¿por qué no WordPress? ¿Por qué no Astro? ¿Por qué no solo un generador de sitios estáticos?
Todas opciones válidas, pero Next.js golpea el punto dulce para la mayoría de migraciones de MODX. Aquí está por qué:
La flexibilidad de renderizado refleja el pensamiento de MODX
Los desarrolladores de MODX ya entienden que diferentes páginas necesitan diferentes estrategias de caché. En MODX, marcarías snippets como cacheados o no cacheados. En Next.js, eliges entre Static Site Generation (SSG), Incremental Static Regeneration (ISR), y Server-Side Rendering (SSR) por página. Mismo concepto, mejor ejecución.
La arquitectura de componentes reemplaza los chunks
Los chunks de MODX son partials HTML reutilizables. Los componentes React son partials de UI reutilizables con lógica integrada. Si has estado escribiendo chunks como [[!$header]] y [[!$footer]], ya piensas en componentes. Solo que no tenías props.
Las rutas API reemplazan snippets
Los snippets de MODX manejan lógica del lado del servidor — procesamiento de formularios, llamadas de API, consultas personalizadas. Las rutas de API de Next.js (o Server Actions en Next.js 14+) hacen lo mismo pero en JavaScript/TypeScript con mejor herramientas y soporte para pruebas.
Para equipos considerando alternativas, Astro vale la pena evaluar para sitios con mucho contenido que no necesitan mucha interactividad. Pero si necesitas características dinámicas, experiencias autenticadas, o obtención de datos compleja, Next.js es la opción más fuerte.
La ruta de migración: MODX a Next.js
Seamos prácticos. Así es cómo funciona realmente una migración de MODX a Next.js.
Paso 1: Audita tu modelo de contenido
Mapea cada plantilla de MODX, variable de plantilla y tipo de recurso. Esto se convierte en tu modelo de contenido en cualquier CMS headless que elijas. Documenta todo:
## Recurso: Blog Post
- pagetitle → title (texto)
- longtitle → seo_title (texto)
- content → body (texto enriquecido)
- TV: hero_image → hero_image (media)
- TV: author → author (referencia)
- TV: category → category (taxonomía)
Paso 2: Exporta tu contenido
MODX no tiene una excelente herramienta de exportación. Probablemente necesitarás escribir un snippet personalizado o script que consulte modx_site_content y tus tablas de TV, luego saca JSON:
<?php
// Exportación de contenido de MODX rápida y sucia
$resources = $modx->getCollection('modResource', [
'published' => 1,
'deleted' => 0
]);
$output = [];
foreach ($resources as $resource) {
$output[] = [
'id' => $resource->get('id'),
'title' => $resource->get('pagetitle'),
'slug' => $resource->get('alias'),
'content' => $resource->get('content'),
'template' => $resource->get('template'),
'tvs' => $resource->getTemplateVars(),
'parent' => $resource->get('parent'),
'publishedon' => $resource->get('publishedon'),
];
}
header('Content-Type: application/json');
echo json_encode($output, JSON_PRETTY_PRINT);
Luego escribe scripts de importación para tu CMS objetivo. Es trabajo poco glamoroso, pero es un esfuerzo de una sola vez.
Paso 3: Construye tu front-end de Next.js
Comienza con create-next-app y construye tus plantillas como componentes de página. Tu mapeo de plantilla de MODX → layout de página podría verse así:
| Concepto de MODX | Equivalente en Next.js |
|---|---|
| Plantilla | Componente de layout |
| Chunk | Componente React |
| Snippet | Server Action / ruta API |
| Variable de plantilla | Campo de CMS |
| Recurso | Página / entrada de contenido |
[[*field]] tag |
Props / obtención de datos |
| Plugin (gancho de evento) | Middleware |
[[!uncached]] |
SSR / renderizado dinámico |
[[cached]] |
SSG / ISR |
Paso 4: Maneja redirecciones de URL
Aquí es donde la gente mete la pata. Cada URL antigua de MODX necesita un redireccionamiento 301 a su equivalente nuevo en Next.js. Construye un mapa de redirecciones y agrégalo a next.config.js:
// next.config.js
module.exports = {
async redirects() {
return [
{
source: '/old-modx-path.html',
destination: '/new-path',
permanent: true,
},
// ... cientos más, generados desde tu exportación
]
},
}
No saltes esto. Tu SEO depende de ello.
Paso 5: Ejecuta en paralelo durante 2-4 semanas
Despliega Next.js junto a tu sitio MODX existente. Prueba todo. Verifica análiticas. Verifica que los formularios funcionen. Luego cambia DNS.
Elegir un CMS headless para reemplazar MODX
Next.js es tu front-end, pero aún necesitas un lugar para gestionar contenido. Aquí está cómo se comparan las opciones populares para refugiados de MODX:
| CMS | Curva de aprendizaje para devs de MODX | Modelado de contenido | Precio (2026) | Opción auto-hospedada |
|---|---|---|---|---|
| Sanity | Medio | Excelente (esquemas definidos por código) | Free tier, luego $15/usuario/mes | No (solo cloud) |
| Strapi | Bajo | Bueno (basado en UI) | Gratis (auto-hospedado), Cloud desde $29/mes | Sí |
| Contentful | Medio | Bueno | Free tier, luego $300/mes | No |
| Payload CMS | Bajo | Excelente (esquemas definidos por código) | Gratis (auto-hospedado), Cloud desde $50/mes | Sí |
| Directus | Bajo | Flexible | Gratis (auto-hospedado), Cloud desde $99/mes | Sí |
Si te encantaba la flexibilidad de MODX y la capacidad de auto-hospedaje, Payload CMS o Strapi se sentirán más familiares. Si quieres la mejor experiencia de desarrollador y no te importa solo cloud, Sanity es difícil de superar.
Hemos hecho trabajo extenso con todos estos a través de nuestra práctica de desarrollo de CMS headless, y la opción correcta realmente depende del nivel de comodidad y presupuesto de tu equipo.
Ganancias de rendimiento reales: Antes y después
Migré un sitio MODX de tamaño medio (aproximadamente 400 páginas, blog + servicios + portafolio) a Next.js con Sanity a finales de 2025. Aquí están los números reales:
| Métrica | MODX (optimizado) | Next.js en Vercel | Mejora |
|---|---|---|---|
| Lighthouse Performance | 72 | 98 | +36% |
| Largest Contentful Paint | 2.8s | 0.9s | -68% |
| Time to First Byte | 680ms | 45ms | -93% |
| Core Web Vitals Pass | Parcial | Full pass | ✅ |
| Tiempo de construcción/despliegue | FTP manual | 42s despliegue auto | Día y noche |
| Costo de hospedaje mensual | $45/mes (VPS) | $0 (tier libre de Vercel) | -100% |
La mejora de TTFB por sí sola es asombrosa. MODX tiene que arrancar PHP, conectarse a MySQL, ejecutar snippets, ensamblar chunks y servir la respuesta — incluso con caché. Una página de Next.js generada estáticamente se sirve desde un nodo de edge de CDN en milisegundos.
Qué echarás de menos (y qué no)
Echarás de menos
- La UI del Manager: El panel de administración de MODX es genuinamente intuitivo para editores de contenido. La mayoría de paneles de administración de CMS headless tienen una curva de aprendizaje.
- Edición en contexto: Editar contenido donde lo ves renderizado. La mayoría de configuraciones headless requieren cambiar entre CMS y vista previa. (La herramienta Presentation de Sanity y el Live Preview de Payload están cerrando esta brecha.)
- Simplicidad: Un servidor, una base de datos, una base de código. Hay belleza en eso. Un stack headless tiene más partes móviles.
- El ambiente de comunidad: La comunidad de MODX, aunque pequeña, era unida y genuinamente útil.
No echarás de menos
- Limpieza de caché: El interminable ciclo de limpiar-caché-actualizar.
- Gestión de TV: Crear y gestionar variables de plantilla a través de la UI para cada campo.
- Ansiedad de base de datos: Ese sentimiento de hundimiento cuando tu conexión MySQL se agota en un pico de tráfico.
- Despliegues FTP: O cualquier proceso manual que usaras para empujar cambios.
- Depuración de eventos de plugin: Tratando de descifrar qué plugin se disparó cuándo, en qué orden.
Comparación de costos: Ejecutar MODX vs Next.js
Seamos realistas sobre costo total de propiedad, no solo hospedaje.
| Categoría de costo | MODX (Anual) | Next.js + CMS Headless (Anual) |
|---|---|---|
| Hospedaje | $540-$1,200 (VPS/compartido) | $0-$240 (Vercel/Netlify) |
| Licencia de CMS | $0 (open source) | $0-$3,600 (varía según CMS) |
| Certificado SSL | $0-$100 | $0 (incluido) |
| CDN | $0-$600 | $0 (incluido) |
| Monitoreo de seguridad | $200-$500 | Mínimo (sin servidor) |
| Mantenimiento del servidor | $500-$2,000 (tiempo u outsourced) | $0 |
| Tarifa horaria del desarrollador | $75-$120 (talento escaso) | $100-$175 (talento abundante) |
| Total (sin tiempo de dev) | $1,240-$4,400 | $0-$3,840 |
La incógnita es las tarifas de desarrollador. Los desarrolladores de MODX son más baratos por hora si los puedes encontrar. Pero la escasez impulsa las tarifas con el tiempo, y a menudo estás atrapado con quien está disponible en lugar de elegir el mejor ajuste.
Si estás evaluando costos de migración para tu situación específica, desglosamos nuestro enfoque de precios aquí — somos transparentes sobre lo que estos proyectos realmente cuestan.
Preguntas frecuentes
¿Cuánto tiempo toma una migración típica de MODX a Next.js?
Para un sitio con 100-500 páginas, espera 6-10 semanas con un equipo dedicado. El modelado de contenido y la migración toma alrededor de 2 semanas, construir el front-end de Next.js toma 3-5 semanas, y QA/pruebas/redirecciones llenan el resto. Los sitios más grandes con snippets personalizados complejos o integración de e-commerce pesada pueden tomar 12-16 semanas. La variable más grande es cuánta lógica PHP personalizada necesita ser reescrita.
¿Puedo mantener mi panel de administración de MODX y simplemente usar Next.js para el front-end?
Técnicamente, sí — podrías construir una capa de API REST en MODX y consumirla con Next.js. Pero esto te da lo peor de ambos mundos: todavía mantienes el servidor PHP, la base de datos MySQL, y todas las preocupaciones de seguridad, mientras también mantienes un front-end separado. A menos que tengas una razón muy específica, es mejor migrar contenido a un CMS headless de propósito general.
¿Perderé rankings de SEO durante la migración?
No si manejas redirecciones adecuadamente. Los pasos críticos son: mantener la misma estructura de URL cuando sea posible, configurar redireccionamientos 301 para cualquier URL que cambie, mantener tus metadatos intactos, y enviar un sitemap actualizado a Google Search Console después del lanzamiento. La mayoría de sitios que hemos migrado ven mejoras de ranking *dentro de 4-8 semanas debido a mejores puntuaciones de Core Web Vitals.
¿Qué pasa con los sitios de MODX con formularios FormIt y flujos de trabajo complejos?
Los formularios son una de las partes más complicadas de la migración. FormIt manejaba validación, envío de correo, hooks, y prevención de spam todo en un paquete. En Next.js, típicamente combinarás Server Actions para procesamiento, Zod para validación, y un servicio como Resend o SendGrid para entrega de correo. Es más explícito pero también más comprobable y fiable.
¿Es Next.js excesivo para un sitio simple de folleto?
Quizás. Si tu sitio de MODX es literalmente 10 páginas estáticas con un formulario de contacto, Astro podría ser un mejor ajuste — envía cero JavaScript por defecto y es más simple de configurar. Pero si existe la posibilidad de que necesites características dinámicas, autenticación, u obtención de datos compleja más adelante, comenzar con Next.js te salva de otra migración más adelante.
¿Qué pasa con mis extras de MODX y snippets personalizados?
Necesitan ser reconstruidos. No hay conversión automatizada. Los snippets personalizados se convierten en rutas de API o acciones de servidor en Next.js. Las extras como Gallery, Articles, o MIGX se reemplazan por características nativas del CMS headless (que generalmente son mejores). Las extras de e-commerce como Foxy o SimpleCart se reemplazarían por la API Storefront de Shopify, Snipcart, o Medusa. Planifica explícitamente este esfuerzo en tu cronograma de migración.
¿Cómo convenzo a mis partes interesadas no técnicas para aprobar esta migración?
Enfócate en tres cosas que les importan: riesgo, costo y resultados. Riesgo: la comunidad cada vez más pequeña de MODX significa que encontrar desarrolladores para emergencias se vuelve más difícil cada año. Costo: el mantenimiento del servidor y el parcheado de seguridad no son gratis, incluso si la licencia del CMS es. Resultados: muéstrales la comparación de Core Web Vitals y explica cómo Google usa la velocidad de página como factor de ranking. Si sus competidores se cargan en menos de un segundo y ellos están en 3 segundos, eso es un problema comercial.
¿Puedo migrar incrementalmente o tiene que ser todo de una vez?
La migración incremental es posible usando una configuración de proxy inverso — servirías nuevas páginas desde Next.js y rutearías páginas legadas a tu servidor de MODX. Hemos hecho esto con configuraciones nginx donde rutas específicas se prorrogan al servidor antiguo mientras todo lo demás va al nuevo despliegue de Next.js. Añade complejidad, pero para sitios con cientos de páginas, te permite migrar en fases durante semanas o meses en lugar de hacer un cutover riesgoso de big-bang.
Si estás sentado en un sitio de MODX y sintiendo los puntos de dolor que he descrito, el mejor momento para comenzar a planificar es ahora. No porque el cielo se esté cayendo, sino porque las migraciones realizadas bajo presión — después de una brecha de seguridad, después de que tu desarrollador se vaya, después de que una versión de PHP alcance el fin de vida — siempre son más caras y más estresantes que las planeadas. Ponte en contacto con nosotros si quieres hablar a través de tu situación específica. Hemos pasado por esto lo suficiente como para saber dónde están las minas terrestres.