Quando os arquivos MBZ deixaram de ser uma estratégia de migração

Uma estratégia segura que começou a ficar pequena

Migrar cursos por arquivos MBZ era uma escolha fácil de explicar, permitia levar uma disciplina por vez, testar o resultado e manter o ambiente antigo disponível, além de evitar uma mudança direta de banco entre versões muito distantes do Software Moodle™, porém a estratégia começou a mostrar limites quando a quantidade de cursos cresceu, os pacotes passaram a ocupar muitos gigabytes e surgiram dependências que não pertenciam claramente a uma única disciplina, então o que parecia um processo simples de backup e restauração virou uma sequência longa de esperas, falhas tardias e verificações manuais que não caberia na janela prevista para a mudança.

Antes de automatizar, fizemos um inventário que classificava cada curso por tamanho, formato, quantidade de atividades, plugins usados, arquivos, usuários, banco de questões, métodos de inscrição e integrações externas, porque processar tudo na ordem alfabética deixaria os maiores problemas para aparecerem por acaso, enquanto a classificação permitia criar grupos semelhantes, testar primeiro casos representativos e identificar cursos que exigiam uma decisão antes da migração, como atividades de um plugin sem versão compatível ou links para um serviço que também seria substituído.

Os primeiros backups confirmaram que tamanho não explicava sozinho a duração, pois um curso com muitos questionários e questões compartilhadas podia levar mais tempo do que outro com arquivos maiores, algumas tarefas pareciam paradas enquanto compactavam ou reconstruíam estruturas e um pacote gerado com sucesso ainda podia falhar somente perto do final da restauração, então passamos a registrar as etapas internas, o tempo de cada fase, o último avanço e as mensagens relevantes, dando à equipe condições de distinguir um processamento lento de uma interrupção real.

Uma fila que sabia continuar

A automação foi construída ao redor de uma fila por curso, com situação, tentativa, horários, origem, destino, tamanho esperado e local dos registros, sem esconder os comandos executados pelo Software Moodle™, pois quando um pacote apresentava erro precisávamos reproduzir exatamente aquela unidade de trabalho e não reiniciar centenas de cursos que já estavam corretos, então cada item podia ser retomado, refeito ou separado para análise, enquanto o restante avançava dentro de limites definidos para não sobrecarregar banco, processador e armazenamento.

Também separamos geração, transporte, restauração e validação, porque executar tudo como uma única ação tornava difícil perceber onde o tempo estava sendo gasto e aumentava o custo de qualquer repetição, assim um backup concluído podia aguardar a transferência sem prender o ambiente de origem, arquivos já conferidos não eram copiados novamente e uma falha de restauração voltava apenas à etapa necessária, com hashes para garantir que o pacote analisado no destino era o mesmo produzido na origem.

O banco de questões exigiu uma revisão mais profunda, já que categorias, contextos e questões compartilhadas podiam atravessar cursos de uma forma que a contagem simples de atividades não mostrava, por isso criamos verificações que comparavam categorias, quantidade de questões, referências usadas pelos questionários e amostras de tentativas, além de definir uma ordem para cursos relacionados quando isso reduzia conflitos, trabalho que evitou a falsa sensação de sucesso de abrir a página inicial do curso e encontrar todas as seções enquanto uma avaliação importante permanecia incompleta.

O ensaio que revelou o trabalho escondido

A migração completa foi executada primeiro em homologação com uma cópia representativa dos dados, medindo o tempo de backup, transferência, restauração, tarefas posteriores e validação, ao mesmo tempo em que registrávamos toda intervenção manual, como substituir uma atividade, ajustar uma permissão ou corrigir um conteúdo antigo, porque cada minuto gasto fora da automação precisava entrar na previsão do corte e alguns ajustes aparentemente rápidos se repetiriam em dezenas de cursos.

Depois do ensaio, os cursos que continuaram recebendo alterações foram identificados para um novo processamento próximo à data definitiva, enquanto aqueles encerrados e já validados não precisaram ocupar a janela novamente, o que diminuiu o volume durante a indisponibilidade e permitiu concentrar a equipe nos dados realmente modificados, mas essa decisão só foi segura porque cada pacote tinha data, versão, origem e resultado de validação, impedindo que uma cópia antiga fosse confundida com a versão mais recente.

Um dos comportamentos mais desconfortáveis acontecia quando a combinação de questionários, arquivos e tarefas pendentes mantinha o processo muito tempo sem produzir uma mensagem nova, dando a impressão de travamento, então adicionamos sinais de progresso que não dependiam apenas da saída final, acompanhando processos, tamanho de temporários, atualização de registros e duração esperada para aquele perfil de curso, com limites que avisavam quando o comportamento saía do intervalo observado em homologação e precisava de investigação.

Validar o que o estudante realmente encontraria

A comparação final foi além do número de seções e atividades, incluindo arquivos, matrículas, grupos, notas, conclusões, categorias de questões e amostras de tentativas, além de navegação real nos cursos de maior risco, porque diferenças de versão podiam transformar configurações, permissões e formatos sem produzir um erro durante a restauração, então os resultados automáticos apontavam divergências e a equipe pedagógica validava aquilo que dependia de contexto, como aparência de uma atividade, regra de conclusão ou disponibilidade condicionada.

Mantivemos o ambiente anterior disponível durante a homologação e o período de conferência, com regras claras para evitar que alunos continuassem produzindo dados nos dois lados, e preparamos retorno por conjunto de cursos em vez de imaginar uma reversão única para toda a plataforma, pois a mesma granularidade que motivou o uso dos MBZ também poderia proteger a implantação caso uma área específica apresentasse um problema depois da abertura.

Os arquivos MBZ continuaram sendo parte da migração, mas deixaram de ser a estratégia inteira, passaram a funcionar dentro de um processo com inventário, classificação, fila, retomada, ensaio e validação, mudança importante porque a ferramenta que transporta o curso não decide sozinha o que fazer com dependências, quanto tempo reservar, quais diferenças aceitar ou como provar que o aluno encontrou no novo ambiente aquilo que existia no anterior.