Moodle UFBA: Versão, LTS e Upgrade do AVA em 2026

O Moodle UFBA voltou ao topo das buscas no Brasil, e o motivo é menos misterioso do que parece: a Universidade Federal da Bahia começou o semestre 2026.2 em 19 de agosto de 2026, e milhares de estudantes e docentes caíram no ambiente virtual no mesmo dia. Por trás do pico de acesso existe uma lição técnica que vale para qualquer instituição que opera Moodle.

TL;DR

• A busca por Moodle UFBA disparou porque o período letivo 2026.2 começou em 19/08/2026 e termina em 19/12/2026, segundo o calendário da SUPAC.
• A UFBA não roda um Moodle: roda vários (ava.ufba.br, www.moodle.ufba.br, devmoodle.ufba.br), com formas de login diferentes e um único e-mail de suporte.
• Em verificação feita em 30/08/2026, www.moodle.ufba.br informava a versão 2022112814.02 — a linha 4.1 LTS, cujo suporte de segurança terminou em 08/12/2025.
• O Moodle 5.3 LTS chega em 05/10/2026 com segurança garantida até 01/10/2029. É para ela que todo plano de upgrade deveria estar mirando.
• Upgrade de LMS não é evento: é rotina de calendário. Quem planeja pelos marcos do semestre migra sem parar aula.

Por que "Moodle UFBA" virou busca em alta agora

Quem digita Moodle UFBA no buscador quase sempre quer uma coisa só: a tela de login do ambiente certo. O gatilho é o calendário. O calendário acadêmico 2026.2 da SUPAC/UFBA fixa o início do período letivo em 19/08/2026 e o encerramento em 19/12/2026, com marcos de 25% em 17/09, 50% em 17/10 e 75% em 18/11. Nas duas semanas seguintes ao início das aulas, o comportamento é sempre o mesmo em qualquer universidade: o aluno procura pelo nome do ambiente, não pela URL.

O volume de buscas por Moodle UFBA acompanha o calendário acadêmico, não a comunicação institucional. Isso importa para quem administra LMS por um motivo prático. O pico de tráfego de um Moodle institucional não é distribuído — ele se concentra em janelas curtas e previsíveis: primeira semana de aula, semana de envio de trabalhos e semana de provas. Dimensionar infraestrutura pela média mensal é o erro mais comum que vejo em auditoria de ambiente EAD.

Trabalho com Moodle desde 2008, sou certificado na plataforma e já assumi a operação de ambientes de ensino a distância com dezenas de milhares de matrículas ativas. A conta que interessa nunca é o número de usuários cadastrados. É quantos deles abrem a mesma atividade no mesmo minuto.

O que o pico revela sobre o ambiente

Se o seu Moodle fica lento só no início do semestre, o gargalo raramente é CPU. Costuma ser sessão em disco em vez de Redis, cache de curso invalidado a cada acesso, ou uma consulta de course_modules sem índice adequado depois de uma restauração mal feita. São problemas de configuração, não de hardware — e são baratos de resolver quando identificados antes da matrícula.

A UFBA não opera um Moodle. Opera vários

Quem procura por Moodle UFBA encontra endereços diferentes, e isso confunde até quem é da casa. Na prática, Moodle UFBA funciona como nome guarda-chuva para pelo menos três ambientes distintos. O ava.ufba.br se apresenta como ambiente de apoio aos componentes de graduação e pós-graduação, com acesso via autenticação federada (Shibboleth). O www.moodle.ufba.br mantém login local, com opção de criar conta e recuperar senha. A página da STI/UFBA aponta ainda para outro portal e centraliza todo o atendimento no e-mail [email protected]. Há também um devmoodle.ufba.br publicamente acessível.

Não estou apontando o dedo: essa fragmentação é a norma nas federais brasileiras. Ela nasce de decisões razoáveis tomadas em momentos diferentes — um ambiente para a graduação, outro para cursos de extensão, um terceiro criado às pressas na pandemia que nunca foi desligado.

