O Adobe Commerce 2.4.5 chegou ao fim do suporte, mas isso não significa que a loja deixará de funcionar imediatamente. Significa que manter essa linha em produção passa a exigir uma avaliação mais rigorosa de segurança, compatibilidade e continuidade operacional.
O suporte estendido do Adobe Commerce 2.4.5 terminou em 11 de agosto de 2026. O suporte regular do Adobe Commerce e o suporte ao Magento Open Source dessa linha já haviam terminado em 12 de agosto de 2025, conforme a tabela oficial da estratégia de releases e política de ciclo de vida.
Para uma operação brasileira, a decisão não deve ser apenas “atualizar ou não”. É necessário descobrir o que bloqueia a migração, escolher uma versão de destino compatível e proteger checkout, pagamentos, cálculo de frete, integrações fiscais, estoque e rotinas administrativas durante a mudança.
O que o fim do suporte do Adobe Commerce 2.4.5 representa?
O encerramento do ciclo não desliga a aplicação, remove módulos ou bloqueia o painel. A loja pode continuar processando acessos enquanto aplicação e infraestrutura permanecerem operacionais. O problema é continuar dependendo de uma linha que ultrapassou seu período oficial de manutenção.
A política da Adobe informa que o suporte estendido das versões 2.4.4 e 2.4.5 termina, respectivamente, em abril e agosto de 2026. Para clientes Adobe Commerce na nuvem, a orientação é migrar para uma versão suportada ou para o Adobe Commerce as a Cloud Service antes do encerramento, segundo a política oficial de ciclo de vida.
Na prática, a loja precisa tratar a atualização como projeto de continuidade, e não como manutenção pontual. Quanto mais tempo a versão antiga permanecer, maior tende a ser o conjunto de diferenças acumuladas entre o código atual, as extensões instaladas e a infraestrutura exigida pelo destino escolhido.
8 etapas para planejar a migração do Adobe Commerce 2.4.5
1. Confirme a edição e a versão realmente instaladas
Não use apenas uma anotação interna ou o nome do projeto no painel da hospedagem. No diretório da aplicação, registre a saída dos comandos:
bin/magento --version
composer show magento/product-enterprise-edition
composer show magento/product-community-editionUm dos pacotes pode não existir, dependendo da edição. Preserve também os arquivos composer.json e composer.lock, o histórico de deploy e a lista de patches aplicados. Isso evita planejar a atualização a partir de uma versão presumida.
2. Faça um inventário da infraestrutura
Registre as versões efetivamente utilizadas de PHP, Composer, banco de dados, mecanismo de busca, Redis ou outro serviço de cache, mensageria, servidor web e sistema operacional. Inclua serviços externos responsáveis por mídia, CDN, e-mail e observabilidade.
A Adobe alerta que o suporte estendido da aplicação não elimina a necessidade de avaliar tecnologias de terceiros que também tenham alcançado o próprio fim de suporte, incluindo MariaDB, PHP, Composer, OpenSearch, Redis e RabbitMQ, conforme a FAQ oficial do ciclo de vida.
Portanto, atualizar somente o pacote do Commerce pode não ser suficiente. Consulte também quais dependências antigas precisam entrar no planejamento.
3. Escolha o destino pela compatibilidade, não apenas pelo número
As linhas 2.4.6, 2.4.7 e 2.4.9 podem aparecer nas discussões da equipe, mas a escolha não deve ser feita apenas por proximidade ou por ser a maior numeração disponível. Compare o ciclo de vida da versão, os requisitos da infraestrutura, o caminho de atualização e a compatibilidade das extensões indispensáveis.
Se a avaliação considerar a linha 2.4.9, revise previamente as mudanças de PHP, banco, busca, cache, filas e ferramentas de instalação. Nosso checklist de infraestrutura do Adobe Commerce 2.4.9 ajuda a organizar esse levantamento sem transformar a produção em ambiente de teste.
4. Classifique módulos e customizações por criticidade
Liste extensões de pagamento, antifraude, frete, ERP, marketplace, fiscal, atendimento, busca e marketing. Para cada componente, registre fornecedor, versão, origem do pacote, licença, dependências e uso real. Módulos instalados e desativados também devem entrar no inventário, pois ainda podem afetar o Composer ou o processo de compilação.
Separe as customizações próprias por área funcional. Um override no checkout, uma preferência de classe ou um plugin em pedidos exige atenção maior do que uma alteração visual isolada. Evite concluir que um módulo é compatível apenas porque a instalação terminou sem erro.
5. Simule a resolução do Composer fora da produção
Crie uma cópia controlada do projeto e solicite ao Composer a versão pretendida sem iniciar uma atualização indiscriminada. Dependendo do pacote e da edição, a análise pode começar com comandos como:
composer why-not magento/product-enterprise-edition VERSAO_DE_DESTINO
composer prohibits magento/product-enterprise-edition VERSAO_DE_DESTINO
composer outdated --directSubstitua o marcador pela versão avaliada e adapte o pacote à edição. Não apague o composer.lock como primeira tentativa: ele documenta o conjunto instalado. Quando a resolução falhar, identifique qual pacote bloqueia a atualização do Magento antes de remover dependências.
6. Monte uma homologação representativa
A homologação precisa reproduzir, na medida necessária, arquitetura, configuração, serviços e fluxo de deploy. Utilize dados anonimizados quando houver informações de clientes e controle o envio de e-mails, notificações, cobranças e chamadas para sistemas externos.
Teste ao menos cadastro, login, busca, categorias, produto configurável, carrinho, cupom, endereço, frete, pagamento aprovado e recusado, criação de pedido, faturamento, expedição, cancelamento, estorno, estoque, cron, indexadores, filas, APIs e painel administrativo. Para meios de pagamento, use os ambientes de teste fornecidos pelos respectivos operadores.
7. Defina critérios objetivos de aprovação
“A página abriu” não é um critério suficiente. Registre resultados esperados, responsáveis e evidências para cada fluxo. Compare logs, tempos das rotas críticas, consumo de recursos, processamento do cron e sincronização com ERP, transportadoras, gateways e hubs.
Estabeleça também condições que impedem o deploy: divergência de valores, pedido sem integração, falha no retorno de pagamento, estoque inconsistente, erro recorrente em filas ou aumento não explicado de respostas HTTP 500. Isso reduz decisões improvisadas durante a janela de mudança.
8. Prepare implantação, observação e rollback
Antes do deploy, faça backup verificável de banco, arquivos necessários e configurações. Registre o commit, os pacotes instalados, as alterações de infraestrutura e o procedimento completo. O rollback deve considerar a compatibilidade do banco após os comandos de atualização; restaurar apenas o código antigo pode não ser suficiente.
Planeje uma janela compatível com o volume de pedidos e mantenha responsáveis por aplicação, infraestrutura e integrações disponíveis. Depois da publicação, acompanhe checkout, pedidos, pagamentos, filas, cron, indexadores, logs e métricas de servidor. Evite acumular outras mudanças funcionais no mesmo deploy.
É seguro permanecer temporariamente na versão 2.4.5?
A resposta depende da exposição da loja, dos controles existentes e do prazo real para migrar. Permanecer temporariamente pode ser uma decisão operacional, mas não deve ser confundido com suporte oficial ativo. Documente a exceção, restrinja acessos administrativos, monitore alterações, revise credenciais e reduza o intervalo até a migração.
Também é importante separar dois riscos: o da aplicação Adobe Commerce 2.4.5 e o das tecnologias que a sustentam. Mesmo que a loja pareça estável, PHP, banco, busca, cache ou mensageria podem ter ciclos de vida diferentes e exigir ações próprias.
Perguntas frequentes
Minha loja Adobe Commerce 2.4.5 ainda recebe suporte estendido?
Não. A tabela oficial informa que o suporte estendido terminou em 11 de agosto de 2026. O suporte regular dessa linha havia terminado em 12 de agosto de 2025.
O fim do suporte faz a loja parar de funcionar?
Não automaticamente. A aplicação pode continuar operando, mas permanece em uma linha fora do período oficial de suporte, o que exige prioridade para avaliação e migração.
Posso atualizar diretamente para o Adobe Commerce 2.4.9?
A possibilidade deve ser validada no projeto. Requisitos de infraestrutura, caminho de atualização, Composer, patches, extensões e customizações precisam ser testados antes de escolher o destino.
Devo atualizar PHP e banco junto com o Commerce?
Depende da versão de destino e do ambiente atual. Levante cada componente e monte uma sequência que mantenha aplicação e serviços compatíveis durante a homologação e a implantação.
Conclusão
O Adobe Commerce 2.4.5 no fim do suporte pede um plano baseado em inventário, compatibilidade, homologação e rollback. Não comece pela produção nem transforme a escolha da versão em uma decisão isolada da infraestrutura.
Se sua equipe precisa confirmar o caminho de migração, diagnosticar bloqueios no Composer ou preparar a homologação, um suporte Magento especializado pode ajudar a organizar a atualização com menor risco para vendas e integrações.
Fontes consultadas
As informações atuais mencionadas neste artigo foram verificadas nas fontes abaixo.
