Migrar Moodle de Servidor Sem Perder Dados nem Parar o AVA

Migrar Moodle de servidor parece a tarefa mais simples do mundo até a primeira tentativa: copiar três coisas, apontar o DNS e pronto. Na prática, é exatamente aí que se perdem submissões de alunos, notas de um semestre inteiro e uma manhã de aula. Trabalho com Moodle desde 2008 e este é o roteiro que uso para tirar um AVA de um servidor e colocá-lo em outro sem perder dado e sem derrubar a operação.

TL;DR — o essencial

• Uma migração move três peças independentes: o código do Moodle, a pasta moodledata e o banco de dados. Esquecer uma delas é o erro nº 1.
• A janela de indisponibilidade não precisa ser de horas. Com cópia incremental e TTL de DNS reduzido, o corte real fica em minutos.
• Não migre e atualize a versão no mesmo movimento. A documentação oficial é explícita: uma variável por vez, ou você não saberá o que quebrou.
• Em setembro de 2026 o calendário pesa na decisão: o Moodle 5.0 perde até o suporte de segurança em 5 de outubro de 2026, e o 5.3 LTS chega no mesmo dia, com suporte de segurança até 1º de outubro de 2029.
• Migrar Moodle de servidor sem ensaio prévio é aposta. O ensaio custa algumas horas; o rollback improvisado custa o semestre.

O que muda de fato ao migrar Moodle de servidor

O Moodle não é um site. É um sistema com estado espalhado em três lugares que precisam chegar íntegros e coerentes entre si no destino. Quem vai migrar Moodle de servidor precisa levar as três peças na mesma foto do tempo — entender isso já evita metade dos acidentes.

1. O código

A pasta da aplicação: core do Moodle, plugins, tema e customizações. É a parte mais fácil de mover e a mais fácil de subestimar — plugins de terceiros instalados há anos costumam não ter registro em lugar nenhum. Gere a lista real em Administração do site → Plugins → Visão geral dos plugins e guarde-a fora do servidor.

2. A pasta moodledata

É onde vivem os arquivos enviados por professores e alunos, os backups de curso e os caches. Ela fica fora da pasta pública do site e o caminho dela está no $CFG->dataroot do config.php. É a peça mais pesada: num AVA com alguns anos de operação, costuma ser dezenas de vezes maior que o código.

A documentação oficial recomenda não copiar os subdiretórios cache, localcache, sessions, temp e trashdir. São efêmeros, o Moodle os recria, e ignorá-los corta horas de transferência.

3. O banco de dados

Todo o resto: usuários, matrículas, notas, logs, configurações, conteúdo dos cursos. É a peça que exige congelamento — se alguém enviar uma tarefa depois do dump, aquele arquivo estará no moodledata novo e o registro dele não estará no banco novo. Resultado: arquivo órfão, entrega invisível na correção.

Quando migrar Moodle de servidor — e quando adiar

Migrar por migrar não resolve nada. Os motivos que sustentam a decisão de migrar Moodle de servidor são quatro:

• O servidor não aguenta o pico. O gargalo de EAD é sazonal: semana de prova e primeira semana do semestre concentram acesso. Se o sistema cai justamente aí, o problema é dimensionamento.
• A pilha ficou velha demais para a próxima versão. O Moodle 5.0 já exige PHP 8.2 no mínimo, a extensão sodium e max_input_vars maior ou igual a 5000. Servidor preso em PHP 7.4 não recebe versão nova — ponto.
• Ninguém cuida da infraestrutura. Servidor sem responsável definido não tem backup testado, nem atualização de segurança, nem monitoramento. Não é risco técnico, é risco institucional.
• O custo não fecha. VPS grande e ocioso 10 meses por ano, ou plano de nuvem gerenciada que não permite instalar o plugin de que a instituição depende.

E quando não migrar? Três situações em que a resposta certa é esperar:

