Atualizar Moodle 4.5 para 5: Checklist Real de Quem Já Fez

O 5.3 LTS saiu e o 4.5 perde segurança em 2027. Banco, pasta /public, plugins e rollback: o que trava o upgrade na prática.

por Cleverson Gouvêa

Checklist para atualizar Moodle 4.5 para 5 com servidor, banco de dados e plugins

Quem precisa atualizar Moodle 4.5 para 5 hoje tem uma decisão maior do que parece: o destino certo, o banco de dados que vai junto e a pasta public que muda o servidor web. O Moodle 5.3 LTS saiu em 5 de outubro de 2026, e a janela de segurança do 4.5 fecha em outubro de 2027. Este é o checklist que eu sigo, do inventário ao plano de volta.

TL;DR

  • Destino: vá para o 5.3 LTS (segurança até 1º/10/2029). O 5.2 tem segurança só até 4/10/2027, a mesma data do 4.5: você faria todo o trabalho sem ganhar um dia de suporte.
  • O que mais trava: o banco. O 5.3 exige MariaDB 11.4, PostgreSQL 17 ou MySQL 8.4, e PHP 8.3. A maioria dos servidores que rodam 4.5 não atende.
  • O que mais quebra: a pasta /public (desde o 5.1), o roteador obrigatório (r.php) e plugins de terceiros que precisam ser movidos e atualizados.
  • Rollback: o Moodle não faz downgrade. Voltar atrás é restaurar código, moodledata e banco do mesmo instante. Sem esses três, não existe plano B.
  • Quando: homologue agora, rode em produção depois do 5.3.1 (previsto para 7/12/2026) e fora de semana de prova.

Administro ambientes Moodle desde 2008 e já levei instituições por vários ciclos de LTS. A parte difícil de atualizar nunca é o comando de upgrade. É o servidor que ninguém atualiza há anos, o plugin que um fornecedor abandonou e a falta de um caminho de volta testado. É disso que este guia trata, para quem responde pelo AVA (Ambiente Virtual de Aprendizagem) de uma instituição: coordenação de EAD ou TI.

Para onde atualizar Moodle 4.5 para 5 em 2026: o calendário decide

LTS significa Long-Term Support, suporte estendido. O Moodle lança duas versões por ano, em abril e outubro, e uma a cada três é LTS. O 4.5 é a LTS de outubro de 2024. A próxima é o 5.3, lançado agora. As datas abaixo são as publicadas na página oficial de releases do Moodle:

Versão Lançamento Correções gerais até Segurança até
4.5 (LTS) 07/10/2024 06/10/2025 04/10/2027
5.1 06/10/2025 05/10/2026 19/04/2027
5.2 20/04/2026 19/04/2027 04/10/2027
5.3 (LTS) 05/10/2026 04/10/2027 01/10/2029

A leitura que importa: o 4.5 já não recebe correção de bug comum desde outubro de 2025. Só patch de segurança. E o 5.2, que muita gente ainda considera "a versão estável", perde a segurança no mesmo dia que o 4.5.

Por isso, quando alguém me pede para atualizar Moodle 4.5 para 5 neste momento, a resposta é quase sempre o 5.3 LTS. O salto direto é suportado: o 5.3 aceita upgrade a partir do Moodle 4.4 ou superior, segundo as notas de release do 5.3. Não há etapa intermediária obrigatória.

Quando faz sentido parar no 5.2

Quase nunca. A exceção é a instituição que precisa de um recurso do 5.2 já, tem um plugin crítico que ainda não declarou compatibilidade com o 5.3 e aceita repetir o processo em 2027. Fora disso, é migrar duas vezes para chegar ao mesmo lugar.

Requisitos: o servidor que roda o 4.5 raramente roda o 5.3

Aqui mora o motivo número um de projeto atrasado. Os requisitos subiram em cada release desde o 4.5, e o 5.3 subiu de novo no banco de dados. Comparando os mínimos oficiais:

