Atualizar o Magento 2.4.4 direto para a 2.4.9: dá para pular versões?

Pular versão no upgrade do Magento: o que a documentação diz

O procedimento de upgrade por Composer da Adobe aponta direto para a versão de destino, com composer require-commerce e o número da versão. A única parada intermediária que o guia manda fazer é para quem está antes da 2.4.1, que precisa passar por uma versão compatível com o Composer 2, como a 2.4.2. Quem está na 2.4.4, 2.4.5 ou 2.4.6 não tem essa obrigação.

O que a documentação cobra sem exceção é a infraestrutura. A matriz de requisitos diz que a Adobe só suporta as combinações listadas e dá um exemplo que interessa aqui: a 2.4.9 é testada com MariaDB 12.3, e quem usa MariaDB precisa estar nessa versão antes do upgrade.

Pular versão também não pula mudança de banco. No upgrade, o bin/magento setup:upgrade aplica de uma vez tudo o que falta entre a versão antiga e a nova, e o Magento registra os patches aplicados na tabela patch_list. Em banco grande, esse tempo precisa ser medido na homologação.

E o prazo aperta: pela política de ciclo de vida, o suporte padrão da 2.4.4 terminou em 12/04/2025, o da 2.4.5 em 12/08/2025 e o da 2.4.6 em 11/08/2026. Os prazos de cada versão estão resumidos em versões e prazos de suporte.

O que muda em PHP, banco, busca e cache até a 2.4.9

Resumo da matriz on-premises da Adobe (atualizada em 11/08/2026), somando as duas correções mais recentes de cada versão. Da 2.4.4 para a 2.4.9, o RabbitMQ também vai de 3.9 ou 3.13 para 4.3 e o Varnish, de 7.7 para 8. Três leituras mudam o plano:

• Nenhuma versão anterior tem PHP 8.5 na matriz. Até quem está na 2.4.8, para ficar dentro da matriz, troca o PHP na mesma mudança que troca o código. Ir por etapas não evita essa troca, só a empurra para o último degrau.
• Composer aceitar não é a Adobe suportar. O composer.json da 2.4.9 aceita PHP 8.3, 8.4 e 8.5, e o da 2.4.8-p4 aceita 8.2, 8.3 e 8.4. A matriz lista só 8.5 e só 8.3 e 8.4, respectivamente.
• Da 2.4.4 para a 2.4.9 não há banco em comum na matriz. O banco novo nasce no ambiente novo, com uma cópia dos dados. Quem sai do MySQL 8.0 para o 8.4 tem um passo extra documentado pela Adobe: sem ajustar o parâmetro restrict_fk_on_non_standard_key, a importação falha com erro de chave estrangeira.

Atualizar direto ou por etapas: 4 perguntas para decidir

1. Dá para montar um ambiente novo com a pilha da 2.4.9? Servidor ou contêiner novo, com PHP 8.5, banco, OpenSearch e Valkey da matriz. Se dá, o salto direto é natural: a loja antiga segue vendendo até a virada. Se o único caminho é trocar peças no servidor atual, que às vezes atende outros sistemas, as etapas mantêm cada troca pequena.
2. As extensões críticas têm versão para a 2.4.9? Pagamento, frete, ERP e nota fiscal. Se uma delas só chega à 2.4.8, parar na 2.4.8, com suporte até 31/05/2028, é uma etapa com prazo, não um desvio.
3. Há código alterado dentro de vendor/ ou correção aplicada à mão? O Composer substitui os pacotes na atualização e a alteração some. Cada correção manual precisa virar patch versionado ou módulo antes, em qualquer caminho.
4. Quantas janelas de teste e de virada a operação aguenta? Cada etapa em produção é um ciclo completo de homologação, teste do checkout e virada.

Exemplo para comparar esforço: da 2.4.4 à 2.4.9 passando pela 2.4.6, pela 2.4.7 e pela 2.4.8, são quatro viradas, cada uma com teste de regressão e janela de manutenção. O salto direto concentra tudo em uma virada, com mais correções de uma vez e um teste mais longo. O direto economiza os ciclos repetidos; as etapas diminuem o tamanho de cada mudança. Os fatores que pesam no preço de cada caminho estão em quanto custa atualizar o Magento 2.

Ordem de atualização de PHP e banco no Magento

1. Levantamento: versão exata, extensões, código próprio, integrações e a pilha atual comparada com a matriz. O que conferir está no checklist antes de atualizar para a 2.4.9.
2. Infraestrutura em homologação: ambiente com PHP 8.5, MySQL 8.4 ou MariaDB 12.3, OpenSearch 3 e Valkey 9, com cópia recente do banco e da pasta de mídia.
3. Código: atualização por Composer para a 2.4.9, extensões nas versões novas e correção do que quebrou no tema e nos módulos próprios.
4. Dados: setup:upgrade no banco copiado, reindexação completa e medição do tempo de cada passo, que vira a estimativa da janela.
5. Testes: fluxo de compra completo, integrações, e-mails e rotinas do cron.
6. Virada: nova cópia dos dados de produção, repetição dos passos medidos, troca do tráfego e plano de volta definido antes de começar.

Loja com Elasticsearch troca de motor de busca e recria o índice no OpenSearch; loja com Redis passa cache e sessão para o Valkey. Os dois entram no passo 2, nunca no dia da virada.