1. No meio do semestre, com atividades abertas e prazos correndo. A janela boa é recesso, virada de semestre ou madrugada de fim de semana.
2. Junto com um upgrade de versão. A documentação oficial de migração pede uma mudança de cada vez: se algo quebrar, você precisa saber o que causou. Migre, estabilize, e só depois atualize.
3. Sem backup restaurado com sucesso pelo menos uma vez. Backup que nunca foi testado é hipótese, não garantia — o mesmo raciocínio que já detalhei em o caso da exclusão de conteúdos no Moodle da UFOP.

Para qual versão migrar em setembro de 2026

Esta é a decisão que mais muda o resultado, porque ela define os requisitos do destino. Quem vai migrar Moodle de servidor agora precisa abrir o calendário oficial antes de escolher a versão:

Versão	Lançamento	Fim do suporte geral	Fim do suporte de segurança	LTS
4.5	07/10/2024	06/10/2025	04/10/2027	Sim
5.0	14/04/2025	20/04/2026	05/10/2026	Não
5.1	06/10/2025	05/10/2026	19/04/2027	Não
5.2	20/04/2026	19/04/2027	04/10/2027	Não
5.3	05/10/2026	04/10/2027	01/10/2029	Sim

Fonte: tabela de releases do Moodle Developer Resources.

Duas leituras práticas saem daí. A primeira: quem ainda roda 5.0 tem prazo curto — em 5 de outubro de 2026 nem correção de segurança sai mais. A segunda: o 5.3 é a próxima LTS, com suporte de segurança até outubro de 2029. Se a migração é agora, o destino inteligente é um servidor que já atenda aos requisitos do 5.3, mesmo que você suba o 5.1 ou o 5.2 hoje e faça o upgrade depois, em outra janela.

E os requisitos subiram de verdade:

Requisito	Moodle 5.0	Moodle 5.3 (LTS)
PHP mínimo	8.2 (8.3 e 8.4 suportados)	8.3 (8.4 suportado)
MariaDB	10.11	10.11
MySQL	8.4	8.4
PostgreSQL	14	16
SQL Server	—	2019
Oracle	Não suportado	Não suportado

O corte do Oracle a partir do 5.0 e o salto do PostgreSQL para a versão 16 no 5.3 são os detalhes que costumam derrubar planos de migração feitos "no olho". Confira também o comprimento do prefixo de tabelas: o limite passou a ser 10 caracteres. Já escrevi sobre esse tipo de armadilha ao analisar as versões e o ciclo de LTS de um AVA institucional grande.

O passo a passo que reduz o risco a quase zero

Pré-voo (dias antes)

Antes de migrar Moodle de servidor, levante a versão exata do Moodle, a versão de PHP e do banco, a lista de plugins, o tamanho do moodledata, o tamanho do dump do banco e quem são os integradores externos (SSO, matrícula automática, gateway de pagamento, aplicativo). Provisione o destino já com a pilha certa e teste uma instalação limpa do Moodle nele: se a instalação limpa falha, a migração falharia também — só que mais tarde e com dados dentro.

Ensaio (a etapa que quase ninguém faz)

Ensaie migrar Moodle de servidor uma vez inteira, sem cutover, com o site novo respondendo num endereço temporário e em modo de manutenção. É no ensaio que aparecem o plugin incompatível, a permissão errada e o cron que não roda. Cronometre cada etapa: esse número vira a janela real que você vai anunciar à instituição.

Execução

Chegou o dia. Esta é a ordem que sigo para migrar Moodle de servidor em produção — cada item da lista existe porque um dia ele faltou em algum lugar.

