Tenho construído sites no MODX desde os dias da Evolution. Escrevi snippets personalizados, lutei com TVs (template variables, não televisões), e defendi o MODX em inúmeros debates sobre CMS. Então acredite em mim quando digo que isto não é um ataque. É um alerta de alguém que genuinamente amava essa plataforma.

Mas aqui está a questão: o mundo do desenvolvimento web avançou, e o MODX não acompanhou. A comunidade está encolhendo, o ciclo de lançamentos desacelerou a um ritmo de caracol, e o pool de talentos está secando mais rápido que uma poça em julho. Se você ainda está rodando sites em produção no MODX em 2026, você precisa considerar seriamente sua estratégia de saída. E para a maioria das equipes, essa saída leva ao Next.js.

Deixe-me explicar por quê — honestamente, sem o hype.

Índice

Por Que Usuários do MODX Devem Migrar para Next.js em 2026: Uma Visão Honesta

O Estado do MODX em 2026

Vamos olhar os números honestamente. O MODX 3.x está por aí há um tempo, mas a adoção tem sido... tíbia. Os fóruns do MODX, outrora fervilhando de atividade, agora veem talvez um punhado de posts por semana. O repositório GitHub oficial mostra atividade de commit cada vez mais escassa. Compare isso com 2018 ou 2019 quando a comunidade ainda estava pressionando forte.

Dados do BuiltWith de início de 2026 estimam que o MODX alimenta aproximadamente 0,3% dos sites com CMS detectado, descendo de cerca de 0,7% em 2021. WordPress ainda domina com ~62%, e novos players como sites baseados em Next.js (frequentemente emparelhados com CMSes headless) estão crescendo em aproximadamente 40% ano após ano.

O marketplace do MODX (anteriormente o repositório de Extras) não viu uma extensão nova significativa em meses. Muitas extras populares estão não mantidas ou apenas parcialmente compatíveis com o MODX 3.x. Quando o ecossistema para de produzir, isso não é uma bandeira vermelha — é uma bandeira branca.

Não estou dizendo que o MODX está morto. Ainda funciona. Seus sites ainda rodam. Mas "ainda funciona" é um lugar perigoso para estar no desenvolvimento web.

O que o MODX Acertou (e Ainda Acerta)

Antes de atacar, crédito aonde é devido. O MODX acertou várias coisas que a maioria dos CMSes ainda erra:

Verdadeira Flexibilidade de Conteúdo

O MODX nunca o forçou a um paradigma "post e página". Template variables, chunks e snippets lhe deram verdadeira liberdade de modelagem de conteúdo anos antes de "conteúdo estruturado" se tornar uma buzzword. Você podia construir qualquer coisa.

Saída Limpa

O MODX não injetava sua própria marcação. Sem classes CSS mistério, sem divs wrapper que você não pediu. Seu HTML era seu HTML. Para desenvolvedores front-end que se importavam com ofício, isso foi uma revelação.

Tematização Amigável ao Desenvolvedor

Sem sistema de temas para aprender, sem hierarquia de templates para memorizar. Você escrevia templates. Era isso. Chunks eram partials reutilizáveis. Snippets eram lógica PHP. Modelo mental simples, resultados poderosos.

A Sintaxe de Tag

Diga o que você quiser sobre [[*pagetitle]] e [[!MySnippet]] — uma vez que você aprendeu, você podia construir páginas complexas rápido. A camada de cache com a flag ! não cacheada era elegante.

Essas forças na verdade fazem os desenvolvedores MODX ótimos candidatos para arquiteturas headless modernas. Se você já pensa em conteúdo estruturado e templates baseados em componentes, você já está no meio do caminho para Next.js.

Os Problemas que Você Não Pode Mais Ignorar

Aqui é onde tenho que ser direto.

Preocupações de Segurança

O MODX 3.x abordou muitas vulnerabilidades históricas, mas rodar qualquer monolito PHP com um painel admin público é um vetor de risco inerente. Em 2025, vimos pelo menos dois CVEs críticos afetando instalações MODX, e patches levaram semanas para chegar. Com um time de segurança encolhendo, os tempos de resposta não estão melhorando.

Compare isso com um site Next.js deployado em Vercel ou Netlify — literalmente não há servidor para atacar. Nenhum painel admin para fazer força bruta. Nenhum PHP para explorar. A superfície de ataque é fundamentalmente menor.

A Crise de Talentos

Tente contratar um desenvolvedor MODX em 2026. Vá em frente. Poste o anúncio de emprego e observe o silêncio. O pool de desenvolvedores migrou para React, Next.js e frameworks JavaScript modernos. Até o talento PHP está indo para Laravel, não MODX.

Isso não é uma preocupação teórica. Falei com agências que têm sites MODX que literalmente não conseguem encontrar desenvolvedores para manter. Quando o desenvolvedor original sai, o site se torna um passivo.

