Migração de Moodle: riscos, custos e como decidir

Migração de Moodle: o problema começa antes de mover o primeiro arquivo

Quando alguém me procura depois de uma migração de Moodle que deu errado, a história é quase sempre a mesma. A migração "funcionou": os arquivos foram para o novo servidor, o site abriu, a home apareceu. E então, dias depois, começaram a pipocar os problemas — um curso que não abre, notas que sumiram de um relatório, um login externo que parou, um plugin que joga erro branco na tela, um conteúdo interativo que virou uma caixa vazia.

O ponto que quase ninguém percebe é este: nenhum desses problemas nasceu na hora de migrar. Eles já estavam decididos antes — no momento em que se escolheu (ou se deixou de escolher) para qual versão ir, quais plugins levar, se o backup seria testado, se a mudança de servidor viria junto com a mudança de versão. A migração só revelou o que já estava combinado.

É por isso que migração de Moodle não é, na essência, uma tarefa técnica de mover arquivos. É uma decisão de risco. E o custo de errar essa decisão não se mede em horas de trabalho — mede-se em plataforma fora do ar na segunda de manhã, em alunos travados no meio de uma avaliação, em dados que voltam incompletos, em uma equipe de TI acordada de madrugada tentando entender o que aconteceu com um sistema que "só ia mudar de lugar".

Em quase dez anos operando Moodle em produção — eu toco o código dos projetos que a ProgramaMoodle entrega —, aprendi que a diferença entre uma migração que ninguém percebe que aconteceu e um pesadelo de fim de semana quase nunca está na destreza de quem executa. Está na qualidade das decisões que vieram antes. Este artigo é sobre essas decisões: o que está realmente em jogo, onde moram os riscos, e como escolher com base em fatos em vez de chute.

Por que uma migração entra na pauta — e por que quase sempre entra tarde

Ninguém migra um Moodle por diversão. A migração entra na pauta empurrada por um gatilho, e vale a pena reconhecer quais são, porque o gatilho determina o nível de pressão — e a pressão é inimiga da boa decisão. O gatilho mais comum é a hospedagem: um contrato que encerra, um provedor que descontinua um plano, uma conta que ficou pequena demais para o volume de alunos. O segundo é a performance: a plataforma que trava na semana de provas e que a equipe, sem diagnóstico, conclui que "precisa de um servidor melhor" — quando muitas vezes o problema é outro, como explico no artigo sobre Moodle lento.

O terceiro gatilho, e o mais perigoso quando é ignorado, é a versão sem suporte. Um Moodle que ficou parado numa versão antiga não é apenas "desatualizado" — é uma plataforma que roda sobre um software que já não recebe correções de segurança, guardando dados de centenas de pessoas. Isso conecta a migração diretamente à segurança da instalação: adiar a atualização não congela o risco, ele o acumula. O quarto gatilho é a conformidade — exigências de proteção de dados que tornam insustentável manter uma instalação abandonada.

O padrão que se repete é este: a migração quase sempre entra na pauta tarde, quando o gatilho já virou urgência — o contrato já venceu, a plataforma já caiu, a auditoria já apontou. E migração sob urgência é migração sob risco elevado, porque o tempo que deveria ser gasto no diagnóstico é gasto apagando incêndio. A melhor migração é a que se planeja quando ainda não é urgente. A segunda melhor é a que, mesmo sob pressão, ainda separa um momento honesto para mapear o risco antes de agir.

As três coisas que se movem — e por que cada uma quebra de um jeito diferente

Um Moodle não é um arquivo. É a soma de três componentes distintos, e a fonte mais comum de perda de dados numa migração é tratá-los como se fossem um só, ou movê-los fora de sincronia. Entender o que são — sem entrar no como fazer — já elimina metade dos desastres.

O primeiro componente é o código da aplicação: os arquivos do Moodle propriamente ditos, mais os plugins e o tema instalados. É a parte mais visível e, ironicamente, a menos crítica em termos de dados — porque o código, em teoria, pode ser reinstalado. O que não pode ser reinstalado é o que ele carrega junto: os plugins de terceiros e as customizações que só existem naquela pasta, e que raramente têm um registro de onde vieram e em que versão estavam.

