Upgrade Moodle: os riscos críticos antes de decidir

1. Por que só vale planejar upgrade para uma LTS

O Moodle HQ adota um modelo de release com versões intermediárias e versões LTS (Long Term Support) com janela de suporte estendida — política documentada em docs.moodle.org/dev/Releases. Para qualquer projeto que precise estabilidade operacional, só faz sentido planejar upgrade para uma LTS.

Versões intermediárias recebem patches por menos tempo. Ir para elas significa fazer outro upgrade em pouco tempo. Quem opera Moodle em produção sabe: upgrade não é coisa que se faz duas vezes seguidas se puder evitar.

Critérios objetivos para escolher uma LTS:

• Ciclo de suporte garantido — patches de segurança por pelo menos 24 meses após o release.
• Compatibilidade com plugins de terceiros — autores de plugins importantes (BigBlueButton, H5P, Edwiser, NextSheet) tipicamente prio­rizam compatibilidade com LTS, não com intermediárias.
• Documentação mantida — docs.moodle.org cobre LTS com detalhe maior.
• Estabilidade do schema — entre LTS o schema do banco muda pouco, o que facilita rollback se necessário.

Regra prática: se a versão de destino não é LTS, não é projeto sério de upgrade — é experimento. E experimentos não vão para produção sem rollback rápido.

2. Por que o upgrade não pode ser direto

Esta é a pergunta que mais ouvimos em projeto novo: "Posso ir direto da versão antiga para a LTS atual?". Não.

O caminho de upgrade entre versões do Moodle é definido pela política oficial Moodle (docs.moodle.org/dev/Releases). O instalador valida a versão de origem antes de aplicar migrações de schema e recusa saltos entre LTS não-adjacentes. Em casos piores, roda parcialmente e corrompe o schema de forma silenciosa — só fica visível depois, quando algum recurso quebra ou um relatório vira impossível de gerar.

O caminho válido (e a tabela de versões intermediárias exigidas como ponte) muda a cada novo release do Moodle. Por isso o caminho específico do seu upgrade é definido na auditoria técnica inicial, contra a versão alvo e segundo a documentação oficial vigente no momento do projeto. Não é informação que se decide por blog — é informação que se decide por auditoria.

Implicação prática: qualquer fornecedor que prometer "upgrade direto" ou que não conseguir explicar o caminho oficial Moodle aplicável ao seu ambiente é candidato a corromper o seu banco.

3. Os 6 riscos críticos que aparecem em quase 100% dos casos

Em quase uma década atendendo upgrades reais de Moodle 3.x para versões mais novas, identificamos uma constância impressionante: seis problemas técnicos aparecem em quase todos os ambientes legados. Independente do setor, do tamanho, do orçamento ou da maturidade da equipe de TI do cliente.

A auditoria pré-upgrade é desenhada para detectar esses seis riscos antes de qualquer orçamento. Quando aparecem (e sempre aparecem), o escopo do upgrade muda — e cliente entende por que upgrade não é "rodar update". Mais sobre isso na página de auditoria de segurança.

4. Quatro tipologias reais de Moodle legado

Diferente de comparar caso a caso (cada cliente é único), faz mais sentido reconhecer arquétipos recorrentes. Em quase uma década de operação, 90% dos projetos cabem numa das quatro tipologias abaixo. Identificar a sua antes do escopo evita surpresas.

Tipo 01 · Educativo multi-tenant

Escola ou instituto com matriz + N subdomínios regionais ou de filiais, todos no mesmo core Moodle legado. Múltiplos subdomínios, dataroot pesado. Cada subdomínio tem admin local mas ninguém atualiza o core. Cron parado há anos. Plugins de relatórios descontinuados. Padrões de uso heterogêneos entre filiais (uma usa pesado, outra mal entra). Prazo e janela de manutenção definidos após auditoria, fora do calendário letivo.

Tipo 02 · Corporativo H5P-heavy

Empresa cujo departamento de T&D investiu em conteúdo interativo H5P em larga escala. Centenas de atividades, milhares de attempts acumulados, notas e progresso entram no histórico oficial de colaboradores. Não podem perder dados — é compliance interna. Não tinham plano para a deprecação do módulo H5P antigo. Projeto sempre bundled com migração de conteúdo H5P, com garantia contratual de integridade.