Componente Moodle 4.5 Moodle 5.3 LTS
PHP 8.1.0 8.3.0 (8.4 suportado)
MariaDB 10.6.7 11.4.0
PostgreSQL 13 17
MySQL 8.0 8.4
SQL Server 2017 2019
Oracle 19c não suportado (desde o 5.0)
Upgrade a partir de 4.1.2 4.4

Fontes: páginas de release do 4.5 e do 5.3.

Quem vai atualizar Moodle 4.5 para 5 precisa olhar o banco primeiro, porque é ele que pega instituição no contrapé. Quem fez o upgrade para o 5.0 ou 5.1 em 2025 subiu para MariaDB 10.11 e achou que estava resolvido. Para o 5.3, o mínimo passou a ser 11.4.0. No PostgreSQL, o piso foi para a versão 17.

O lado bom: o calendário do banco também melhora

O MariaDB 11.4 tem suporte até 29/05/2029 e o PostgreSQL 17 até 08/11/2029, segundo o endoflife.date. Ou seja, o banco novo acompanha o fim do suporte do 5.3 LTS. Já o PostgreSQL 14 perde suporte em 12/11/2026, e o MariaDB 10.6 já perdeu em julho de 2026. Se o seu servidor está aí, o problema é anterior ao Moodle.

Os três requisitos de PHP que derrubam instalação

  • Só PHP de 64 bits. Raro em Linux, comum em servidor Windows herdado.
  • Extensão sodium obrigatória. Em muitas distribuições vem em pacote separado.
  • max_input_vars maior ou igual a 5000. O padrão do PHP é 1000. Com ele, formulários grandes, como a página de notas de uma turma cheia, salvam pela metade sem mostrar erro.

O detalhe completo de CPU, RAM e dimensionamento está no nosso guia de requisitos de servidor para Moodle 5.x. Antes de qualquer coisa, abra Administração do site → Servidor → Verificação do ambiente: o próprio Moodle mostra em vermelho o que impede o upgrade.

A pasta /public e o roteador: a mudança que exige mexer no servidor web

O Moodle 5.1 reorganizou os arquivos. Tudo o que é acessível pela web passou para uma subpasta /public, e arquivos sensíveis ficam acima dela. Quem vai atualizar Moodle 4.5 para 5 nunca passou por isso, então essa etapa cai inteira no seu upgrade.

Na prática, três coisas mudam:

  1. O DocumentRoot muda. O servidor web (Apache ou Nginx) precisa apontar para moodle/public, e não mais para moodle. A documentação oficial de upgrade é direta: sem reconfigurar o servidor, o upgrade não avança.
  2. O config.php fica na raiz. Ele volta para a pasta principal do Moodle, não para dentro de public.
  3. Plugins de terceiros precisam ser movidos. Os que já estavam instalados continuam no lugar antigo, acima de /public. Cada um tem de ir para o caminho equivalente dentro da nova estrutura. As notas do 5.1 avisam isso com todas as letras.

O roteador deixou de ser opcional

Junto com a pasta public veio o roteador do Moodle. Segundo a documentação Configuring the Router, a configuração é obrigatória a partir do 5.1. No Apache, isso é um FallbackResource /r.php dentro do bloco <Directory>. No Nginx, um try_files $uri /r.php;. Depois, você informa ao Moodle com $CFG->routerconfigured = true; no config.php.

Esquecer o roteador não derruba o site inteiro. Gera páginas específicas em 404 e um alerta de "router not configured" na verificação do ambiente. É o tipo de defeito que só aparece quando um professor tenta abrir uma tela pouco usada, dias depois.

O que sai do núcleo entre o 4.5 e o 5.3