Dores de Cabeça de Compatibilidade com PHP 8.x

O MODX 3.x roda em PHP 8, mas muitas extras não. Se você construiu um site que depende de snippets ou plugins de terceiros, atualizar PHP frequentemente quebra coisas. Você termina fixado em versões PHP mais antigas, o que volta ao problema de segurança.

Nenhuma Experiência Moderna de Desenvolvedor

Sem hot module reloading. Sem arquitetura baseada em componentes. Sem suporte TypeScript. Sem otimização de imagem integrada. Sem renderização edge. Sem ISR. Eu poderia continuar.

O fluxo de trabalho de desenvolvimento do MODX é essencialmente: editar um arquivo ou um chunk no gerenciador (ou no seu IDE via uma ferramenta de sincronização), limpar o cache, atualizar o navegador. Funciona, mas é lento comparado à DX moderna.

Limite de Performance

O MODX pode ser rápido — construí sites sub-2-segundo nele. Mas chegar lá requer otimização significativa: cache de página inteira, setup de CDN, ajuste de banco de dados e arquitetura cuidadosa de snippets. Next.js oferece performance sub-segundo essencialmente pronto para uso com geração estática. Você está lutando por performance no MODX; no Next.js, você está lutando para arruiná-lo.

Por Que Usuários do MODX Devem Migrar para Next.js em 2026: Uma Visão Honesta - arquitetura

Por Que Next.js É o Alvo Natural de Migração

Você pode perguntar: por que não WordPress? Por que não Astro? Por que não apenas um gerador de site estático?

Todas são opções válidas, mas Next.js atinge o ponto doce para a maioria das migrações MODX. Aqui está o porquê:

Flexibilidade de Renderização Espelha Pensamento MODX

Os desenvolvedores MODX já entendem que diferentes páginas precisam de diferentes estratégias de cache. No MODX, você marcaria snippets como cacheados ou não cacheados. No Next.js, você escolhe entre Static Site Generation (SSG), Incremental Static Regeneration (ISR), e Server-Side Rendering (SSR) por página. Mesmo conceito, execução melhor.

Arquitetura de Componentes Substitui Chunks

Chunks MODX são partials HTML reutilizáveis. Componentes React são partials UI reutilizáveis com lógica integrada. Se você tem estado escrevendo chunks como [[!$header]] e [[!$footer]], você já pensa em componentes. Você apenas não tinha props.

Rotas de API Substituem Snippets

Snippets MODX lidam com lógica do lado do servidor — processamento de formulários, chamadas de API, consultas personalizadas. Rotas de API Next.js (ou Server Actions no Next.js 14+) fazem a mesma coisa mas em JavaScript/TypeScript com melhor suporte a ferramentas e testes.

Para equipes considerando alternativas, Astro vale a pena avaliar para sites com conteúdo pesado que não precisam de muita interatividade. Mas se você precisa de recursos dinâmicos, experiências autenticadas ou busca de dados complexa, Next.js é a escolha mais forte.

O Caminho da Migração: MODX para Next.js

Vamos ser práticos. Aqui está como uma migração MODX-para-Next.js realmente funciona.

Passo 1: Auditar Seu Modelo de Conteúdo

Mapeie cada template MODX, template variable e tipo de recurso. Isso se torna seu modelo de conteúdo em qualquer CMS headless que você escolher. Documente tudo:

## Recurso: Blog Post
- pagetitle → title (texto)
- longtitle → seo_title (texto)
- content → body (rich text)
- TV: hero_image → hero_image (mídia)
- TV: author → author (referência)
- TV: category → category (taxonomia)

Passo 2: Exportar Seu Conteúdo

MODX não tem uma ferramenta de exportação ótima. Você provavelmente precisará escrever um snippet customizado ou script que consulta modx_site_content e suas tabelas TV, então gera JSON:

<?php
// Exportação rápida e suja de conteúdo 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);

Depois escreva scripts de importação para seu CMS alvo. É trabalho ingrato, mas é um esforço único.

Passo 3: Construir Seu Front-End Next.js

Comece com create-next-app e construa seus templates como componentes de página. Seu mapeamento template MODX → layout de página poderia parecer:

Conceito MODX Equivalente Next.js
Template Componente Layout
Chunk Componente React
Snippet Server Action / rota API
Template Variable Campo CMS
Recurso Página / entrada de conteúdo
[[*field]] tag Props / busca de dados
Plugin (event hook) Middleware
[[!uncached]] SSR / renderização dinâmica
[[cached]] SSG / ISR

Passo 4: Lidar com Redirecionamentos de URL

Aqui é onde as pessoas erram. Cada URL MODX antiga precisa de um redirecionamento 301 para seu equivalente Next.js novo. Construa um mapa de redirecionamento e adicione-o ao next.config.js:

