Checklist para atualizar o Magento para a 2.4.9: servidor, extensões e loja

Requisitos do Magento 2.4.9: a matriz oficial e como conferir cada item

A Adobe publica, na página de requisitos de sistema, as combinações de software testadas com cada versão e avisa que só dá suporte às combinações listadas. Para a 2.4.9 em servidor próprio (on-premises), a tabela é esta, ao lado do comando que confere o servidor atual da sua loja:

Dois detalhes da documentação mudam a ordem do trabalho. O primeiro está na própria página de requisitos: a 2.4.9 foi testada com MariaDB 12.3, e a orientação é atualizar o MariaDB antes de atualizar o Magento. O segundo está nas notas de lançamento: o PHP 8.5 é o suportado, o PHP 8.4 é aceito só durante a atualização (não é recomendado em produção) e os PHP 8.2 e 8.3 deixaram de ser suportados. Banco novo com a loja antiga rodando é combinação que eu testo antes em homologação.

O que verificar antes do upgrade do Magento: três leituras que enganam

Três desses comandos enganam quem lê com pressa:

• O PHP do terminal não é o PHP da loja. O php -v mostra o PHP de linha de comando. Quem atende o visitante é o PHP-FPM, que pode estar em outra versão no mesmo servidor. No Ubuntu o binário leva o número no nome (por exemplo, php-fpm8.3 -v). Confira os dois.
• O mysql --version mostra o cliente, não o servidor. A saída cita a versão do programa de linha de comando instalado naquela máquina. A versão que importa é a que o banco devolve em SELECT VERSION();.
• O Valkey responde como se fosse Redis 7.2.4. No INFO server, o Valkey mantém um campo redis_version com valor fixo por compatibilidade. Para saber o que está rodando, leia server_name e valkey_version.

Confirme também qual motor de busca a loja usa hoje, com bin/magento config:show catalog/search/engine. Se a resposta citar Elasticsearch, a migração para o OpenSearch 3 entra na conta.

Preparar a loja para a atualização: extensões, tema e integrações

Servidor em dia não garante loja compatível. A 2.4.9 trocou o Laminas MVC por uma implementação MVC nativa, substituiu o Zend_Cache pelo Symfony Cache e migrou o editor de conteúdo do admin do TinyMCE para o HugeRTE. Cada mudança dessas pode atingir código que não é da Adobe. Eu separo o levantamento em três blocos, cada um com o seu sinal de alerta.

Extensões de terceiros

• Liste o que a loja exige diretamente com composer show --direct --no-dev e os módulos ativos e inativos com bin/magento module:status.
• Para cada extensão, procure a versão que o fornecedor declara compatível com a 2.4.9 e com PHP 8.5.
• Sinal de alerta: extensão sem versão nova desde o lançamento da 2.4.9, em 12/05/2026, fornecedor que não responde ou módulo copiado para app/code sem origem conhecida.

Tema

• Identifique se o tema foi comprado ou feito sob medida e quantos templates do core ele sobrescreve.
• Sinal de alerta: tema comprado que o autor parou de atualizar, ou personalização em cima do editor de conteúdo do admin, que mudou de TinyMCE para HugeRTE.

Integrações

• Liste ERP, gateway de pagamento, frete, marketplaces e emissão de nota, com o nome de quem mantém cada uma.
• Sinal de alerta: integração sem responsável ativo ou sem ambiente de teste do outro lado (sandbox do gateway, base de teste do ERP). Sem isso, o teste de ponta a ponta fica para depois da virada, que é o pior momento.

Na edição Adobe Commerce existe ainda o Upgrade Compatibility Tool, que analisa os módulos e o código instalados contra a versão de destino e devolve a lista de problemas críticos, erros e avisos. A ferramenta é só para Adobe Commerce; no Magento Open Source esse levantamento é manual.

Homologação e rollback: o que precisa existir antes da janela

A atualização roda primeiro numa cópia da loja, nunca direto em produção. Antes de marcar a data, eu confiro esta lista:

1. Ambiente de homologação com os mesmos serviços da produção nas versões de destino, e não uma cópia qualquer.
2. Pré-requisitos do guia de upgrade da Adobe: tabelas do banco no formato DYNAMIC em vez de COMPACT, motor InnoDB em vez de MyISAM, cron rodando e limite de arquivos abertos ajustado.
3. Roteiro de teste do fluxo de compra: busca, filtro, carrinho, checkout, cada meio de pagamento, cálculo de frete, e-mail de pedido e envio ao ERP.
4. Backup que restaura, testado, e não só gerado. A atualização altera o banco; voltar só o código não devolve a loja ao estado anterior.
5. Plano de rollback escrito, com o ponto de decisão (até quando dá para voltar) e quem autoriza.

Item que não existe vira parte do projeto, com prazo e custo próprios.

O que levar ao fornecedor antes do orçamento

Com o checklist feito, o pedido de orçamento vira uma lista objetiva. Eu peço estas informações:

• a versão exata, com o sufixo -p, saída de bin/magento --version (ou o número que aparece no rodapé do admin);
• a edição: Magento Open Source ou Adobe Commerce, e onde a loja está hospedada;
• a lista de extensões (composer show --direct --no-dev) e os módulos em app/code;
• as versões reais de PHP-FPM, banco, busca, cache, fila e Varnish;
• as integrações e quem responde por cada uma;
• se já existe homologação e roteiro de teste.

Se a loja ainda está na 2.4.6 ou em versão anterior, o prazo pesa mais do que o destino: veja a tabela de prazos de suporte de cada versão do Magento antes de decidir entre parar na 2.4.8 ou ir direto para a 2.4.9.