He estado construyendo sitios en MODX desde los tiempos de Evolution. He escrito snippets personalizados, luchado con TVs (template variables, no televisores), y defendido MODX en innumerables debates sobre CMSes. Así que créeme cuando digo que esto no es un artículo de ataque. Es un llamado de atención de alguien que genuinamente amó esta plataforma.

Pero aquí está la realidad: el mundo del desarrollo web ha avanzado, y MODX no ha seguido el ritmo. La comunidad se está reduciendo, el ciclo de lanzamientos se ha ralentizado hasta casi detenerse, y el grupo de talentos se está agotando más rápido que un charco en julio. Si todavía estás ejecutando sitios en producción con MODX en 2026, necesitas considerar seriamente tu estrategia de salida. Y para la mayoría de los equipos, esa salida lleva a Next.js.

Déjame explicarte por qué — con honestidad, sin exageraciones.

Tabla de contenidos

Por qué los usuarios de MODX deberían migrar a Next.js en 2026: Una perspectiva honesta

El estado de MODX en 2026

Miremos los números con honestidad. MODX 3.x lleva un tiempo disponible, pero la adopción ha sido... tibia. Los foros de MODX, que alguna vez estuvieron llenos de actividad, ahora ven quizás un puñado de publicaciones por semana. El repositorio oficial de GitHub muestra una actividad de commits cada vez más escasa. Compara eso con 2018 o 2019, cuando la comunidad todavía empujaba con fuerza.