// next.config.js
module.exports = {
  async redirects() {
    return [
      {
        source: '/old-modx-path.html',
        destination: '/new-path',
        permanent: true,
      },
      // ... centenas mais, geradas da sua exportação
    ]
  },
}

Não pule isso. Seu SEO depende disso.

Passo 5: Rodar em Paralelo por 2-4 Semanas

Deploy Next.js ao lado de seu site MODX existente. Teste tudo. Verifique analytics. Confirme se formulários funcionam. Depois altere DNS.

Escolhendo um CMS Headless para Substituir o MODX

Next.js é seu front-end, mas você ainda precisa de um lugar para gerenciar conteúdo. Aqui está como as opções populares se comparam para refugiados MODX:

CMS Curva de Aprendizado para Devs MODX Modelagem de Conteúdo Preço (2026) Opção Self-Hosted
Sanity Médio Excelente (schemas definidos em código) Tier gratuito, depois $15/usuário/mês Não (apenas cloud)
Strapi Baixo Bom (baseado em UI) Gratuito (self-hosted), Cloud a partir de $29/mês Sim
Contentful Médio Bom Tier gratuito, depois $300/mês Não
Payload CMS Baixo Excelente (schemas definidos em código) Gratuito (self-hosted), Cloud a partir de $50/mês Sim
Directus Baixo Flexível Gratuito (self-hosted), Cloud a partir de $99/mês Sim

Se você amava a flexibilidade do MODX e a capacidade de self-hosting, Payload CMS ou Strapi se parecerão mais familiares. Se você quer a melhor experiência de desenvolvedor e não se importa com cloud-only, Sanity é difícil de superar.

Fizemos trabalho extenso com todos esses através de nossa prática de desenvolvimento de CMS headless, e a escolha certa realmente depende do nível de conforto de sua equipe e orçamento.

Ganhos Reais de Performance: Antes e Depois

Migrei um site MODX de médio porte (aproximadamente 400 páginas, blog + serviços + portfólio) para Next.js com Sanity no final de 2025. Aqui estão os números reais:

Métrica MODX (otimizado) Next.js em Vercel Melhoria
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 Pass completo ✅
Tempo de Build/Deploy FTP manual Auto-deploy 42s Dia e noite
Custo de Hosting Mensal $45/mês (VPS) $0 (tier gratuito Vercel) -100%

A melhoria do TTFB sozinha é impressionante. MODX tem que inicializar PHP, conectar ao MySQL, rodar snippets, montar chunks e servir a resposta — mesmo com cache. Uma página Next.js gerada estaticamente é servida de um nó CDN edge em milissegundos.

O que Você Vai Sentir Falta (e O que Você Não Vai)

Você Vai Sentir Falta

  • A UI do Gerenciador: O painel admin do MODX é genuinamente intuitivo para editores de conteúdo. A maioria dos painéis admin de CMS headless têm uma curva de aprendizado.
  • Edição in-context: Editar conteúdo onde você o vê renderizado. A maioria dos setups headless requerem alternar entre CMS e preview. (A Presentation tool do Sanity e o Live Preview do Payload estão fechando essa lacuna.)
  • Simplicidade: Um servidor, um banco de dados, um codebase. Há beleza nisso. Um stack headless tem mais partes móveis.
  • A vibe da comunidade: A comunidade MODX, embora pequena, era unida e genuinamente prestativa.

Você Não Vai Sentir Falta

  • Limpeza de cache: O ciclo infinito de limpar-cache-atualizar.
  • Gerenciamento de TV: Criar e gerenciar template variables através da UI para cada campo.
  • Ansiedade de banco de dados: Aquele sentimento de desespero quando sua conexão MySQL atinge o máximo em um pico de tráfego.
  • Deployments FTP: Ou qualquer processo manual que você usava para fazer push de mudanças.
  • Debugging de evento de plugin: Tentar descobrir qual plugin disparou quando, em qual ordem.

Comparação de Custos: Rodando MODX vs Next.js

Vamos ser realistas sobre o custo total de propriedade, não apenas hosting.

Categoria de Custo MODX (Anual) Next.js + CMS Headless (Anual)
Hosting $540-$1.200 (VPS/compartilhado) $0-$240 (Vercel/Netlify)
Licença CMS $0 (open source) $0-$3.600 (varia por CMS)
Certificado SSL $0-$100 $0 (incluído)
CDN $0-$600 $0 (incluído)
Monitoramento de Segurança $200-$500 Mínimo (sem servidor)
Manutenção de Servidor $500-$2.000 (tempo ou terceirizado) $0
Taxa Horária do Desenvolvedor $75-$120 (talento escasso) $100-$175 (talento abundante)
Total (excluindo tempo de dev) $1.240-$4.400 $0-$3.840