1. Ative o modo de manutenção no site antigo. Sem isso não existe consistência entre banco e arquivos.
2. Gere o dump do banco com a ferramenta nativa (mysqldump, pg_dump) e confira o tamanho do arquivo — dump truncado é silencioso.
3. Copie o moodledata com rsync, pulando cache, localcache, sessions, temp e trashdir.
4. Copie o código com os plugins e o tema.
5. Crie o banco vazio no destino com a collation correta (normalmente utf8mb4_unicode_ci) e restaure o dump.
6. Ajuste o config.php: $CFG->wwwroot, $CFG->dataroot e as credenciais do banco.
7. Corrija dono e permissões do código e do moodledata — o servidor web precisa de leitura e escrita no moodledata.
8. Rode o cron manualmente uma vez e acompanhe a saída; depois agende-o.
9. Teste com o site ainda em manutenção: login de admin, um curso com atividade, upload, envio de e-mail, relatório de notas.
10. Faça o cutover de DNS, saia do modo de manutenção e monitore os logs por 48 horas.

O roteiro completo está na documentação oficial de migração do Moodle — vale ler antes, não durante.

Como derrubar a janela de indisponibilidade de horas para minutos

A parte demorada de migrar Moodle de servidor é copiar arquivo, e arquivo velho não muda. Use isso a favor.

Cópia em duas passadas. Dias antes, rode um rsync com o site no ar — ele leva o volume inteiro sem pressa. No dia, com o site em manutenção, rode o mesmo rsync de novo: ele copia só o delta, e o que levava horas leva minutos.

TTL de DNS reduzido. Baixe o TTL do registro para 300 segundos com 24 a 48 horas de antecedência. Sem isso, parte dos alunos continua caindo no servidor antigo por horas depois do corte — e, pior, enviando arquivos que ficarão órfãos lá.

Servidor antigo em modo de manutenção, não desligado. Quem chegar por cache de DNS vê "em manutenção" em vez de erro, e não grava nada.

Validação com o site novo ainda em manutenção. Se precisar refazer a restauração, ninguém perdeu trabalho.

Na prática, com essa sequência, a janela anunciada costuma ser de 30 a 60 minutos, dos quais boa parte é teste — e não transferência.

Domínio novo: o search and replace que salva (ou destrói) o site

Quem vai migrar Moodle de servidor e trocar de domínio no mesmo movimento tem uma tarefa extra. Se o endereço muda, o conteúdo do banco continua apontando para o antigo: links dentro de rótulos, páginas, questões e recursos. O Moodle traz a ferramenta em /admin/tool/replace/index.php, com versão de linha de comando:

php admin/tool/replace/cli/replace.php --search=//antigo.exemplo.br --replace=//novo.exemplo.br --shorten --non-interactive

Três cuidados que a própria documentação sinaliza — e um quarto que aprendi apanhando:

• Backup do banco antes. A ferramenta reescreve texto em massa e não tem "desfazer".
• Sem barra final e sem esquema fixo. Buscar por //antigo.exemplo.br cobre http e https de uma vez.
• Rode uma vez só, com o site em manutenção. Duas execuções com padrões diferentes viram bagunça difícil de auditar.
• reCAPTCHA e integrações precisam de chave nova. Domínio novo invalida as chaves do Google usadas no cadastro por e-mail; o mesmo vale para callbacks de SSO e de gateway de pagamento, que apontam para a URL antiga.

Sete armadilhas que quebram uma migração de Moodle

As sete já apareceram em ambientes que recebi para arrumar depois de alguém migrar Moodle de servidor às pressas.

1. Copiar o moodledata com o site no ar e sem segunda passada. Tudo que entrou depois da cópia sumiu.
2. Permissões erradas. O site abre, mas nenhum upload funciona. Quase sempre é dono do moodledata diferente do usuário do servidor web.
3. Collation diferente entre origem e destino. Acentuação corrompida em milhares de registros — e a correção depois é cara.
4. Cron não configurado no destino. Sem cron, o Moodle para de notificar, de processar filas e de indexar — sem erro visível, silenciosamente.
5. Plugins ausentes. O Moodle sobe reclamando de tabelas de plugins que não existem mais, e atividades inteiras somem dos cursos.
6. Migrar e atualizar de uma vez. Quando quebra, você tem dois suspeitos e nenhum caminho de volta rápido.
7. Não guardar o servidor antigo por uma semana. Desligar no dia seguinte é apostar que nada foi esquecido.