O segundo componente é o diretório de dados — o famoso moodledata. É onde vivem os arquivos enviados pelos usuários: os trabalhos entregues, os PDFs dos cursos, as imagens, os backups internos, os arquivos de sessão. Esse diretório costuma ser o maior de todos em volume e, ao mesmo tempo, o mais esquecido, porque fica fora da pasta pública e ninguém "vê" ele no dia a dia. Uma migração que move o código e o banco de dados mas leva um moodledata incompleto entrega um Moodle que abre lindamente e, ao clicar em qualquer arquivo, mostra um erro de "arquivo não encontrado". Os dados não foram corrompidos — foram deixados para trás.

O terceiro componente é o banco de dados. É o cérebro: usuários, cursos, notas, tentativas de questionário, progresso, configurações, permissões, logs. Tudo o que dá sentido aos arquivos e ao código está aqui. O banco é o componente onde um erro é mais caro e mais silencioso, porque uma exportação incompleta, uma diferença de codificação de caracteres ou uma versão incompatível de banco pode passar despercebida na abertura do site e só aparecer semanas depois, quando alguém procura uma nota específica que não está mais lá.

O risco real não está em nenhum dos três isoladamente — está no acoplamento invisível entre eles. O banco de dados aponta para arquivos que precisam existir no moodledata na estrutura exata que ele espera. O código precisa estar na versão que aquele banco entende. Mover os três em momentos diferentes, ou de fontes diferentes, é a receita clássica para um ambiente que fica "quase certo" — e "quase certo", num sistema que guarda o histórico acadêmico de centenas de pessoas, é o mesmo que errado.

O ambiente de destino também decide o resultado

Há uma suposição silenciosa em quase toda migração que dá errado: a de que o destino é terreno neutro, um lugar vazio que só espera receber os arquivos. Não é. Para onde você migra importa tanto quanto o que você migra, e o ambiente de destino tem exigências próprias que, se não forem atendidas, produzem uma plataforma que parece funcionar e não funciona.

A primeira exigência são os recursos do servidor. Cada versão do Moodle pede uma versão mínima de PHP, uma versão de banco de dados compatível e extensões específicas instaladas. Um destino que não atende a esses requisitos não roda o Moodle — ou pior, roda de forma instável, com erros que aparecem só sob carga. Migrar para uma hospedagem compartilhada que "promete" recursos que não entrega de verdade é trocar um problema conhecido por um problema novo e mais difícil de diagnosticar.

A segunda, e a mais esquecida de todas, é o cron — as tarefas agendadas que o Moodle roda por baixo dos panos. É o cron que envia notificações, processa backups internos, atualiza relatórios, fecha questionários no horário, entrega badges, dispara mensagens. Quando o cron não é configurado corretamente no destino, nada explode com um erro claro: a plataforma simplesmente fica "meio quebrada" de um jeito difícil de nomear — e-mails que não chegam, relatórios que não atualizam, prazos que não fecham. É um dos sintomas mais comuns de uma migração incompleta, e um dos mais frustrantes justamente porque não aparece como erro, aparece como coisas que "deveriam acontecer e não acontecem".

A terceira é a configuração de ambiente: endereços, permissões de arquivos, certificados, limites de upload, fuso horário. Detalhes que, individualmente, parecem pequenos, mas que somados definem se a plataforma nova se comporta como a antiga ou como uma versão sutilmente diferente dela. É por isso que validar o destino faz parte da migração, e não é um passo opcional feito depois.

Migrar de servidor não é a mesma coisa que atualizar de versão

Existe uma confusão que custa muito caro, e vale a pena desfazê-la com clareza: migrar de servidor e atualizar de versão são duas operações diferentes.

Migrar de servidor é mover a mesma instalação do Moodle — mesma versão, mesmos plugins, mesmo tema — de uma máquina ou hospedagem para outra. O objetivo é que, no fim, tudo funcione exatamente como funcionava, só que em outro lugar. Atualizar de versão é passar o Moodle de uma versão para outra, mais nova, o que envolve o Moodle reescrever partes do próprio banco de dados para se adequar ao novo formato. São propósitos distintos, com superfícies de risco distintas.

O problema aparece quando as duas são embrulhadas numa coisa só — "já que a gente vai mudar de servidor, aproveita e atualiza tudo". É uma tentação compreensível e, quase sempre, um erro de método. Quando algo dá errado num pacote que mistura mudança de servidor e mudança de versão ao mesmo tempo, você fica sem saber qual das duas mudanças causou o problema. O ambiente novo tem, ao mesmo tempo, um hardware diferente, uma configuração diferente, uma versão diferente e um comportamento diferente — e nenhuma forma limpa de isolar a causa. O risco não soma; ele se multiplica.