Tipo 03 · Governo / setor público

Município, universidade pública ou órgão. Infraestrutura própria, restrições de licitação ou de processo de compra, integração SSO obrigatória (LDAP corporativo, SAML institucional, Gov.br), compliance LGPD pesada documentada, equipe interna de TI envolvida em cada decisão. Janela de manutenção restrita a horário não letivo ou fora do expediente público. Sign-off escrito de cada etapa exigido. Cronograma mais lento porque governance é mais lento — definido no escopo inicial.

Tipo 04 · PME com tema customizado

Escola pequena, instituto privado ou empresa de cursos com investimento pesado em branding via tema customizado. Pode ser um tema premium pago ou um tema gratuito customizado. O tema antigo não é compatível com versões atuais out-of-the-box. Cliente não aceita perder identidade visual. Adaptamos preservando a marca, sem mover o core. Geralmente o tema é entregue antes do upgrade do core (staging serve para validar o visual).

Tipologias mistas existem — escola privada com tema custom + H5P em produção combina três tipologias ao mesmo tempo. Universidade com migração H5P + SSO combina duas. A auditoria inicial mapeia qual mix você tem e ajusta cronograma — sempre definido no escopo inicial, nunca por estimativa cega.

5. Stack do servidor: quem dita as regras

A regra que mais derruba orçamento por surpresa: cada versão LTS do Moodle exige uma faixa de stack específica — versão de PHP, versão de banco de dados, configuração de cache. Não basta "ter PHP novo" — uma versão muito nova também quebra, porque plugins de terceiros e o próprio core ainda não foram testados nela.

Quem define essa matriz é a Moodle HQ, na documentação oficial (docs.moodle.org/dev/Releases). A faixa muda a cada release e é informação que se valida no momento do projeto, não meses antes pelo blog — porque entre o blog e o projeto o Moodle pode lançar uma nova LTS, mudar requisitos mínimos ou retirar suporte de uma versão de PHP.

Implicação prática para quem está decidindo o upgrade:

• Não confie em "a gente atualiza o PHP depois" — o instalador do Moodle valida a versão do stack antes de rodar e recusa avançar se estiver fora da faixa exigida.
• Não suba para a versão mais nova de PHP "porque é a mais nova" — uma versão acima da máxima testada pela Moodle HQ gera warnings, quebras em plugins de terceiros e dor de cabeça em produção.
• Cada plugin de terceiros precisa avaliação individual de compatibilidade — afirmação genérica do autor ("suporta Moodle X.Y") não substitui validação real contra a versão alvo. Quando um plugin crítico não é compatível, três decisões possíveis: aguardar update do autor, fazer fork, ou substituir por equivalente — decisão documentada antes do projeto começar.
• O gap de stack faz parte do orçamento do upgrade — não é "item extra" que aparece no meio. A auditoria prévia mapeia stack atual versus stack exigido pela versão alvo, com tudo no escopo inicial.

6. Padrões de risco em upgrades auto-conduzidos

Antes de chegar para a gente, alguns clientes tentaram (ou sua equipe interna tentou) o upgrade sozinhos. Os padrões de risco são tão repetidos que viraram quase folclore. Resumimos abaixo o sintoma e a consequência — o "como evitar" entra no escopo do projeto, não no blog:

Padrão 1 · Não conseguir isolar onde quebrou

Upgrade roda em sequência mas sem pontos de retorno entre as etapas. Quando algo quebra no fim, não dá para identificar onde apareceu o problema. Refaz tudo do começo. Custo: dias perdidos.

Padrão 2 · Stack atualizado fora de ordem

Equipe atualiza PHP, banco ou cache na ordem errada em relação ao upgrade do Moodle. O instalador valida o stack antes de aplicar migrações e recusa rodar — ou pior, roda parcialmente e deixa o banco em estado inconsistente.

Padrão 3 · Upgrade interrompido no meio