Este é o item que a coordenação pedagógica precisa ver antes da TI. Ao atualizar Moodle 4.5 para 5 você herda de uma vez tudo o que saiu do núcleo entre as versões 5.0 e 5.3, segundo as notas oficiais:

  • Editor Atto (5.0): o TinyMCE assume. Conteúdo antigo continua lá; o que muda é o editor que o professor usa.
  • Atividades Chat e Pesquisa (Survey) (5.0): saem do pacote padrão. Se algum curso usa, decida antes o que fazer com os dados.
  • Autenticação CAS e todos os plugins de MNet (5.0): se o login institucional depende de CAS, isso é bloqueante. Precisa de alternativa (SAML, OAuth 2) antes da data.
  • Filtro MimeTeX (5.2): quem usa fórmulas em TeX precisa conferir o filtro configurado.
  • Tema Classic (5.3): quem ainda roda Classic, ou um tema filho dele, precisa migrar para Boost ou para um tema próprio compatível.

Nenhum desses itens aparece como erro no upgrade. Eles aparecem como professor reclamando na segunda-feira. Por isso entram no inventário, não no dia da virada.

Plugins: o inventário que decide o prazo

Em quase todo projeto para atualizar Moodle 4.5 para 5 que conduzo, o cronograma é definido pelo plugin mais atrasado, não pelo Moodle. O processo que funciona:

1. Liste tudo o que não é do núcleo

Em Administração do site → Plugins → Visão geral dos plugins, filtre os adicionais. Exporte a lista. Para cada um, anote: quem mantém, versão instalada, se está em uso e qual curso depende dele.

2. Classifique em três grupos

  • Compatível: o diretório de plugins do Moodle já declara suporte ao 5.3. Baixe a versão nova.
  • Sem sinal de vida: última versão antiga, autor sem resposta. Aqui está o risco real. Ou alguém assume a manutenção, ou o plugin sai.
  • Feito sob medida: desenvolvido para a instituição. Precisa de revisão de código contra as APIs descontinuadas, que o 5.2 marcou como remoção final de métodos antigos das versões 2.x, 3.x e 4.x.

3. Corte o que ninguém usa

Plugin instalado e sem uso é só custo de upgrade. Atualizar Moodle 4.5 para 5 é o melhor momento para desinstalar o que ficou de projetos antigos. Menos plugin, menos superfície de ataque e menos tempo de homologação.

Checklist para atualizar Moodle 4.5 para 5 sem surpresa

Esta é a sequência que eu sigo. Ela parte de um ambiente de homologação, uma cópia fiel de produção onde tudo é testado antes.

Antes (2 a 6 semanas)

  1. Rodar a verificação do ambiente apontando para o 5.3.
  2. Subir PHP 8.3 e o banco novo (MariaDB 11.4 ou PostgreSQL 17) em homologação.
  3. Clonar produção para homologação: código, moodledata e banco.
  4. Fazer o inventário de plugins e resolver os bloqueantes.
  5. Testar com professores reais os fluxos críticos: questionário, envio de tarefa, livro de notas, emissão de certificado, matrícula automática.
  6. Medir o tempo do upgrade em homologação. Esse número define a janela de manutenção.

No dia

  1. Avisar alunos e professores com antecedência, com data e horário da parada.
  2. Ativar o modo de manutenção. O script de upgrade não faz isso sozinho.
  3. Fazer o backup completo dos três itens (veja a próxima seção).
  4. Trocar o código, copiar o config.php para a raiz, mover os plugins para dentro de /public.
  5. Ajustar DocumentRoot e roteador no servidor web.
  6. Rodar o upgrade pela linha de comando com php admin/cli/upgrade.php, a opção que a documentação recomenda para sites grandes.
  7. Purgar caches, revisar a verificação do ambiente e testar os fluxos críticos antes de liberar.

Depois (primeira semana)

Depois de atualizar Moodle 4.5 para 5 acompanhe os logs de erro do PHP, tarefas agendadas (cron) e tempo de resposta. Upgrade grande costuma reconstruir índices e caches, e o primeiro dia de uso real é mais pesado. Se o AVA ficar arrastado, o roteiro de diagnóstico de Moodle lento ajuda a separar problema de upgrade de problema antigo de infraestrutura.