O custo aparece depois, e é sempre o mesmo:

• Superfície de manutenção multiplicada. Cada instância tem seu ciclo de patch, seus plugins, seu tema, seu cron.
• Suporte impossível de padronizar. O mesmo e-mail atende usuários de ambientes com regras de login distintas.
• Dados de aprendizagem fragmentados. Relatório de engajamento institucional vira exportação manual e planilha.
• Risco assimétrico. Basta a instância mais esquecida estar desatualizada para comprometer a reputação do domínio inteiro.

Consolidar ou isolar: como decidir

A dispersão que aparece no Moodle UFBA existe em quase toda federal que acompanhei, e a decisão entre juntar e separar precisa de critério. A regra que uso é simples. Instâncias com o mesmo público e o mesmo ciclo acadêmico devem ser consolidadas — dois Moodles de graduação são um problema, não uma redundância. Instâncias com requisitos regulatórios ou de carga muito distintos (um ambiente de certificação corporativa, por exemplo) podem permanecer separadas, desde que entrem no mesmo pipeline de atualização. O que não pode existir é a terceira categoria: a instância que ninguém reivindica.

A pista que o rodapé entrega: qual versão está no ar

Todo Moodle publica a própria versão sem pedir licença, e a home do Moodle UFBA com login local entrega esse dado sem exigir esforço nenhum. No bloco de download do aplicativo móvel, a plataforma expõe o número da build. Em uma verificação feita em 30 de agosto de 2026, a home de www.moodle.ufba.br trazia 2022112814.02 — número que corresponde à linha Moodle 4.1 LTS, lançada em 28/11/2022, sobre o tema Adaptable e servida por Apache 2.4.65 em Debian.

O que vale registrar sobre o Moodle UFBA aqui é o método, não o veredito sobre a instituição. Repito: isso não é uma peculiaridade da UFBA. É o retrato da maioria dos Moodles institucionais que audito no Brasil. E o dado relevante não é a idade da versão, é a data de corte: segundo o endoflife.date, o suporte de segurança da linha 4.1 LTS terminou em 08/12/2025. De lá para cá, correções de segurança publicadas pelo Moodle HQ não são mais retroportadas para esse ramo.

Como checar a versão do seu ambiente em 30 segundos

1. Abra a página inicial do LMS deslogado e procure o bloco do app móvel — a build aparece ali.
2. Logado como administrador, vá em Administração do site → Notificações: a versão completa e o número de build ficam no topo.
3. Compare a build com a tabela de releases oficial e anote a data de fim de suporte de segurança.
4. Rode php admin/cli/checks.php no servidor: o relatório de verificações do próprio Moodle já sinaliza versão de PHP incompatível, cron parado e HTTPS mal configurado.

Se o resultado do passo 3 for uma data no passado, você não tem um projeto de upgrade — tem um incidente aguardando data.

O calendário de suporte do Moodle em 2026

O Moodle HQ mantém um ciclo previsível: uma versão maior a cada seis meses, com LTS a cada quatro releases. Versões comuns recebem 18 meses de segurança; LTS recebem 36. Os números abaixo vêm da documentação oficial de releases, cruzados com o endoflife.date.

Versão	Lançamento	Fim do suporte geral	Fim do suporte de segurança
4.1 LTS	28/11/2022	11/12/2023	08/12/2025
4.5 LTS	07/10/2024	06/10/2025	04/10/2027
5.0	14/04/2025	20/04/2026	05/10/2026
5.1	06/10/2025	05/10/2026	19/04/2027
5.2	20/04/2026	19/04/2027	04/10/2027
5.3 LTS	05/10/2026 (previsto)	04/10/2027	01/10/2029