Los datos de BuiltWith de principios de 2026 estiman que MODX impulsa aproximadamente el 0,3% de los sitios web con CMS detectado, por debajo de alrededor del 0,7% en 2021. WordPress sigue dominando con ~62%, y los nuevos actores como los sitios basados en Next.js (a menudo combinados con CMSes 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 nueva extensión significativa en meses. Muchos extras populares no están mantenidos o solo son parcialmente compatibles con MODX 3.x. Cuando el ecosistema deja de producir, eso no es una señal de alerta — es una bandera blanca.

No estoy diciendo que MODX esté muerto. Todavía funciona. Tus sitios siguen corriendo. Pero "todavía funciona" es un lugar peligroso en el que estar en el desarrollo web.

Lo que MODX hizo bien (y sigue haciendo)

Antes de seguir criticando, démosle crédito donde lo merece. MODX acertó en varias cosas que la mayoría de los CMSes todavía hacen mal:

Verdadera flexibilidad de contenido

MODX nunca te obligó a seguir el paradigma de "publicación y página". Las template variables, chunks y snippets te dieron una verdadera libertad de modelado de contenido años antes de que el "contenido estructurado" se convirtiera en una palabra de moda. Podías construir cualquier cosa.

Salida limpia

MODX no inyectaba su propio marcado. Sin clases CSS misteriosas, sin divs contenedores que no pediste. Tu HTML era tu HTML. Para los desarrolladores de front-end que se preocupaban por el oficio, esto fue una revelación.

Creación de temas orientada al desarrollador

Sin sistema de temas que aprender, sin jerarquía de plantillas que memorizar. Escribías plantillas. Eso era todo. Los chunks eran partials reutilizables. Los snippets eran lógica PHP. Un modelo mental simple, resultados poderosos.

La sintaxis de etiquetas

Digan lo que quieran sobre [[*pagetitle]] y [[!MySnippet]] — una vez que la aprendías, podías construir páginas complejas rápidamente. La capa de caché con el flag ! sin caché era elegante.

Estas fortalezas en realidad hacen que los desarrolladores de MODX sean excelentes candidatos para las arquitecturas headless modernas. Si ya piensas en contenido estructurado y plantillas basadas en componentes, ya estás a mitad de camino hacia Next.js.

Los problemas que ya no puedes ignorar

Aquí es donde tengo que ser directo.

Problemas 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 que afectaron instalaciones de MODX, y los parches tardaron semanas en llegar. Con un equipo de seguridad cada vez más pequeño, los tiempos de respuesta no están mejorando.

Compara eso con un sitio Next.js desplegado en Vercel o Netlify — literalmente no hay servidor que atacar. Sin panel de administración para ataques de fuerza bruta. Sin PHP que 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 la oferta de trabajo y observa el silencio. El grupo de desarrolladores ha migrado a React, Next.js y frameworks modernos de JavaScript. Incluso el talento de PHP se está yendo a Laravel, no a MODX.

Esta no es una preocupación teórica. He hablado con agencias que tienen sitios MODX para los que literalmente no pueden encontrar desarrolladores que los mantengan. Cuando el desarrollador original se va, el sitio se convierte en una responsabilidad.

Dolores de cabeza de compatibilidad con PHP 8.x

MODX 3.x funciona en PHP 8, pero muchos extras no. Si has construido un sitio que depende de snippets o plugins de terceros, actualizar PHP a menudo rompe las cosas. Terminas anclado a versiones antiguas de PHP, lo que vuelve al problema de seguridad.

Sin experiencia de desarrollo moderna

Sin recarga de módulos en caliente. Sin arquitectura basada en componentes. Sin soporte para TypeScript. Sin optimización de imágenes incorporada. Sin renderizado en el 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 la caché, actualizar el navegador. Funciona, pero es lento en comparación con el DX moderno.

Techo de rendimiento

MODX puede ser rápido — he construido sitios con tiempos inferiores a 2 segundos en él. Pero lograrlo requiere una optimización significativa: caché de página completa, configuración de CDN, ajuste de base de datos y una arquitectura cuidadosa de snippets. Next.js te ofrece un rendimiento inferior al segundo esencialmente de fábrica con la generación estática. En MODX luchas por el rendimiento; en Next.js, luchas para estropearlo.

Por qué los usuarios de MODX deberían migrar a Next.js en 2026: Una perspectiva honesta - arquitectura

Por qué Next.js es el destino de migración natural

Podrías preguntar: ¿por qué no WordPress? ¿Por qué no Astro? ¿Por qué no simplemente un generador de sitios estáticos?

Todas son opciones válidas, pero Next.js da en el punto exacto para la mayoría de las migraciones de MODX. He aquí 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, marcabas los 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. El mismo concepto, mejor ejecución.

La arquitectura de componentes reemplaza a los chunks

Los chunks de MODX son partials HTML reutilizables. Los componentes de React son partials de UI reutilizables con lógica incorporada. Si has estado escribiendo chunks como [[!$header]] y [[!$footer]], ya piensas en componentes. Solo que no tenías props.

Las rutas de API reemplazan a los snippets

Los snippets de MODX manejan la lógica del lado del servidor — procesamiento de formularios, llamadas a API, consultas personalizadas. Las rutas de API de Next.js (o las Server Actions en Next.js 14+) hacen lo mismo pero en JavaScript/TypeScript con mejor soporte de herramientas y pruebas.

Para los equipos que consideren alternativas, Astro vale la pena evaluarlo para sitios con mucho contenido que no necesitan mucha interactividad. Pero si necesitas funciones dinámicas, experiencias autenticadas o recuperación de datos compleja, Next.js es la opción más sólida.

La ruta de migración: de MODX a Next.js

Vayamos a lo práctico. Así es como funciona realmente una migración de MODX a Next.js.

Paso 1: Audita tu modelo de contenido

Mapea cada plantilla de MODX, template variable y tipo de recurso. Esto se convierte en tu modelo de contenido en cualquier CMS headless que elijas. Documenta todo:

## Recurso: Entrada de blog
- pagetitle → title (texto)
- longtitle → seo_title (texto)
- content → body (texto enriquecido)
- TV: hero_image → hero_image (multimedia)
- TV: author → author (referencia)
- TV: category → category (taxonomía)

Paso 2: Exporta tu contenido

MODX no tiene una gran herramienta de exportación. Probablemente necesitarás escribir un snippet o script personalizado que consulte modx_site_content y tus tablas de TV, y luego genere JSON:

<?php
// Exportación rápida y sencilla de contenido MODX
$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 de destino. Es un trabajo poco glamoroso, pero es un esfuerzo de una sola vez.

Paso 3: Construye tu front-end en Next.js

Comienza con create-next-app y construye tus plantillas como componentes de página. El mapeo de tu plantilla MODX a diseño de página podría verse así:

Concepto MODX Equivalente en Next.js
Template Componente de layout
Chunk Componente React
Snippet Server Action / Ruta API
Template Variable Campo CMS
Resource Página / entrada de contenido
Etiqueta [[*field]] Props / recuperación de datos
Plugin (event hook) Middleware
[[!uncached]] SSR / renderizado dinámico
[[cached]] SSG / ISR

Paso 4: Gestiona las redirecciones de URL

Aquí es donde la gente se equivoca. Cada URL antigua de MODX necesita una redirección 301 a su equivalente 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 omitas 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. Revisa las analíticas. Verifica que los formularios funcionen. Luego cambia el DNS.

Elegir un CMS headless para reemplazar MODX

Next.js es tu front-end, pero todavía necesitas un lugar para gestionar el contenido. Aquí se comparan las opciones más populares para los refugiados de MODX:

CMS Curva de aprendizaje para desarrolladores MODX Modelado de contenido Precios (2026) Opción autoalojada
Sanity Media Excelente (esquemas definidos por código) Nivel gratuito, luego $15/usuario/mes No (solo nube)
Strapi Baja Bueno (basado en UI) Gratuito (autoalojado), Nube desde $29/mes Sí
Contentful Media Bueno Nivel gratuito, luego $300/mes No
Payload CMS Baja Excelente (definido por código) Gratuito (autoalojado), Nube desde $50/mes Sí
Directus Baja Flexible Gratuito (autoalojado), Nube desde $99/mes Sí

Si amabas la flexibilidad y la capacidad de autoalojamiento de MODX, Payload CMS o Strapi te resultarán más familiares. Si quieres la mejor experiencia de desarrollador y no te importa depender de la nube, Sanity es difícil de superar.

Hemos realizado un trabajo extenso con todos ellos a través de nuestra práctica de desarrollo de CMS headless, y la elección correcta realmente depende del nivel de comodidad y el presupuesto de tu equipo.

Mejoras de rendimiento reales: antes y después

Migré un sitio MODX de tamaño mediano (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
Rendimiento en Lighthouse 72 98 +36%
Largest Contentful Paint 2,8s 0,9s -68%
Time to First Byte 680ms 45ms -93%
Aprobación de Core Web Vitals Parcial Aprobación completa ✅
Tiempo de construcción/despliegue FTP manual Despliegue automático en 42s Noche y día
Costo mensual de alojamiento $45/mes (VPS) $0 (nivel gratuito de Vercel) -100%

La mejora en TTFB por sí sola es asombrosa. MODX tiene que iniciar 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 edge de CDN en milisegundos.

Lo que extrañarás (y lo que no)

Extrañarás

  • La interfaz del Manager: El panel de administración de MODX es genuinamente intuitivo para los editores de contenido. La mayoría de los paneles de administración de CMS headless tienen una curva de aprendizaje.
  • La edición en contexto: Editar contenido donde lo ves renderizado. La mayoría de las configuraciones headless requieren cambiar entre el CMS y la vista previa. (La herramienta Presentation de Sanity y Live Preview de Payload están cerrando esta brecha.)
  • La simplicidad: Un servidor, una base de datos, un código base. Hay belleza en eso. Una pila headless tiene más partes móviles.
  • El ambiente de la comunidad: La comunidad de MODX, aunque pequeña, era unida y genuinamente solidaria.

No extrañarás

  • Limpiar la caché: El interminable ciclo de limpiar caché y actualizar.
  • La gestión de TVs: Crear y gestionar template variables a través de la interfaz para cada campo.
  • La ansiedad de la base de datos: Esa sensación de hundimiento cuando las conexiones MySQL se agotan durante un pico de tráfico.
  • Los despliegues por FTP: O cualquier proceso manual que usabas para publicar cambios.
  • Depurar eventos de plugins: Intentar averiguar qué plugin se disparó cuándo y en qué orden.

Comparación de costos: ejecutar MODX vs Next.js

Seamos realistas sobre el costo total de propiedad, no solo el alojamiento.

Categoría de costo MODX (anual) Next.js + CMS headless (anual)
Alojamiento $540-$1.200 (VPS/compartido) $0-$240 (Vercel/Netlify)
Licencia CMS $0 (código abierto) $0-$3.600 (varía según el 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 o externalizado) $0
Tarifa horaria del desarrollador $75-$120 (talento escaso) $100-$175 (talento abundante)
Total (excluido tiempo de desarrollo) $1.240-$4.400 $0-$3.840

El factor imprevisible son las tarifas de los desarrolladores. Los desarrolladores de MODX son más baratos por hora si puedes encontrarlos. Pero la escasez hace subir las tarifas con el tiempo, y a menudo estás atrapado con quien esté disponible en lugar de elegir el mejor candidato.

Si estás evaluando los costos de migración para tu situación específica, desglosamos nuestro enfoque de precios aquí — somos transparentes sobre lo que realmente cuestan estos proyectos.

Preguntas frecuentes

¿Cuánto tiempo lleva una migración típica de MODX a Next.js?

Para un sitio con 100-500 páginas, espera entre 6 y 10 semanas con un equipo dedicado. El modelado y la migración de contenido toman aproximadamente 2 semanas, construir el front-end en Next.js toma 3-5 semanas, y el control de calidad, las pruebas y las redirecciones llenan el resto. Los sitios más grandes con snippets personalizados complejos o integraciones pesadas de comercio electrónico pueden tomar entre 12 y 16 semanas. La mayor variable es cuánta lógica PHP personalizada necesita ser reescrita.

¿Puedo mantener mi panel de administración de MODX y usar Next.js solo para el front-end?

Técnicamente, sí — podrías construir una capa REST API 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 todos los problemas de seguridad, mientras también mantienes un front-end separado. A menos que tengas una razón muy específica, es mejor migrar el contenido a un CMS headless diseñado específicamente para ese propósito.

¿Perderé posicionamiento SEO durante la migración?

No si manejas las redirecciones correctamente. Los pasos críticos son: mantener la misma estructura de URL donde sea posible, configurar redirecciones 301 para cualquier URL que cambie, mantener intactos tus metadatos y enviar un sitemap actualizado a Google Search Console después del lanzamiento. La mayoría de los sitios que hemos migrado ven mejoras en el posicionamiento dentro de 4-8 semanas gracias a mejores puntuaciones en Core Web Vitals.

¿Qué pasa con los sitios MODX que tienen formularios de FormIt y flujos de trabajo complejos?

Los formularios son una de las partes más complicadas de la migración. FormIt manejaba la validación, el envío de correos electrónicos, los hooks y la prevención de spam todo en un solo paquete. En Next.js, normalmente combinarás Server Actions para el procesamiento, Zod para la validación y un servicio como Resend o SendGrid para la entrega de correos electrónicos. Es más explícito pero también más fácil de probar y más confiable.

¿Es Next.js exagerado para un sitio de folleto simple?

Tal vez. Si tu sitio MODX tiene literalmente 10 páginas estáticas con un formulario de contacto, Astro podría ser una mejor opción — envía cero JavaScript por defecto y es más sencillo de configurar. Pero si hay alguna posibilidad de que necesites funciones dinámicas, autenticación o recuperación de datos compleja más adelante, empezar con Next.js te ahorra otra migración en el futuro.

¿Qué pasa con mis extras de MODX y mis snippets personalizados?

Necesitan ser reconstruidos. No hay conversión automatizada. Los snippets personalizados se convierten en rutas API o server actions en Next.js. Los extras como Gallery, Articles o MIGX son reemplazados por las funciones nativas de tu CMS headless (que generalmente son mejores). Los extras de comercio electrónico como Foxy o SimpleCart serían reemplazados por la Storefront API de Shopify, Snipcart o Medusa. Planifica este esfuerzo explícitamente en tu cronograma de migración.

¿Cómo convenzo a mis partes interesadas no técnicas para que aprueben esta migración?

Enfócate en tres cosas que les importan: riesgo, costo y resultados. Riesgo: la comunidad en declive de MODX significa que encontrar desarrolladores para emergencias se vuelve más difícil cada año. Costo: el mantenimiento del servidor y la aplicación de parches de seguridad no son gratuitos, aunque la licencia del CMS lo sea. Resultados: muéstrales la comparación de Core Web Vitals y explica cómo Google usa la velocidad de la página como factor de posicionamiento. Si sus competidores cargan en menos de un segundo y ellos están a 3 segundos, eso es un problema de negocio.

¿Puedo migrar de forma incremental o tiene que ser todo a la vez?

La migración incremental es posible usando una configuración de proxy inverso — servirías las páginas nuevas desde Next.js y enrutarías las páginas antiguas a tu servidor MODX. Hemos hecho esto con configuraciones de nginx donde rutas específicas se redirigen mediante proxy 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 cambio total arriesgado de una sola vez.

Si tienes un sitio MODX y estás sintiendo los puntos de dolor que he descrito, el mejor momento para empezar a planificar es ahora. No porque el cielo esté cayendo, sino porque las migraciones hechas bajo presión — después de una brecha de seguridad, después de que tu desarrollador se va, después de que una versión de PHP llega al fin de su vida útil — siempre son más costosas y más estresantes que las planificadas. Contáctanos si quieres hablar sobre tu situación específica. Hemos pasado por esto suficientes veces como para saber dónde están las minas terrestres.