Sua instalação MODX inicia em 1,2 segundos — respeitável para um CMS PHP construído em 2005. Você abre o painel do gerenciador e percebe que a última atualização do núcleo saiu há onze meses. O canal Slack que você costumava frequentar para ajuda com snippets agora vê três posts por semana, reduzido de tópicos diários em 2019. Seu desenvolvedor flutua a ideia de 'explorar opções' durante a standup, e você sabe o que isso significa.

Trabalhei com MODX Evolution por seis anos. Escrevi snippets personalizados, lutei com variáveis de template até as 2 da manhã, e defendi sua flexibilidade em pitches de agência. Este não é um ataque. É reconhecimento de padrões: o abandono de plugins acelerou 40% entre 2024 e agora, provedores de hospedagem descontinuaram silenciosamente pilhas otimizadas para MODX, e a lacuna entre o que seu site pode fazer versus o que os prospectos esperam virou um abismo. A questão não é se deve migrar — é se você se move agora ou espera até algo quebrar durante um lançamento de campanha.

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

Deixe-me caminhar com você pelo porquê — honestamente, sem o hype.

Índice

Por que usuários de MODX devem migrar para Next.js em 2026: Uma perspectiva honesta

O estado do MODX em 2026

Vamos examinar os números honestamente. MODX 3.x existe há um tempo, mas a adoção tem sido... tépida. Os fóruns MODX, que costumavam estar repletos de atividade, agora veem talvez um punhado de posts por semana. O repositório oficial do GitHub mostra atividade de commit cada vez mais esparsa. Compare isso com 2018 ou 2019 quando a comunidade ainda estava pressionando com força.

Os dados BuiltWith de início de 2026 estimam que MODX alimenta aproximadamente 0,3% dos sites detectados de CMS, reduzido de cerca de 0,7% em 2021. WordPress ainda domina com ~62%, e novos players como sites baseados em Next.js (geralmente emparelhados com CMSes headless) estão crescendo a aproximadamente 40% ano a ano.

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

Não estou dizendo que 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 amontoar mais, crédito aonde é devido. MODX acertou várias coisas que a maioria dos CMSes ainda erra:

Flexibilidade verdadeira de conteúdo

MODX nunca o forçou ao paradigma "post e página". Variáveis de template, chunks e snippets ofereceram liberdade genuína de modelagem de conteúdo anos antes de "conteúdo estruturado" virar uma palavra-chave. Você podia construir qualquer coisa.

Saída limpa

MODX não injetava sua própria marcação. Nenhuma classe CSS misteriosa, nenhuma div envolvente que você não pediu. Seu HTML era seu HTML. Para desenvolvedores front-end que se importavam com o ofício, isso era uma revelação.

Temas amigáveis para desenvolvedores

Sem sistema de temas para aprender, sem hierarquia de template 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 quiser sobre [[*pagetitle]] e [[!MySnippet]] — uma vez que você a aprendeu, podia construir páginas complexas rápido. A camada de cache com a flag ! não cacheable era elegante.

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

Os problemas que você não pode mais ignorar

Aqui é onde preciso ser franco.

Preocupações de segurança

MODX 3.x abordou muitas vulnerabilidades históricas, mas executar qualquer monólito PHP com um painel de 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 uma equipe de segurança em encolhimento, os tempos de resposta não estão melhorando.

Compare isso com um site Next.js implantado no Vercel ou Netlify — literalmente não há servidor para atacar. Sem painel de admin para fazer brute-force. Sem 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 a vaga 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.

Este não é uma preocupação teórica. Conversei 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

MODX 3.x roda em PHP 8, mas muitos extras não. Se você construiu um site que depende de snippets ou plugins de terceiros, atualizar PHP geralmente quebra as coisas. Você acaba preso 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 de borda. Sem ISR. Posso continuar.

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

Teto de performance

MODX pode ser rápido — construí sites sub-2-segundo nele. Mas para chegar lá é necessário otimização significativa: cache de página inteira, configuração de CDN, ajuste de banco de dados e arquitetura cuidadosa de snippet. Next.js oferece performance sub-segundo essencialmente fora da caixa com geração estática. Você está lutando por performance em MODX; em Next.js, você está lutando para estragar.

Por que usuários de MODX devem migrar para Next.js em 2026: Uma perspectiva 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 as opções válidas, mas Next.js atinge o ponto doce para a maioria das migrações MODX. Aqui está o porquê:

A flexibilidade de renderização espelha o pensamento MODX

Desenvolvedores MODX já entendem que diferentes páginas precisam de diferentes estratégias de cache. Em MODX, você marcaria snippets como cacheable ou uncacheable. Em 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 componente substitui chunks

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

Rotas de API substituem snippets