Upgrade rodado pela interface gráfica em ambiente que não comporta a duração. A sessão expira no meio. O banco já foi parcialmente migrado, o código já mudou, mas as últimas etapas não rodaram. Recuperar exige restore de backup — se o backup existir e for válido.

Padrão 4 · Plugins descontinuados deixam lixo

Plugins descontinuados nem sempre desinstalam limpamente quando o core já passou da versão que os suportava. Ficam tabelas órfãs, configurações zumbi e erros em telas de admin que ninguém entende meses depois.

Padrão 5 · Backup do hosting sem teste

Backup automático do hosting é frequentemente parcial (só banco, ou só arquivos) ou em formato proprietário que não restaura em outro lugar. Descobrir isso durante um problema de upgrade é o pior cenário possível.

Padrão 6 · Validação só técnica

Equipe técnica valida que "subiu, login funciona, cursos abrem". Mas o aluno reclama que a atividade H5P perdeu o progresso, o professor não consegue lançar nota porque o gradebook mudou layout, o RH não acha o relatório que sai todo mês. Validação real exige casos de uso de cada perfil, com pessoas reais — não só equipe técnica.

7. O que precisa ser mapeado na auditoria pré-upgrade

Antes de orçar um upgrade, a auditoria mapeia quatro grandes blocos de informação. O detalhe técnico de cada bloco vai além de um checklist público — entra no escopo da auditoria propriamente dita:

Ambiente atual

Versão e estado da plataforma, configuração do servidor, estado do agendador de tarefas, infraestrutura de hosting. O objetivo é mapear o gap real até a versão alvo, em vez de assumir.

Conteúdo e uso

Volume de cursos, perfis de uso, plugins de terceiros em produção, tipo de conteúdo interativo, customizações de tema. O objetivo é antecipar quais decisões de "manter, migrar, recriar" o cliente vai precisar tomar.

Integrações ativas

SSO, sistemas externos, pagamento, videoconferência, webhooks. Cada integração ativa entra na fase de validação pós-upgrade porque pode quebrar silenciosamente. Mapear antes evita ter que descobrir em produção.

Operação

Estado do backup (e se ele já foi testado), janela de manutenção possível, responsável técnico, compliance aplicável (LGPD/GDPR/CNPD/ISO). Esses fatores impactam diretamente cronograma e modelo de execução.

Quando esses quatro blocos estão mapeados, o orçamento é específico e realista em vez de chute. O prazo é definido após auditoria, com cláusula contratual. E o cronograma é defensável. É por isso que nunca damos orçamento de upgrade sem auditoria prévia — e por isso também não publicamos o checklist completo: ele é o nosso processo, não um material de blog.

8. Conclusão prática

Upgrade de Moodle não é "rodar update". É processo técnico definido pela política oficial Moodle, com riscos críticos quase universais, tipologias de cenário recorrentes e implicações de stack que afetam plugins de terceiros e a continuidade da operação.

O ponto deste artigo não é ensinar a fazer — é dar a você elementos para decidir. Decidir se está em situação de risco. Decidir se a tipologia da sua plataforma exige tratamento especial. Decidir se vale terceirizar ou tentar in-house. Decidir em que prazo agir.

Para quem pensa em fazer in-house: é possível, se a equipe interna tem expertise técnica sólida, conhece a política oficial Moodle vigente, está disposta a investir em ambiente de staging e validação real. Para quem não tem esse luxo de tempo e expertise, terceirizar com quem já fez muitos upgrades vale o investimento — porque o custo de quebrar um Moodle em produção (perda de dados, downtime no semestre, conflito com cliente) é absurdamente maior que o custo do upgrade bem feito.

Se você está em uma versão legada de Moodle agora, vale uma decisão consciente: ou planeja o upgrade nos próximos meses (antes da próxima auditoria, antes do próximo semestre, antes do próximo audit de compliance), ou aceita que a plataforma vai virar dívida técnica acelerada. Não tem terceira opção.

O caminho prático: diagnóstico técnico de upgrade em 2 minutos (gratuito, sem cadastro) ou entrevista inicial de 30 minutos para definir escopo, prazo e orçamento fechados antes de qualquer compromisso.