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.