Snippets MODX tratam lógica do lado do servidor — processamento de formulário, chamadas de API, consultas customizadas. As rotas de API Next.js (ou Server Actions em 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 muito conteúdo 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 ficar 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, variável de template 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 (texto rico)
- 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 ótima ferramenta de exportação. Você provavelmente precisará escrever um snippet customizado ou script que consulte modx_site_content e suas tabelas de TV, depois output JSON:

<?php
// Quick and dirty MODX content export
$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 de destino. É trabalho inglório, 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 de template MODX → layout de página pode se parecer com:

Conceito MODX Equivalente Next.js
Template Componente de layout
Chunk Componente React
Snippet Server Action / rota de API
Variável de template Campo de 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: Manipular redirecionamentos de URL

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

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

Não pule isso. Seu SEO depende disso.

Passo 5: Executar em paralelo por 2-4 semanas

Implante Next.js ao lado de seu site MODX existente. Teste tudo. Verifique a analytics. Verifique que formulários funcionam. Depois mude o DNS.

Escolhendo um CMS headless para substituir 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 Precificação (2026) Opção auto-hospedada
Sanity Média Excelente (schemas definidos em código) Nível gratuito, depois $15/usuário/mês Não (somente nuvem)
Strapi Baixa Boa (baseada em UI) Gratuito (auto-hospedado), Nuvem a partir de $29/mês Sim
Contentful Média Boa Nível gratuito, depois $300/mês Não
Payload CMS Baixa Excelente (schemas definidos em código) Gratuito (auto-hospedado), Nuvem a partir de $50/mês Sim
Directus Baixa Flexível Gratuito (auto-hospedado), Nuvem a partir de $99/mês Sim

Se você amava a flexibilidade MODX e a capacidade de auto-hospedagem, Payload CMS ou Strapi parecerão mais familiares. Se você quer a melhor experiência de desenvolvedor e não se importa com somente nuvem, Sanity é difícil de bater.

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

Ganhos reais de performance: antes e depois

Migrei um site MODX de tamanho médio (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 Aprovação total ✅
Tempo de construção/deploy FTP manual Auto-deploy 42s Noite e dia
Custo mensal de hospedagem $45/mês (VPS) $0 (nível gratuito Vercel) -100%

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

O que você sentirá falta (e o que não sentirá)

Você sentirá falta

  • A UI do gerenciador: O painel de admin MODX é genuinamente intuitivo para editores de conteúdo. A maioria dos painéis de admin CMS headless tem uma curva de aprendizado.
  • Edição em contexto: Editar conteúdo onde você o vê renderizado. A maioria das configurações headless exigem alternar entre CMS e visualização. (A ferramenta Presentation do Sanity e o Live Preview do Payload estão fechando essa lacuna.)
  • Simplicidade: Um servidor, um banco de dados, uma base de código. Há beleza nisso. Uma pilha headless tem mais partes móveis.
  • O vibe da comunidade: A comunidade MODX, apesar de pequena, era unida e genuinamente prestativa.

Você não sentirá falta

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

Comparação de custos: executar MODX vs Next.js

Vamos ser reais sobre custo total de propriedade, não apenas hospedagem.

Categoria de custo MODX (Anual) Next.js + CMS Headless (Anual)
Hospedagem $540-$1.200 (VPS/compartilhado) $0-$240 (Vercel/Netlify)
Licença de CMS $0 (código aberto) $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 do servidor $500-$2.000 (tempo ou terceirizado) $0
Taxa de desenvolvedor horária $75-$120 (talento escasso) $100-$175 (talento abundante)
Total (excluindo tempo de dev) $1.240-$4.400 $0-$3.840

O curinga é as taxas dos desenvolvedores. Desenvolvedores MODX são mais baratos por hora se você conseguir encontrá-los. Mas a escassez aumenta as taxas ao longo do tempo, e você geralmente fica preso com quem estiver disponível em vez de escolher o melhor ajuste.

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

Perguntas frequentes

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

Para um site com 100-500 páginas, espere 6-10 semanas com uma equipe dedicada. A modelagem e migração de conteúdo 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 lógica customizada complexa ou integração de e-commerce pesada podem levar 12-16 semanas. A variável mais significativa é quanto PHP customizado precisa ser reescrito.

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

Tecnicamente, sim — você poderia construir uma camada de API REST em MODX e consumir com Next.js. Mas isso oferece 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 de propósito específico.

Vou perder classificações de SEO durante a migração?

Não se você manipular os redirecionamentos adequadamente. As etapas críticas são: manter a mesma estrutura de URL quando possível, configurar redirecionamentos 301 para qualquer URL que mude, manter seus metadados intactos e submeter um sitemap atualizado ao Google Search Console após o lançamento. A maioria dos sites que migramos vê melhorias de classificação *dentro de 4-8 semanas devido a melhores pontuações de Core Web Vitals.

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

Formulários são uma das partes mais complicadas da migração. FormIt manipulava validação, envio de email, hooks e prevenção de spam tudo em um pacote. Em Next.js, você tipicamente combinaria 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 é excessivo para um site brochura simples?

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

O que acontece com minhas extras e snippets customizados MODX?

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 API Storefront do Shopify, Snipcart ou Medusa. Planeje esse esforço explicitamente em sua linha do tempo 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 encolhida 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 se a licença de CMS for. Resultados: mostre-lhes a comparação de Core Web Vitals e explique como Google usa velocidade de página como fator de classificação. Se seus concorrentes estão carregando em menos de um segundo e eles em 3 segundos, isso é um problema de negócio.

Posso migrar incrementalmente ou tem que ser tudo de uma vez?

Migração incremental é possível usando uma configuração de proxy reverso — você serviria páginas novas de Next.js e rotearia páginas legadas para seu servidor MODX. Fizemos isso com configurações nginx onde caminhos específicos são proxiados para o servidor antigo enquanto tudo mais vai para a implantação Next.js nova. Adiciona complexidade, mas para sites com centenas de páginas, permite que você migre em fases ao longo de semanas ou meses em vez de fazer uma cutover arriscada de big-bang.

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