A carta curinga é a taxa de desenvolvedor. Desenvolvedores MODX são mais baratos por hora se você conseguir encontrá-los. Mas a escassez impulsiona as taxas para cima ao longo do tempo, e você frequentemente fica preso com quem está disponível ao invés de escolher o melhor ajuste.

Se você está avaliando custos de migração para sua situação específica, quebramos nossa abordagem de preço aqui — somos transparentes sobre o que esses projetos realmente custam.

FAQ

Quanto tempo uma migração típica de MODX para Next.js leva?

Para um site com 100-500 páginas, espere 6-10 semanas com uma equipe dedicada. Modelagem de conteúdo e migração leva cerca de 2 semanas, construir o front-end Next.js leva 3-5 semanas, e QA/testes/redirecionamentos preenchem o resto. Sites maiores com snippets customizados complexos ou integração de e-commerce pesada podem levar 12-16 semanas. A maior variável é quanto lógica PHP customizada precisa ser reescrita.

Posso manter meu painel admin MODX e apenas usar Next.js para o front-end?

Tecnicamente, sim — você poderia construir uma camada de API REST em MODX e consumi-la com Next.js. Mas isso lhe dá o pior dos dois mundos: você ainda mantém o servidor PHP, o banco de dados MySQL, e todas as preocupações de segurança, enquanto também mantém um front-end separado. A menos que você tenha uma razão muito específica, é melhor migrar conteúdo para um CMS headless propósito-construído.

Vou perder rankings de SEO durante a migração?

Não se você lidar com redirecionamentos corretamente. Os passos críticos são: manter a mesma estrutura de URL onde possível, configurar redirecionamentos 301 para qualquer URL que mude, manter seus metadados intactos, e enviar um sitemap atualizado para o Google Search Console após o lançamento. A maioria dos sites que migramos veem melhorias de ranking *dentro de 4-8 semanas devido a melhores pontuações de Core Web Vitals.

E sobre sites MODX com formulários FormIt e workflows complexos?

Formulários são uma das partes mais complicadas da migração. FormIt lidava com validação, envio de email, hooks e prevenção de spam tudo em um pacote. No Next.js, você combinará tipicamente Server Actions para processamento, Zod para validação, e um serviço como Resend ou SendGrid para entrega de email. É mais explícito mas também mais testável e confiável.

Next.js é exagerado para um site simples de brochura?

Talvez. Se seu site MODX é literalmente 10 páginas estáticas com um formulário de contato, Astro pode ser um melhor ajuste — ele envia zero JavaScript por padrão e é mais simples de configurar. Mas se há qualquer chance de você precisar de recursos dinâmicos, autenticação ou busca de dados complexa depois, começar com Next.js o salva de outra migração estrada abaixo.

O que acontece com minhas extras MODX e snippets customizados?

Eles precisam ser reconstruídos. Não há conversão automatizada. Snippets customizados se tornam rotas de API ou server actions em Next.js. Extras como Gallery, Articles ou MIGX são substituídas pelos recursos nativos de seu CMS headless (que geralmente são melhores). Extras de e-commerce como Foxy ou SimpleCart seriam substituídas pela Shopify Storefront API, Snipcart ou Medusa. Planeje este esforço explicitamente em sua timeline de migração.

Como convencer meus stakeholders não técnicos a aprovar essa migração?

Foque em três coisas que eles se importam: risco, custo e resultados. Risco: a comunidade encolhendo do MODX significa que encontrar desenvolvedores para emergências está ficando mais difícil a cada ano. Custo: manutenção de servidor e patching de segurança não são gratuitos, mesmo que a licença do CMS seja. Resultados: mostre-lhes a comparação de Core Web Vitals e explique como o Google usa velocidade de página como fator de ranking. Se seus competidores estão carregando em menos de um segundo e eles estão em 3 segundos, isso é um problema comercial.

Posso migrar incrementalmente ou precisa ser tudo de uma vez?

Migração incremental é possível usando uma configuração de reverse proxy — você serviria novas páginas do Next.js e rotearia páginas legadas para seu servidor MODX. Fizemos isso com configurações nginx onde caminhos específicos são proxied para o servidor antigo enquanto tudo mais vai para o deployment Next.js novo. Adiciona complexidade, mas para sites com centenas de páginas, permite migrar em fases ao longo de semanas ou meses ao invés de fazer um cutover arriscado big-bang.

Se você está sentado em um site MODX e sentindo os pontos de dor que descrevi, o melhor momento para começar a planejar é agora. Não porque o céu está caindo, mas porque migrações feitas sob pressão — após um breach de segurança, após seu desenvolvedor sair, após uma versão PHP atingir fim-de-vida — são sempre mais caras e mais estressantes que as planejadas. Entre em contato conosco se você quiser conversar sobre sua situação específica. Passamos por isso o suficiente para saber onde as minas terrestres estão.