Quanto custa migrar Moodle de servidor — e quanto custa não migrar

Há três caminhos, com contas bem diferentes.

Nuvem oficial (MoodleCloud). Os planos padrão vão de AUD 230 por ano (50 usuários, 1 GB de armazenamento) a AUD 3.000 por ano (750 usuários, 50 GB), conforme a tabela oficial de planos. É previsível, mas com um limite duro: não se instala plugin nem integração, e domínio próprio só está incluído no plano mais alto. Para instituição que depende de plugin de matrícula, emissor de certificado ou integração com o sistema acadêmico, a conversa acaba aí.

VPS por conta própria. O aluguel é barato; o custo real é a hora de quem administra. Atualização de PHP, certificado, ajuste de banco, backup testado, monitoramento e resposta a incidente na semana de prova — isso é uma função, não uma tarefa.

Hospedagem gerenciada especializada. O servidor vem afinado para Moodle e alguém responde pelo funcionamento dele. É o modelo que oferecemos em hospedagem gerenciada de Moodle, e o que faz sentido para quem tem alunos dependendo do ambiente e não tem sysadmin dedicado.

O custo de não migrar é o mais fácil de subestimar: um AVA fora do suporte de segurança é superfície de ataque conhecida. Com 146.693 sites Moodle registrados no mundo, segundo o painel oficial de estatísticas, falha divulgada é explorada em escala — e não escolhe alvo.

Como a Agathas Web resolve isso

Migrar Moodle de servidor é serviço, não produto de prateleira. O que fazemos, na ordem:

• Diagnóstico do ambiente atual. Versão, plugins, tamanho de moodledata e banco, integrações e o que está fora de suporte. Sai daí a estimativa honesta de janela.
• Provisionamento do destino. Servidor já com a pilha compatível com o Moodle 5.x — PHP 8.2 ou superior com sodium, banco na versão mínima exigida, Redis para cache e sessões, certificado, firewall e cron.
• Ensaio completo antes do dia D. Site novo no ar em endereço temporário, para validar plugins, tema, SSO, envio de e-mail e desempenho antes de qualquer corte.
• Cutover com cópia incremental e TTL baixo, com o servidor antigo preservado em modo de manutenção por uma semana como rollback real.
• Operação depois. Backup diário automatizado com restauração testada, monitoramento, atualização de ponto de versão e suporte técnico em português. É o que está incluso na hospedagem gerenciada de Moodle — a migração inicial entra no processo de contratação, sem cobrança separada para ambientes dentro do porte do plano.

Somos certificados em Moodle, administramos ambientes críticos de EAD desde 2008 e desenvolvemos as integrações quando o plugin pronto não existe — de sincronismo com sistema acadêmico a notificação de aluno pela API oficial do WhatsApp, para avisar prazo e nota sem depender do e-mail que ninguém abre.

Para começar, o caminho é simples: pela página de hospedagem gerenciada de Moodle você solicita o diagnóstico, recebe o levantamento do ambiente atual e uma janela de migração proposta em data que não atropele o calendário letivo.

Conclusão: planeje o corte, não a correria

Migrar Moodle de servidor com segurança é menos sobre comandos e mais sobre sequência: congelar, copiar em duas passadas, validar em manutenção, cortar o DNS com TTL baixo e guardar o servidor antigo como rede de proteção. As três peças — código, moodledata e banco — precisam chegar juntas e coerentes, e o upgrade de versão fica para outro dia.

Se o seu ambiente está preso numa pilha que não aceita o Moodle 5.x, ou se o servidor já deu o que tinha que dar, o próximo passo é levantar o que existe hoje antes de escolher o destino. Peça o diagnóstico pela página de hospedagem gerenciada de Moodle e faça a mudança na janela certa — não no meio da semana de prova.