A forma profissional de lidar com isso é separar as operações em etapas conscientes: primeiro estabilizar a migração pura (a mesma versão rodando bem no novo ambiente), validar, e só então tratar a atualização de versão como um projeto próprio, com seu próprio plano e seu próprio ponto de retorno. Não é mais lento por burocracia — é mais rápido no total, porque cada etapa é reversível e diagnosticável. Escrevi sobre os padrões específicos desse encadeamento de versões no artigo sobre upgrade de Moodle de versões legadas.

O mapa de risco: as seis minas de uma migração de Moodle

Se há uma coisa que uma década de projetos ensina, é que as migrações falham nos mesmos lugares, projeto após projeto. Não são surpresas — são minas conhecidas. O trabalho de um especialista é mapeá-las antes, não desarmá-las no susto. Aqui está o mapa. Repare que quase nenhuma dessas minas é "o Moodle" — são as bordas ao redor dele.

Nenhuma dessas seis minas é obscura ou rara. Todas são conhecidas, todas são mapeáveis antes de a migração começar. O que separa um projeto tranquilo de um desastre não é evitar territórios desconhecidos — é levar a sério o mapa do território conhecido. É exatamente por isso que uma migração séria começa com um levantamento, não com um rsync.

A decisão de versão: LTS ou a última? (e por que outubro de 2026 muda a conta)

Se a migração vai acompanhar uma atualização de versão, há uma decisão estratégica que muita gente pula e que deveria vir bem no começo: para qual versão ir? A resposta reflexa — "a mais nova, óbvio" — nem sempre é a certa, e entender por quê é o tipo de decisão que separa quem enxerga o Moodle como plataforma de quem o enxerga como um pacote de software qualquer.

O Moodle libera uma versão principal a cada seis meses, em abril e em outubro. Nem toda versão é igual: existem as versões de suporte padrão e existem as versões LTS (do inglês Long-Term Support, suporte de longo prazo). A diferença que importa para quem toma a decisão é o horizonte de manutenção: uma versão LTS recebe correções de segurança por um período bem mais longo, o que costuma ser decisivo para instituições que priorizam estabilidade e não querem repensar a versão a cada poucos meses.

E aqui entra o fator tempo, que torna esta decisão especialmente sensível agora. A versão mais recente do Moodle é a 5.2, lançada em abril de 2026, que exige PHP 8.3 ou superior no servidor. Mas a 5.2 é uma versão de suporte padrão — não é LTS. A LTS atualmente em vigor é a linha 4.5, e a próxima LTS, a 5.3, está prevista para outubro de 2026. Ou seja: quem decide a versão de destino de uma migração neste segundo semestre de 2026 está tomando essa decisão a poucas semanas de uma nova LTS aparecer.

Isso não significa que exista uma resposta única e certa — significa que existe uma decisão a ser tomada com consciência, e não por reflexo. Migrar para a versão mais recente entrega os recursos mais novos, mas coloca você num ciclo de atualização mais curto. Mirar na LTS entrega um horizonte de tranquilidade maior, ao custo de, às vezes, esperar ou passar por um degrau a mais. A escolha certa depende do seu perfil: quanto de estabilidade você precisa, com que frequência sua equipe consegue manter a plataforma, qual o custo de parar para atualizar de novo daqui a alguns meses.

O backup que ninguém testou

Vale insistir na mina número seis, porque ela é a que mais transforma uma migração em manchete interna. A migração que perde dados quase nunca é falta de competência de quem executa. É um backup em que todo mundo confiou e ninguém testou.

O mecanismo é sempre o mesmo. A rotina de backup existe há anos. Ela roda, gera arquivos, ocupa espaço, aparece como "concluída". Todos os sinais dizem que está tudo bem. Só que "gerar um arquivo de backup" e "conseguir voltar a plataforma inteira a partir dele" são duas coisas diferentes — e a segunda nunca foi verificada. O arquivo pode estar truncado, pode estar sem o moodledata, pode estar num formato que o destino não lê, pode estar corrompido de forma que só se percebe ao tentar restaurar. Nada disso aparece no painel verde.