Se o Moodle UFBA fosse o seu ambiente, a leitura seria direta: a linha 4.1 saiu do mapa de segurança há mais de oito meses. Duas leituras práticas saltam da tabela. A primeira: quem está em 5.0 perde cobertura de segurança em 05/10/2026 — daqui a poucas semanas. A segunda, mais importante: o 5.3 LTS chega em outubro de 2026 com validade até 2029. Para uma instituição pública, que planeja compra e parada técnica com meses de antecedência, pular direto de 4.x para o 5.3 LTS é quase sempre a decisão certa. Você troca dois upgrades por um e ganha três anos de tranquilidade.

O que muda de verdade da linha 4 para a linha 5

Não é maquiagem de interface. As mudanças da série 5 alteram a forma como o ambiente é operado:

• Nova estrutura de diretórios. Os arquivos servidos ao navegador passam a ficar concentrados em uma pasta public, mantendo configuração sensível fora do alcance direto por URL. É ganho real de segurança — e exige revisar o DocumentRoot do vhost, não só rodar o instalador. Para um ambiente do porte do Moodle UFBA isso significa mexer em configuração de servidor antes de tocar no LMS.
• Controles granulares de IA. As políticas de uso de inteligência artificial passam a ser configuráveis por curso e por atividade, com novos provedores suportados, incluindo modelos abertos hospedados pela própria instituição.
• Visão de curso reformulada. O aluno recebe uma tela consolidada de cursos, atividades e prazos, com ícones por tipo de atividade e avisos em linguagem natural ("vence amanhã") em vez de datas cruas.
• Open Badges 3.0 e notificações por SMS, úteis para instituições que certificam trilhas e precisam reduzir evasão em prazos críticos.

O ponto de atenção é sempre o mesmo: plugins de terceiros. Tema customizado, integração de webconferência, plugin de relatórios acadêmicos e módulos de proctoring são o que efetivamente trava um upgrade. A versão do núcleo é a parte fácil.

Use o calendário acadêmico como janela de manutenção

Aqui está a virada de chave que quase ninguém aplica. O calendário 2026.2 da UFBA — como o de qualquer instituição — já entrega, publicado com meses de antecedência, o mapa das janelas de menor risco. Os marcos de 25% (17/09), 50% (17/10) e 75% (18/11) delimitam períodos de avaliação; as semanas imediatamente após cada marco costumam ser vales de tráfego.

O mesmo calendário que faz o Moodle UFBA ser buscado em agosto é o que indica quando parar o serviço com o menor prejuízo. Meu roteiro para agendar uma parada técnica:

1. Nunca na primeira ou na última semana do período letivo (19/08 e 19/12, no caso da UFBA).
2. Evite as 72 horas anteriores a cada marco de percentual — é quando fecham prazos de envio.
3. Prefira o intervalo entre o fim de um semestre e o início do seguinte para upgrades de versão maior; use fins de semana para patches menores.
4. Anuncie a janela com 15 dias de antecedência, dentro do próprio ambiente, e mantenha uma página de status fora do LMS.
5. Tenha rollback testado — snapshot do banco e do moodledata, restaurados em homologação antes de tocar em produção.

Nunca faça upgrade sem homologação com dados reais anonimizados. Um Moodle vazio sobe em qualquer versão; o problema aparece quando 40 mil registros de conclusão precisam ser migrados.

Integração com o sistema acadêmico: onde a migração quebra

O calendário da UFBA menciona explicitamente matrícula e rematrícula via SIGAA, além de uma janela de migração de dados. É o caso do Moodle UFBA e do SIGAA, e o de praticamente toda federal brasileira. Esse é o ponto mais frágil de qualquer projeto de Moodle em instituição de ensino: a sincronização entre o sistema acadêmico (fonte da verdade sobre matrícula) e o LMS (fonte da verdade sobre atividade).

Três armadilhas recorrentes:

