// serviço · upgrade moodle
Upgrade Moodle 3.x → 5.2 com garantia
Migração encadeada para a versão 5.2 LTS sem perder notas, progresso, certificados ou conteúdo H5P. Cláusula contratual de 95% de integridade, 30 dias de suporte pós go-live, staging clone obrigatório antes de tocar a produção.
// para quem é
Para quem é
Você tem Moodle legado parado em alguma das situações abaixo, e adiar virou o problema:
Moodle 3.9 ou 4.x antigo
EOL desde 2023. Sem patches de segurança, plugins descontinuados, PHP 7.x deprecated em produção.
Conteúdo H5P legado
Plugin mod_hvp abandonado pela comunidade. Moodle 5.x só aceita mod_h5pactivity.
LGPD / GDPR / CNPD
Auditoria interna ou de cliente exigiu plataforma com suporte ativo do vendor e patches de segurança correntes.
// escopo
O que entregamos
Não é "atualizar Moodle". É um processo técnico encadeado com pontos de validação em cada etapa.
- Análise prévia (auditoria pré-upgrade) — mapeamento de plugins, customizações, integrações, volume de dados e riscos antes de gerar o orçamento.
- Staging clone idêntico à produção — todo upgrade roda primeiro em ambiente staging com cópia 1:1 do banco e dataroot.
- Upgrade encadeado: 3.9 → 4.1 → 4.5 → 5.0 → 5.2 — não pulamos versões. Cada etapa valida integridade do banco antes de prosseguir.
- Migração H5P automática —
mod_hvp→mod_h5pactivitypreservando progresso e notas dos alunos. - Atualização de stack — PHP 8.3/8.4, MySQL/MariaDB compatível, configuração de cache (Redis opcional).
- Tema revisado e adaptado — premium pago (MB2NL, Klass, Lambda, Edumy) ou gratuito (Boost, Moove, Adaptable, próprio). Mantemos a identidade visual atual.
- Teste de carga e validação — usuários de teste, login, acesso a cursos, lançamento de notas, geração de certificados.
- Go-live programado — janela de manutenção comunicada, rollback plan documentado, on-call durante a virada.
- 30 dias de suporte pós go-live — qualquer problema decorrente do upgrade é resolvido sem custo adicional.
// metodologia
Como trabalhamos
Processo de seis etapas, cada uma com sign-off antes da próxima. Sem surpresas.
Auditoria pré-upgrade
Análise técnica do ambiente atual: versão, PHP, plugins, customizações, integrações, banco e dataroot, uso de H5P. Saída: relatório com riscos e plano.
Clone idêntico
Clone em ambiente isolado. Validação de credenciais, conexão, performance baseline. Nenhuma alteração toca produção nesta fase.
Migração encadeada
Migrações sucessivas 3.9 → 4.1 → 4.5 → 5.0 → 5.2. Em cada etapa: purge_caches, validação de integridade, teste de plugins, snapshot.
Validação com cliente
Você recebe acesso ao staging com Moodle 5.2 e dados reais. Valida cursos críticos, fluxos, certificados, integrações. Sign-off escrito antes de produção.
Virada programada
Janela de manutenção comunicada com 7 dias. Backup final, upgrade da produção replicando staging, on-call durante a virada. Rollback plan pronto.
30 dias pós go-live
Qualquer comportamento decorrente do upgrade é tratado sem custo adicional. Após 30 dias, suporte continuado via contrato mensal opcional.
// padrões que atendemos
Tipologias de Moodle legado que vemos
Em quase 10 anos atendendo upgrades, identificamos quatro arquétipos recorrentes. Provavelmente seu cenário cai em um (ou mistura dois) deles.
Escola ou instituto com várias filiais
Matriz + N subdomínios regionais, todos no mesmo Moodle 3.x. Cron parado, plugins de relatórios descontinuados, multi-tenant sem isolamento entre tenants. Cada filial tem seu admin local mas ninguém atualiza.
Empresa com biblioteca H5P presa em 4.x
Departamento de T&D investiu em conteúdos interativos com mod_hvp. Centenas de atividades H5P com progresso real de centenas/milhares de colaboradores. Não podem perder dados. Não tinham plano para a deprecação do mod_hvp.
Município, universidade pública ou órgão
Infraestrutura própria, restrições de licitação, integração SSO obrigatória (LDAP / SAML / Gov.br), compliance LGPD pesada, equipe interna de TI envolvida no projeto. Janela de manutenção restrita a horário não letivo.
Escola com branding pesado no tema
Investiram em identidade visual num tema premium pago (MB2NL, Klass, Lambda, Edumy) ou customizaram um gratuito (Boost, Moove, Adaptable). O tema não é compatível com 5.2 out-of-the-box. Solução: revisar templates Mustache + SCSS adaptando ao Bootstrap 5.
Há também tipologias mistas e híbridas — eventos pontuais com Moodle descartável, plataformas multinacionais com replicação geográfica, integrações com ERPs proprietários. Se seu cenário não cabe em nenhuma das quatro acima, a auditoria pré-upgrade é o lugar para detectar isso.
// investimento
O que define o orçamento
Não trabalhamos com tabela fixa. Cada Moodle legado é um cenário diferente. O orçamento sai depois da auditoria prévia, com base nestas variáveis:
mod_hvp)→ migração específicaA auditoria pré-upgrade é a peça que transforma essas variáveis em um orçamento fechado, com escopo, prazo e cláusulas contratuais.
// faq
Perguntas frequentes
Por que o upgrade precisa ser encadeado e não direto?
O Moodle não suporta upgrades que saltam mais de uma versão LTS. Para ir de 3.9 a 5.2 é obrigatório passar por 4.1 → 4.5 → 5.0 → 5.2, validando integridade do banco e plugins em cada etapa. Tentar saltar etapas quebra tabelas e corrompe dados de progresso.
Quanto tempo leva um upgrade Moodle 3.9 para 5.2?
Depende do volume de dados, número de plugins de terceiros e uso de mod_hvp (H5P legado). Plataformas pequenas (até 5 GB, sem customizações): 1 a 2 semanas. Médias com H5P e tema custom: 3 a 4 semanas. Multi-tenant com 8+ subdomínios: 6 a 8 semanas.
O upgrade preserva 100% dos dados, notas e atividades dos alunos?
Garantimos 95% de integridade na cláusula contratual. Os 5% restantes cobrem casos onde plugins descontinuados de versões antigas não têm equivalente em 5.2 (ex: mod_hvp legado, certificate v1, alguns blocos descontinuados). Para esses casos apresentamos plano de migração de conteúdo antes do upgrade. Afirmar "100%" é mentir — preferimos transparência contratual.
Preciso atualizar o PHP antes do upgrade?
Sim. Moodle 5.2 LTS exige PHP 8.3 (mínimo) ou 8.4 (recomendado). Servidores ainda em PHP 7.x ou 8.0 precisam de upgrade de stack antes da migração. Isso faz parte do nosso escopo padrão e é validado na auditoria prévia.
O que acontece com plugins customizados ou desenvolvidos in-house?
Cada plugin de terceiros é testado individualmente em staging contra Moodle 5.2. Plugins com versão compatível: atualizados. Plugins descontinuados: identificados e propostos substitutos. Plugins críticos sem substituto: avaliamos fork ou desenvolvimento de equivalente — isso é orçamentado separadamente do upgrade base.
E se algo der errado no go-live?
Antes do go-live mantemos: backup completo do banco e dataroot da produção (snapshot timestamped), staging idêntico funcionando como fallback, rollback plan documentado e on-call durante a janela. Em ~9 anos de upgrades, nunca usamos o rollback — mas ele está pronto.
Não tem certeza se o upgrade é seu caso?
Faça o diagnóstico técnico de upgrade em 2 minutos. 9 perguntas sobre versão, PHP, cron, plugins e tema. Score 0-100 + plano de ação adaptado ao seu grau de risco.
Fazer diagnóstico de upgradePronto para sair do Moodle legado?
Reserve 30 minutos com Alejandro para uma auditoria preliminar gratuita do seu ambiente.
Reservar auditoria de 30 minOu direto por email: ceo@programamoodle.com