Atualizar uma loja Magento quase sempre custa menos do que migrar quando a instalação está poucas versões atrás e foi construída com extensões mantidas e pouco código próprio. Migrar passa a fazer sentido quando o custo de cada atualização cresce por causa de personalizações, quando extensões essenciais foram abandonadas ou quando a operação mudou e a plataforma já não é a mais adequada. Não dá para saber de qual lado a sua loja está sem um inventário e um teste em homologação.
Este guia é para lojas em Magento 2, na edição Open Source ou no Adobe Commerce. Se a dúvida ainda é qual das duas edições faz sentido, veja a comparação entre Magento Open Source ou Adobe Commerce.
O que inventariar antes de decidir?
O próprio guia de atualização da Adobe aponta onde está o risco: a flexibilidade do Magento é uma vantagem, mas personalizações que não seguem as boas práticas levam a custos de atualização maiores do que o esperado. O inventário serve para encontrar essas personalizações antes de alguém orçar.
Versão e edição. Anote a edição (Open Source ou Adobe Commerce), a versão exata com o patch e a modalidade de hospedagem. A página de versões da Adobe, consultada em 20/10/2026, mostra a situação de cada linha do Adobe Commerce:
| Linha | Fim do suporte padrão | Fim do suporte estendido | Fim do período só de segurança |
|---|---|---|---|
| 2.4.9 | 31/05/2029 | A definir | Não se aplica |
| 2.4.8 | 31/05/2028 | A definir | Não se aplica |
| 2.4.7 | 31/05/2027 | 31/05/2028 | Não se aplica |
| 2.4.6 | Encerrado em 11/08/2026 | 31/08/2027 | 31/05/2028 |
| 2.4.5 | Encerrado em 12/08/2025 | Encerrado em 11/08/2026 | 31/05/2027 |
| 2.4.4 | Encerrado em 12/04/2025 | Encerrado em 14/04/2026 | 31/05/2027 |
| 2.4.0 a 2.4.3 | Encerrado em 28/11/2022 | Não informado | Não informado |
| 2.3 | Encerrado em 08/09/2022 | Não informado | Não informado |
A política de ciclo de vida define o suporte padrão como três anos a partir do lançamento de cada versão e trata o período só de segurança como tempo de transição, não como suporte de longo prazo. Essas datas são do Adobe Commerce; se a loja é Open Source, confirme com quem mantém a instalação como cada linha está sendo corrigida.
Ambiente. Registre versões de PHP, banco de dados, mecanismo de busca, cache e servidor web. A Adobe só suporta as combinações listadas na tabela de requisitos de cada versão. Dois pontos da documentação de pré-requisitos costumam surpreender em lojas antigas: a partir da 2.4, o MySQL deixou de ser aceito como mecanismo de busca do catálogo, e Elasticsearch ou OpenSearch passaram a ser obrigatórios.
Tema. Diga se a loja usa Luma, um tema derivado dele, um tema comprado ou uma vitrine separada (PWA ou headless). Temas muito alterados são uma das fontes de retrabalho na atualização.
Extensões. Para cada extensão, registre fornecedor, versão instalada, se é instalada por Composer, se o fornecedor ainda publica versões compatíveis e qual função ela cumpre. A Adobe lembra um caso que afeta quem vem de versões anteriores à 2.4.4: as extensões que vinham embutidas no pacote (como Amazon Pay, Dotdigital, Klarna, Vertex e Yotpo) foram removidas e precisam ser declaradas como dependências antes da atualização.
Código próprio. Liste módulos criados para a loja, alterações em arquivos do núcleo ou de extensões e integrações feitas sob medida. Cada item desses precisa ser revisado à mão na versão alvo.
Como estimar a compatibilidade e o custo da atualização em homologação?
A estimativa confiável sai de uma atualização de verdade, feita numa cópia da loja fora do ar.
- Montar a homologação. Copiar código, banco e mídia para um ambiente separado, com o mesmo conjunto de serviços que a versão alvo exige. A tabela de requisitos indica a ordem: por exemplo, a 2.4.9 foi testada com MariaDB 12.3, e o banco deve ser atualizado antes da loja.
- Atualizar dependências e extensões. A Adobe documenta a atualização de módulos por Composer, seguida de
setup:upgrade, publicação de arquivos estáticos e limpeza de cache. Extensões sem versão compatível entram numa lista à parte. - Revisar o código próprio. Cada módulo da lista passa por correção ou reescrita. No Adobe Commerce, a Adobe lista o Upgrade Compatibility Tool entre as ferramentas que ajudam a apontar incompatibilidades.
- Testar a operação. Busca, filtros, carrinho, checkout com cada meio de pagamento, cálculo de frete, emissão de nota, envio de pedido ao ERP e área do cliente.
- Medir o esforço. Registrar horas por item. Esse número, e não uma estimativa por versão, é o que vai para a comparação com a migração.
Dois fatos da documentação entram na conta mesmo que a loja funcione. O guia de atualização informa que, para manter a conformidade PCI, a loja precisa estar no patch ou patch de segurança mais recente, e recomenda atualizar a cada ciclo de patches, porque atualizações adiadas acumulam dívida técnica e ficam mais caras. E, para quem está no Adobe Commerce em nuvem, a política de ciclo de vida avisa que, a partir de 1º de junho de 2027, ambientes com versões sem suporte deixarão de ser mantidos e poderão ter o tráfego suspenso.
Quando reconstruir ou migrar faz mais sentido?
Compare as duas saídas pelos mesmos critérios, com o resultado da homologação na mão.
| Critério | Sinal para atualizar | Sinal para migrar ou reconstruir |
|---|---|---|
| Distância de versão | Uma ou duas linhas atrás | Várias linhas atrás, com troca de PHP, banco e busca ao mesmo tempo |
| Extensões | Fornecedores ativos e versões compatíveis | Extensões essenciais sem versão nova ou sem fornecedor |
| Código próprio | Poucos módulos, bem isolados | Muitas alterações no núcleo e em extensões |
| Requisitos | A loja atual atende à operação | A operação mudou: canais, B2B, ERP ou equipe pedem outra plataforma |
| Equipe | Há quem mantenha Magento depois | Não há equipe nem fornecedor para manter |
| Custo recorrente | Cada atualização cabe no orçamento de manutenção | O custo de cada atualização se aproxima do custo de reconstruir |
Migrar não leva o código, leva os dados e as regras da operação. Produtos com atributos e variações, clientes, histórico de pedidos, avaliações, cupons ativos, conteúdo e, sobretudo, as URLs indexadas precisam de um plano. Cada URL antiga deve ter destino com redirecionamento permanente, e o lançamento precisa de critérios de corte e de recuo. O guia de planejamento da migração de plataforma detalha esse roteiro. Se a migração estiver em pauta, escolha o destino pelo mesmo conjunto de requisitos, com a matriz de como escolher a plataforma de e-commerce.
Uma observação para quem pensa em ficar no ecossistema Adobe e passar ao Adobe Commerce as a Cloud Service: a documentação informa que essa modalidade não suporta vitrines Luma. Para uma loja com tema Luma personalizado, isso equivale a reconstruir a vitrine.
Inventário de uma instalação demonstrativa, com ações nas duas saídas
O modelo abaixo é ilustrativo: uma instalação demonstrativa de Magento Open Source, não uma loja real nem um projeto executado. Ele mostra como o mesmo inventário alimenta as duas estimativas. Preencha a coluna “situação” com os dados da sua loja.
| Item | Situação na instalação demonstrativa | Compatível com a versão alvo? | Ação se atualizar | Ação se migrar |
|---|---|---|---|---|
| Edição e versão | Open Source 2.4.5-p17 | Não se aplica | Atualizar para a linha suportada escolhida | Exportar dados antes do corte |
| PHP, banco e busca | Versões da época da 2.4.5 | Não | Atualizar os serviços antes da loja | Não se aplica |
| Tema | Derivado do Luma, com muitas alterações | A verificar | Corrigir templates e estilos | Refazer a vitrine na nova plataforma |
| Extensão de frete | Fornecedor ativo (ilustrativo) | Sim, versão nova publicada | Atualizar por Composer | Substituir por recurso ou app da nova plataforma |
| Extensão de pagamento | Fornecedor sem versão nova (ilustrativo) | Não | Trocar de extensão e retestar o checkout | Usar meio de pagamento da nova plataforma |
| Integração com ERP | Módulo próprio | A verificar | Revisar e testar pedidos e estoque | Refazer a integração com o conector da nova plataforma |
| Alteração no checkout | Código próprio em arquivo de extensão | Não | Reescrever como módulo isolado | Avaliar se a regra ainda é necessária |
| Catálogo | Produtos configuráveis com atributos de cor e tamanho | Sim | Reindexar e testar filtros | Mapear atributos e variações no destino |
| Clientes e pedidos | Base com histórico | Sim | Manter | Definir o que migra e o que fica arquivado |
| URLs | Produtos e categorias indexados | Sim | Manter | Mapear todas e redirecionar com 301 |
| Responsável pela manutenção | Fornecedor contratado | Não se aplica | Manter o contrato de patches | Definir manutenção na nova plataforma |
Some as horas da coluna “se atualizar” medidas na homologação e compare com a proposta de migração. Inclua, nas duas colunas, o custo dos próximos ciclos: a atualização de hoje não é a última, e a migração traz mensalidades e manutenção próprias.
Condições e limites
As datas de suporte vêm da documentação do Adobe Commerce consultada em 20/10/2026 e podem mudar. Para Magento Open Source, confirme a situação das correções da sua linha com quem mantém a loja. Este texto não trata de Magento 1. O inventário é demonstrativo e não substitui a atualização de teste numa cópia da sua instalação.
Próximo passo
Se a decisão for continuar, o próximo passo é a homologação com o inventário acima. Se for migrar, siga o roteiro de migração de plataforma. A SouLoja trabalha com Nuvemshop, Shopify, WooCommerce, Tray, Loja Integrada, Wix e VTEX; se uma delas atender aos requisitos levantados, conheça a nossa criação de loja virtual e peça uma avaliação do projeto.