• Sincronismo unidirecional mal desenhado. Quando o LMS aceita inscrição manual em curso sincronizado, a próxima execução do job de integração pode remover o aluno — e junto vão as notas se a política de suspensão estiver errada. Use suspender, nunca remover.
• Identificador instável. Chavear a integração por e-mail é convite a duplicidade. O identificador precisa ser o número de matrícula ou o idnumber institucional, imutável.
• Cron sem monitoramento. Integração que falha em silêncio só é descoberta pelo aluno que não vê a disciplina. Alarme no cron do Moodle é item obrigatório, não refinamento.

O app móvel: onde a versão do LMS vira experiência do aluno

Existe uma consequência da versão que raramente entra na conversa: o aplicativo. Recursos de app dependem de APIs do núcleo, e um ambiente parado em uma linha antiga limita o que o aluno consegue fazer no celular — especialmente acesso offline e notificações.

Um ambiente na escala do Moodle UFBA sente esse limite primeiro no aplicativo, e só depois no navegador. É por isso que, para instituições que levam mobile a sério, tratamos o upgrade e a estratégia de app como um projeto só. Já detalhei em outros textos como o aplicativo Moodle personalizado supera o app oficial, como funciona o acesso offline no app Moodle e o que muda no comparativo entre o app oficial e um app próprio. Para quem já decidiu ter o próprio aplicativo, o passo seguinte é o processo de publicação na Google Play e na App Store, e vale entender o efeito das notificações push no engajamento.

Uma observação de campo: em ambientes que acompanhei, o aumento de acesso via aplicativo se concentra exatamente nas semanas de prazo — os mesmos vales e picos que o calendário acadêmico prevê. App e infraestrutura são o mesmo problema visto de dois ângulos.

Checklist de upgrade que aplicamos na Agathas Web

Esse é o roteiro que seguimos em migrações de Moodle, e ele vale tanto para um ambiente corporativo de 500 alunos quanto para algo na escala do Moodle UFBA com dezenas de milhares de matrículas. Na ordem:

1. Inventário. Versão do núcleo, versão do PHP, banco, lista de plugins com autor e última atualização, tamanho do moodledata.
2. Triagem de plugins. Cada plugin recebe um destino: mantém (há versão compatível), substitui (existe equivalente no núcleo) ou descarta. Plugin abandonado é dívida, não funcionalidade.
3. Homologação espelhada. Clone com dados reais anonimizados, mesma versão de PHP de destino, mesmo esquema de cache.
4. Upgrade em etapas. Saltos muito longos exigem versão intermediária; o instalador não perdoa migrações de esquema puladas.
5. Testes funcionais roteirizados. Login federado, envio de tarefa, tentativa de questionário, exportação de notas, emissão de certificado, acesso pelo app.
6. Performance sob carga sintética. Simule a primeira semana de aula, não uma terça-feira comum.
7. Corte com rollback pronto e monitoramento reforçado nas 72 horas seguintes.

O passo 5 é o que separa uma migração tranquila de uma crise: quase todo problema pós-upgrade aparece em fluxo de avaliação, não no login.

Conclusão: o que levar do caso Moodle UFBA

O interesse em Moodle UFBA é sazonal e volta todo semestre. O que não é sazonal é a pergunta que ele expõe: sua instituição sabe qual versão cada ambiente está rodando, até quando ela recebe correção de segurança e em que semana do calendário a próxima parada técnica cabe?

O caso do Moodle UFBA serve de espelho aqui: o que não se mede, não se atualiza. Se a resposta demorar mais de cinco minutos, comece pelo inventário — é a etapa mais barata e a que mais reduz risco. E se o alvo for chegar ao 5.3 LTS antes do próximo período letivo, o momento de mapear plugins é agora, não em dezembro.

Na Agathas Web trabalhamos com hospedagem, manutenção e upgrade de Moodle, integração com sistemas acadêmicos e desenvolvimento de aplicativos próprios para instituições de ensino. Se quiser uma leitura técnica do seu ambiente antes de decidir a rota de atualização, é só falar com a gente.