A boa notícia é que existe um teste de dez minutos que revela tudo: peça hoje para restaurarem o último backup num ambiente de teste. Não conferir se ele "rodou" — restaurar de verdade e abrir. Se a resposta que você receber for algum tipo de "a gente nunca fez isso, mas deve funcionar", você acabou de encontrar o problema antes que ele te encontrasse. Migrar sem perder nada não é sorte: é validar a integridade antes de tocar em qualquer coisa. Detalhei essa dinâmica no artigo sobre o backup de Moodle que ninguém testou — e é, de longe, a coisa mais barata e mais valiosa que você pode fazer antes de qualquer migração.

O que define o investimento numa migração de Moodle

A pergunta que sempre chega é "quanto custa migrar?". E a resposta honesta é que não existe preço de tabela para migração de Moodle — quem oferece um número fechado sem olhar o ambiente está chutando, e o chute quase sempre vira surpresa no meio do projeto. O que existe é um conjunto de variáveis que define o esforço, e entendê-las é o que permite a você comparar propostas com critério, em vez de comparar só números.

A versão de origem é a primeira variável: quanto mais antiga, mais longo e mais arriscado o caminho até a versão de destino, porque mais degraus de atualização e mais incompatibilidades acumuladas existem no meio. O número de instâncias ou subdomínios é a segunda: migrar um Moodle é um projeto; migrar oito instalações que compartilham infraestrutura é outro, com uma superfície de risco muito maior.

A terceira variável são os plugins e customizações: cada plugin de terceiro e cada personalização que tocou o comportamento padrão é um item que precisa ser avaliado, testado e, às vezes, substituído. A quarta são as integrações externas — SSO, pagamentos, sistemas do cliente —, que multiplicam os pontos de verificação. A quinta é o volume de dados: o tamanho do moodledata e do banco não muda a complexidade lógica, mas muda o tempo de janela e o custo de infraestrutura da operação. E a sexta é o prazo: uma migração planejada com folga é um projeto controlado; uma migração para ontem, com a plataforma em produção e alunos ativos, é um projeto de risco elevado que cobra um preço proporcional.

Há ainda uma variável que quase nunca aparece nas propostas e que, na prática, é a que mais explica surpresas: a distância entre o Moodle que se imagina ter e o Moodle que se tem de fato. Instalações reais acumulam camadas — um plugin instalado anos atrás e esquecido, uma customização feita às pressas, uma integração que ninguém documentou, um moodledata que cresceu muito além do previsto. Essa distância entre o estado documentado e o estado real é invisível até que alguém a meça — e é justamente por isso que o diagnóstico não é uma formalidade burocrática: é o que transforma variáveis desconhecidas em variáveis conhecidas, antes que elas virem custo no meio do projeto.

É por isso que, na ProgramaMoodle, uma migração nunca começa por um orçamento cego. Começa por um levantamento que transforma essas variáveis em um escopo fechado, com prazo e cláusula contratual, antes de qualquer compromisso. Você sabe exatamente o que será feito e quanto custa — sem "tinha mais coisa do que parecia" no meio do caminho.

Como decidir sem chutar

Repare no fio que atravessa tudo até aqui: cada risco de uma migração é conhecido, mapeável e — o mais importante — diagnosticável antes de começar. A versão de origem se lê. Os plugins se listam. As integrações se inventariam. O backup se testa. O tema se avalia. Nada disso é adivinhação. O que transforma uma migração de aposta em projeto é justamente essa etapa de diagnóstico, feita com honestidade, antes de a primeira decisão irreversível ser tomada.

E há um princípio que guia como fazemos isso, que vale a pena deixar explícito: toda migração tem que deixar você mais livre, não mais refém. Migrar sem alterar o núcleo do Moodle, sem criar dependência de um fornecedor específico, sem prender a plataforma a customizações que ninguém mais entende — para que, no futuro, você possa atualizar, trocar de hospedagem ou trocar de parceiro sem precisar de arqueologia. Contratar bem uma migração é contratar alguém que te devolve o controle da própria plataforma, não que te amarra a ele.

Se você tem um Moodle diante de uma migração — de servidor, de versão, ou das duas — e não tem certeza do que exatamente está em jogo, o ponto de partida certo não é pedir um orçamento. É fazer um diagnóstico. Nosso diagnóstico técnico gratuito leva dois minutos, não exige cadastro, e devolve um retrato de criticidade do seu ambiente. A partir dele, a conversa deixa de ser sobre "quanto custa mover isso" e passa a ser sobre "qual é o caminho certo, com base no que o seu Moodle realmente é". E a gente conduz esse caminho por você, do levantamento à virada de chave.

Perguntas frequentes sobre migração de Moodle