Rollback: o plano B que precisa existir antes de começar

Antes de atualizar Moodle 4.5 para 5 saiba: o Moodle não tem downgrade. Depois que o upgrade grava a versão nova no banco, o código antigo se recusa a rodar sobre ele. Voltar atrás significa restaurar o estado anterior inteiro.

A documentação oficial lista os três itens do backup, e todos precisam ser do mesmo instante:

Item O que é Como eu faço
Código A pasta do Moodle com plugins e config.php Manter a pasta antiga intacta e subir a nova ao lado
moodledata Arquivos enviados, caches, sessões Cópia com rsync com o site em manutenção
Banco Todas as tabelas Dump completo (ou snapshot do volume) após ativar a manutenção

Três regras que tornam o rollback real, e não só uma intenção:

  • Teste a restauração em homologação. Backup nunca restaurado é hipótese. Temos um texto inteiro sobre isso: backup do Moodle e a rotina de restauração.
  • Defina o critério de volta antes. Exemplo: se em duas horas após o upgrade o questionário ou o livro de notas não funcionar, volta. Decidido na véspera, não às 23h com o diretor no telefone.
  • Tudo o que entrar depois do upgrade se perde no rollback. Por isso a liberação para alunos só acontece depois dos testes finais.

Quando NÃO atualizar agora

Atualizar Moodle 4.5 para 5 é obrigatório até outubro de 2027, para quem quer continuar recebendo patch de segurança. Fazer isso nesta semana, não. Segure o upgrade quando:

  • For semana de prova, fechamento de notas ou início de semestre. A janela certa é a de menor uso, e ela está no calendário acadêmico, não no da TI.
  • Algum plugin crítico não tiver versão para o 5.3. Rodar o Moodle novo sem a integração com o sistema acadêmico é pior do que esperar alguns meses.
  • Não houver homologação. Upgrade direto em produção, saltando três ciclos de mudança, é aposta.
  • Você estiver pensando em ir no dia do lançamento. O 5.3.0 acabou de sair. O calendário oficial prevê o 5.3.1 para 7 de dezembro de 2026. Homologar agora e virar produção depois dessa primeira correção é o ritmo que eu recomendo.

Esperar demais também custa. Quem deixar para setembro de 2027 vai disputar a janela com o próprio semestre e, dias depois, ficar sem patch de segurança.

Como a Agathas Web resolve isso

Atualizar Moodle 4.5 para 5 é exatamente o tipo de projeto descrito na nossa página de serviços Moodle. Nosso time tem a Moodle Developer Certification, da Moodle Academy, e conduz migração entre versões, da linha 3.x até a 5.x, e entre servidores. Somos uma empresa independente de serviços, não um Moodle Partner.

Na prática, o processo é este:

  1. Diagnóstico gratuito de 1 hora. Entendemos versão atual, servidor, plugins, integrações e calendário acadêmico.
  2. Proposta técnica. Documento com a versão de destino, a infraestrutura necessária, a lista de plugins e o que fazer com cada um, cronograma e investimento. A cobrança considera a complexidade do banco e o volume de dados, e a proposta sai em até 5 dias úteis.
  3. Homologação e execução. Montamos a cópia de produção, resolvemos plugins e tema, testamos com a sua equipe e executamos a virada na janela combinada, com backup e critério de rollback definidos antes.
  4. Acompanhamento após o go-live. Ficamos de perto nas primeiras semanas.

Quem não quer passar por isso a cada ciclo pode manter o ambiente em sustentação com SLA mensal: atualizações de segurança e de versão, monitoramento 24/7, backup verificado e suporte por WhatsApp em horário comercial, a partir de R$ 800/mês. O código dos plugins customizados e os dados ficam com a instituição, sem lock-in. Se o gargalo for o servidor, a hospedagem Moodle já sai com PHP, banco e cache ajustados para a versão nova.

