Migrar um Moodle muito antigo: o upgrade encadeado

Caso real de produção, contado sem identificar o cliente. Uma entidade de formação profissional certificada rodava um Moodle da linha 3.x: muito desatualizado, com mais de uma centena de cursos e várias centenas de usuários. Sem suporte, com PHP antigo, o cron parado havia muito tempo e sem conseguir instalar nada moderno. A pergunta que chegou foi a de sempre: "dá para atualizar direto para a versão nova?"
Não dá. E o motivo é justamente o que mais gente ignora.
Por que o salto direto não funciona
O Moodle só suporta upgrade a partir de certas versões de origem. Pular de uma linha muito antiga direto para a atual não é suportado: o instalador recusa ou o banco quebra no meio. O caminho correto é o upgrade encadeado: subir por versões intermediárias, uma de cada vez, respeitando em cada etapa a versão de PHP que aquela versão do Moodle exige. PHP a mais quebra tanto quanto PHP a menos.
O diagnóstico antes de tocar em qualquer coisa
Antes de subir uma linha sequer, mapeamos: qual a sequência de saltos suportada, qual matriz de PHP por etapa, e quais plugins legados vão dar problema. O caso clássico é o conteúdo interativo (H5P): o componente antigo foi descontinuado e precisa ser convertido para o componente atual do Moodle, senão o conteúdo simplesmente para de funcionar depois do upgrade. Isso vira uma etapa própria dentro do projeto.
Como foi feito, por fases
- Staging primeiro. Todo o encadeamento foi validado num ambiente de teste, cópia da produção, nunca direto no ar.
- Upgrade faseado. Vários saltos por versões intermediárias, com a versão de PHP certa em cada um.
- Backup a cada fase. Se algo desse errado numa etapa, o rollback era daquela etapa, não do projeto inteiro.
- Migração do conteúdo interativo para o componente atual, como passo dedicado.
- Cron religado e rodando de minuto em minuto.
O resultado
Plataforma atual e com suporte, PHP moderno, cron funcionando, e o que mais importava para o cliente: dados 100% preservados (cursos, notas, inscrições). O projeto correu por fases semanais, ao longo de cerca de um mês. Nada de "reinstalar e recomeçar do zero", que é o atalho que faz uma instituição perder anos de histórico.
A lição do caso: um Moodle antigo não é um beco sem saída, mas também não se resolve com um clique. É projeto: sequência suportada, PHP por etapa, plugins legados e validação em staging. Sobre o custo desse tipo de trabalho, veja quanto custa uma consultoria de Moodle; sobre o dia a dia depois, o que mantém o Moodle seguro passa por estar atualizado.
Leia também: Versões do Moodle: datas de suporte e qual usar em 2026.
Perguntas frequentes
Posso atualizar direto de um Moodle 3.x para a versão mais nova?
Não. O Moodle só suporta upgrade a partir de certas versões de origem; um salto direto de uma linha muito antiga (3.x) para a atual não é suportado e costuma quebrar. O caminho correto é o upgrade encadeado: subir por versões intermediárias, uma de cada vez, respeitando a versão de PHP exigida por cada etapa.
Vou perder cursos, notas e inscrições no upgrade?
Não, quando o processo é feito por fases e com backup a cada etapa. O upgrade do Moodle preserva os dados; o risco vem de pular versões, usar o PHP errado ou não validar em ambiente de teste antes de tocar na produção.
O que acontece com o conteúdo interativo (H5P) antigo?
Componentes antigos de conteúdo interativo foram descontinuados e substituídos pelo componente atual do Moodle. Na migração, esse conteúdo precisa ser convertido para o novo componente para continuar funcionando: é uma etapa à parte dentro do projeto de upgrade.


