Adobe Commerce 2.4.9 requisitos e compatibilidade precisam ser avaliados como um conjunto, não como uma simples troca de versão do pacote principal. PHP, Composer, mecanismo de busca, banco de dados, extensões e integrações participam do upgrade e podem exigir janelas ou procedimentos diferentes.
Para lojas brasileiras, o planejamento também deve considerar checkout, PIX, cartão, antifraude, cálculo de frete, emissão fiscal e ERP. O objetivo deste guia é ajudar a separar compatibilidade oficial, estado real do ambiente e homologação funcional antes de alterar a produção.
O que muda nos requisitos do Adobe Commerce 2.4.9?
O Adobe Commerce 2.4.9 foi lançado em 12 de maio de 2026. A documentação dessa versão adiciona compatibilidade com PHP 8.5, Composer 2.9, OpenSearch 3.x e MariaDB 11.8/12.x, além de informar que PHP 8.2 e PHP 8.3 deixaram de ser suportados nessa linha. Os detalhes devem ser conferidos nas notas oficiais do Adobe Commerce 2.4.9.
Compatibilidade, entretanto, não significa que toda dependência precise ser migrada simultaneamente ou que qualquer combinação entre essas versões seja válida. A matriz de requisitos diferencia as combinações por release da plataforma; por exemplo, ela registra OpenSearch 3, Valkey 8.1, MariaDB 10.11 e PHP 8.2 para a linha 2.4.6-p15. Por isso, compare origem e destino diretamente nos requisitos de sistema do Adobe Commerce, sem reaproveitar a matriz de outra linha.
Adobe Commerce 2.4.9: requisitos e compatibilidade do ambiente real
O inventário deve ser feito a partir dos servidores e arquivos usados no deploy. O número exibido no Admin não revela sozinho a versão do PHP CLI, o Composer que resolve as dependências nem o serviço de busca efetivamente consultado pela aplicação.
Em ambiente controlado e com um usuário sem privilégios desnecessários, registre:
bin/magento --version
php -v
php -m
composer --version
composer check-platform-reqsConsulte também a versão do banco por uma conexão administrativa autorizada:
SELECT VERSION();Para o OpenSearch, use o endpoint interno definido pela equipe de infraestrutura, evitando expor credenciais no histórico do terminal:
curl -s http://HOST_INTERNO:9200/Complete o levantamento com sistema operacional, servidor web, PHP-FPM, extensões do PHP, Redis ou Valkey, RabbitMQ quando utilizado, Varnish, CDN e serviços externos. Registre separadamente o PHP executado pelo servidor web e pelo terminal: eles podem apontar para binários ou arquivos de configuração diferentes.
PHP 8.5 exige revisão do código personalizado
A compatibilidade oficial da plataforma não valida automaticamente módulos de terceiros, tema ou código próprio. Procure dependências com restrições de PHP, métodos obsoletos, avisos convertidos em erros e extensões nativas ausentes no novo runtime.
Faça primeiro uma instalação limpa das dependências em homologação, usando o arquivo de lock do projeto. Não esconda o conflito com atualizações indiscriminadas ou com opções que ignorem requisitos da plataforma. O comando abaixo ajuda a identificar pacotes que impedem a versão desejada:
composer why-not php 8.5Depois, acompanhe logs da aplicação, PHP-FPM e servidor web enquanto percorre catálogo, conta do cliente, carrinho, checkout e Admin. Se o objetivo for investigar lentidão depois da troca de runtime, use um diagnóstico por camada como o guia sobre Magento 2 lento, em vez de atribuir toda regressão ao PHP.
Composer 2.9 deve ser validado no pipeline
O Composer usado no notebook do desenvolvedor pode ser diferente daquele presente no CI/CD ou servidor de build. Registre a versão em cada etapa e teste autenticação dos repositórios, plugins autorizados, scripts pós-instalação e geração de autoload.
Execute o mesmo procedimento adotado em produção, mas em ambiente descartável ou de homologação. O resultado esperado não é apenas um comando concluído: o pacote instalado deve corresponder ao lock, o código compilado precisa ser gerado e os artefatos estáticos devem ficar disponíveis para todas as visões de loja.
OpenSearch 3.x requer teste de relevância e indexação
A migração do mecanismo de busca não termina quando a conexão fica verde. Crie índices novos em homologação, execute os indexadores e compare consultas conhecidas. Avalie nome completo, termos parciais, SKU, acentos, sinônimos, ordenação, filtros e produtos configuráveis.
Se itens ativos desaparecerem dos resultados, não reinicie o serviço nem reindexe repetidamente sem preservar evidências. Compare atributos, escopo e disponibilidade seguindo os testes para quando a busca do Magento 2 não encontra produtos.
MariaDB 11.8/12.x deve ser migrado como projeto próprio
A compatibilidade declarada com uma versão de banco não elimina a necessidade de backup restaurável, ensaio de migração, análise de consultas e plano de reversão. Compare parâmetros, conjunto de caracteres, collation, permissões, tamanho das tabelas e duração das operações de manutenção.
Evite combinar, na mesma janela, upgrade da aplicação, mudança de PHP, troca do OpenSearch e migração do banco quando a infraestrutura permitir etapas separadas. Alterações isoladas facilitam a identificação da origem de erros e reduzem a quantidade de componentes envolvidos na reversão.
Checklist de homologação antes do deploy
- Crie uma linha de base: registre tempos de resposta, filas, erros, consumo de recursos e resultados de busca antes da mudança.
- Restaure uma cópia sanitizada: confirme que backup de arquivos, banco e configurações pode ser recuperado.
- Instale dependências do zero: valide o lock, os plugins do Composer e os requisitos da plataforma.
- Compile e publique: teste injeção de dependência, conteúdo estático, temas, idiomas e permissões.
- Reindexe em homologação: acompanhe duração, falhas e uso de memória sem apagar logs.
- Teste sessões e cache: valide visitantes, clientes autenticados, carrinho, login e invalidação de conteúdo.
- Percorra o checkout brasileiro: use CEPs, métodos de entrega, cupom, PIX, cartão, antifraude e cenários de pagamento negado.
- Confirme o ciclo do pedido: verifique criação, faturamento, cancelamento, reembolso, estoque e integração com ERP.
- Valide tarefas assíncronas: observe cron, consumidores, e-mails e filas. Se houver acúmulo, consulte o diagnóstico para quando o cron do Magento 2 para.
- Prepare a reversão: defina critérios objetivos, responsáveis, comandos e limite de tempo para voltar à versão anterior.
É necessário atualizar tudo na mesma janela?
Não necessariamente. A sequência depende da matriz suportada na origem e no destino, da arquitetura e da possibilidade de manter compatibilidade transitória. A equipe pode preparar imagens de aplicação, validar o novo PHP e ensaiar a migração do banco antes do corte, mas não deve criar uma combinação intermediária fora dos requisitos oficiais.
Também não existe uma obrigação universal de trocar Redis por Valkey apenas por causa do upgrade. Identifique o serviço atual, confira a combinação suportada para a versão de destino e trate a migração como alteração de infraestrutura, com teste de sessões, cache e filas quando aplicável.
Perguntas frequentes
Quais versões de PHP são suportadas pelo Adobe Commerce 2.4.9?
As notas da versão adicionam compatibilidade com PHP 8.5 e informam que PHP 8.2 e 8.3 não são suportados nessa linha. Consulte a matriz oficial antes de escolher a versão exata do ambiente.
O Adobe Commerce 2.4.9 funciona com OpenSearch 3?
Sim. A documentação registra compatibilidade com OpenSearch 3.x. Ainda assim, extensões de busca, relevância, indexação, filtros e consumo de recursos precisam ser homologados.
Como testar PIX e integrações após o upgrade?
Teste aprovação, recusa, expiração, retorno assíncrono, atualização do pedido, faturamento, cancelamento e reembolso. Confirme também antifraude, ERP, estoque, frete e emissão fiscal.
É obrigatório migrar Redis para Valkey?
Não há uma resposta universal. Compare a infraestrutura atual com a matriz suportada para sua versão de destino e não inclua a troca na mesma janela sem necessidade e homologação.
Conclusão
Adobe Commerce 2.4.9 requisitos e compatibilidade devem orientar um upgrade dividido entre inventário, resolução de dependências, migração de serviços e homologação do negócio. PHP 8.5, Composer 2.9, OpenSearch 3.x e MariaDB 11.8/12.x ampliam as opções da plataforma, mas não substituem a validação do projeto instalado.
Se sua equipe precisa mapear dependências, preparar a homologação ou investigar incompatibilidades antes do deploy, o suporte técnico especializado pode ajudar a montar um plano de atualização compatível com a operação da loja, sem transformar a produção em ambiente de testes.
Fontes consultadas
As informações atuais mencionadas neste artigo foram verificadas nas fontes abaixo.