Para agendar o diagnóstico, use o formulário ou o WhatsApp da página de serviços Moodle da Agathas Web.

Conclusão: atualizar Moodle 4.5 para 5 é um projeto, não um comando

O caminho em uma frase: vá direto para o 5.3 LTS, comece pelo banco e pelo PHP, trate a pasta /public e o roteador como parte do escopo, faça o inventário de plugins antes de marcar data e só vire produção com o rollback testado.

O prazo real é 4 de outubro de 2027, quando o 4.5 deixa de receber segurança. Para uma instituição com dois semestres no meio, isso é menos tempo do que parece. Quem começa a homologação agora vira produção com calma no recesso. Quem deixa para depois vai atualizar Moodle 4.5 para 5 com pressa, e pressa é onde o upgrade dá errado.

Se você quer um cronograma realista para o seu ambiente, peça o diagnóstico gratuito em serviços Moodle. Você sai com versão de destino, lista de bloqueantes e janela sugerida.

Perguntas frequentes

Posso pular direto do Moodle 4.5 para o 5.3 LTS?

Sim. Segundo as notas oficiais de release, o Moodle 5.3 aceita upgrade a partir da versão 4.4 ou superior, então o 4.5 vai direto, sem passar por 5.0, 5.1 ou 5.2. O salto é suportado, mas concentra três ciclos de mudança em um único evento: banco e PHP novos, pasta /public, roteador obrigatório e remoção de Atto, Chat, Survey, CAS, MNet e tema Classic do núcleo. Por isso o salto direto só é seguro com um ambiente de homologação, que é uma cópia fiel de produção onde todos os fluxos críticos são testados antes da virada.

Dá para voltar para o Moodle 4.5 se o upgrade der errado?

Não por downgrade. Depois que o upgrade grava a nova versão no banco, o código antigo não roda mais sobre ele. O único caminho de volta é restaurar os três itens do backup feito no mesmo instante, com o site em manutenção: a pasta de código, o moodledata e o banco de dados. Tudo o que for criado depois do upgrade se perde nessa restauração. Por isso definimos o critério de rollback antes, por exemplo, voltar se o questionário ou o livro de notas falhar nas primeiras duas horas, e só liberamos o acesso aos alunos depois dos testes.

Quanto tempo o Moodle fica fora do ar durante a atualização?

Depende do tamanho do banco, do volume do moodledata e da quantidade de plugins, por isso não existe número genérico honesto. O jeito certo é medir: rodar o upgrade completo no ambiente de homologação com uma cópia de produção e cronometrar. Some a esse tempo o backup, a troca de código, o ajuste do servidor web e os testes finais. Esse total define a janela de manutenção, que deve cair no período de menor uso do calendário acadêmico, nunca em semana de prova ou de fechamento de notas.

Vale a pena atualizar para o Moodle 5.2 em vez do 5.3?

Na maioria dos casos, não. O Moodle 5.2 recebe patches de segurança só até 4 de outubro de 2027, a mesma data em que o 4.5 LTS perde o suporte. Você faria todo o trabalho de upgrade sem ganhar um dia de proteção. O 5.3 LTS tem segurança até 1º de outubro de 2029. A exceção é quem depende de um plugin crítico que ainda não tem versão para o 5.3 e aceita repetir o upgrade em 2027.

Meus plugins do Moodle 4.5 vão funcionar no 5.x?

Não há garantia. Cada plugin de terceiros precisa de uma versão que declare compatibilidade com a versão de destino, e desde o 5.1 todos precisam ser movidos para dentro da pasta /public. Plugins feitos sob medida exigem revisão de código, porque o 5.2 fez a remoção final de métodos antigos das versões 2.x, 3.x e 4.x. O caminho é inventariar tudo em Visão geral dos plugins, classificar em compatível, abandonado ou customizado, e desinstalar o que ninguém usa antes de marcar a data.