Existe uma mudança em curso na estratégia da Adobe que merece leitura atenta de quem opera Magento no Brasil, e ela não é sobre funcionalidade nova. É sobre para onde a plataforma está sendo direcionada e o que isso implica para quem escolheu a edição comunitária.
Neste texto, explicamos o que é o Commerce as a Cloud Service, a quem a política de upgrade da Adobe se aplica, quais são as datas de 2026, 2027 e 2028 e o que cada modelo de operação ganha e perde.
Principais pontos
- A Adobe oferece o Adobe Commerce em três modelos: Commerce as a Cloud Service (SaaS), Commerce on Cloud (PaaS) e Adobe Commerce em infraestrutura própria (on-premises).
- Existe uma política de upgrade obrigatório para ambientes Adobe Commerce on Cloud (PaaS), com consequência prática de loja fora do ar.
- Duas datas de dependência vêm antes do upgrade de versão: 30 de outubro de 2026 e 31 de maio de 2027.
- A política vale para o Adobe Commerce on Cloud, e não para o Magento Open Source, para o Adobe Commerce on-premises nem para o Commerce as a Cloud Service.
- Isso reposiciona a autonomia do Open Source: o que parecia custo virou proteção contra a decisão de um terceiro, em troca de uma sustentação própria bem feita.
O que é o Commerce as a Cloud Service
O Commerce as a Cloud Service é a oferta SaaS da Adobe: uma plataforma de comércio nativa de nuvem, totalmente gerenciada e sem versão visível para o cliente (versionless). As atualizações são aplicadas pela Adobe como parte do serviço, e a infraestrutura também é da Adobe.
A documentação da Adobe compara três ofertas:
- Adobe Commerce as a Cloud Service (SaaS): multi-inquilino (multi-tenant), atualizado automaticamente pela Adobe.
- Adobe Commerce on Cloud (PaaS): inquilino único (single-tenant), com upgrades e patches feitos de forma manual, em hospedagem na AWS ou no Azure (o Google Cloud não é padrão).
- Adobe Commerce (on-premises): instalado em infraestrutura própria, com capacidades parecidas com as do modelo PaaS.
Em termos simples, no SaaS a Adobe decide quando a versão muda. No PaaS e no on-premises, quem opera a loja decide, dentro do calendário de suporte da Adobe.
A política de upgrade obrigatório e o que ela significa
Junto dessa organização do portfólio existe uma política de segurança com consequência real, publicada pela Adobe na documentação “Required actions and deadlines to secure Commerce environments”.
A partir de 1º de junho de 2027, a Adobe deixa de manter ambientes Cloud que rodam versões sem suporte e passa a tomar medidas para proteger a plataforma. Se o ambiente não cumpre as datas, a Adobe pode suspender o acesso ao admin para todos os usuários, com a vitrine ainda no ar, e pode suspender o tráfego de entrada, o que tira a vitrine do ar. Se o ambiente continua fora de conformidade depois da suspensão do tráfego, a Adobe pode encerrar o serviço e desativar o ambiente, e a desativação apaga os dados e os arquivos de forma permanente. Em português direto: a loja sai do ar.
Datas de versão
- Linhas 2.4.4 e 2.4.5: até 1º de junho de 2027.
- Linhas 2.4.6 e 2.4.7: até 1º de junho de 2028.
- Linhas 2.4.8 e 2.4.9: sem exigência de upgrade por enquanto, segundo a página da Adobe.
Os caminhos oficiais são dois: atualizar para a versão mais recente do Commerce on Cloud ou migrar para o Commerce as a Cloud Service.
Datas de dependências
As dependências têm datas próprias, que vêm antes do upgrade de versão. A política vale para todos os ambientes, e não só para produção. Pela tabela da Adobe:
- Até 30 de outubro de 2026: MariaDB/Galera 10.5 ou anterior (para 10.6 ou superior), Elasticsearch em qualquer versão (para OpenSearch) e RabbitMQ 3.9 ou anterior (para 3.13 ou superior).
- Até 31 de maio de 2027: PHP 8.1 ou anterior (para 8.2 ou superior), MariaDB/Galera acima da 10.5 e abaixo da 10.11 (para 10.11 ou superior), OpenSearch 1.x, Redis 5 ou anterior (para Valkey 8 ou superior) e RabbitMQ acima da 3.9 e abaixo da 3.13 (para 4.3 ou superior).
A primeira data cai quatro semanas antes da Black Friday de 2026, que é em 27 de novembro. Quem precisa cumpri-la e ainda não começou vai atualizar dependências na janela em que normalmente se congela mudança estrutural. Essa colisão de calendário pede uma conversa já, e não em novembro.
A quem essa política se aplica, e a quem não se aplica
Aqui está o ponto que mais gera confusão, e que muda completamente a leitura.
A política se aplica a ambientes Adobe Commerce on Cloud (PaaS) nas linhas 2.4.4 a 2.4.9. Segundo a própria Adobe, ela não se aplica ao Commerce as a Cloud Service nem ao Adobe Commerce on-premises. O Magento Open Source não é uma oferta de nuvem da Adobe, então também não entra nessa política.
Vale colocar essa informação ao lado de outra, que aparece nas notas de patches de segurança da Adobe: o suporte estendido, de um ano para as versões 2.4.6 e 2.4.7, é oferecido a clientes do Adobe Commerce.
As duas frases juntas descrevem uma troca que raramente é discutida em voz alta.
A troca que agora fica visível
Quem opera o Adobe Commerce em nuvem gerenciada pela Adobe tem a infraestrutura cuidada pelo fornecedor e um calendário de suporte claro. O preço dessa comodidade é que a data de atualização passa a ser definida por um terceiro, e o descumprimento tem consequência operacional direta na disponibilidade da loja.
Quem opera Magento Open Source não recebe suporte estendido e precisa manter a cadência de sustentação por conta própria ou com um parceiro: aplicar patches, trocar dependências que chegam ao fim de vida e planejar upgrades. Em compensação, ninguém suspende o tráfego da sua loja porque a sua versão saiu do calendário de outra empresa.
Nenhum dos dois modelos é melhor em abstrato. Para uma operação sem time técnico próprio nem parceiro com cadência confiável, a comodidade da nuvem gerenciada vale o que custa, inclusive a perda de controle sobre o calendário. Para uma operação com sustentação estruturada, a autonomia do Open Source deixou de ser apenas economia de licença e passou a ser previsibilidade de roadmap.
Antes era uma diferença de custo. Agora é também uma diferença de quem decide quando a sua loja precisa mudar.
O que isso deveria provocar na sua operação
Independentemente da edição, três verificações merecem entrar na pauta.
- Confirme sua edição, sua modalidade de hospedagem e sua versão exata. Adobe Commerce on Cloud, Adobe Commerce on-premises e Magento Open Source têm obrigações diferentes. A resposta muda tudo o que vem depois.
- Liste a data de fim de vida de cada dependência da sua pilha. Banco de dados, mecanismo de busca, cache, fila e versão de PHP. Esse calendário é independente do calendário do Magento, e a Adobe não fornece correção de segurança nem de qualidade para dependência de terceiro que chegue ao fim de vida durante o período de suporte.
- Leve a conversa para a diretoria antes que ela chegue por outro caminho. Decisão de modelo operacional envolve orçamento de mais de um ano e não se resolve no nível técnico. Um documento curto, com a edição atual, o calendário de dependências e as duas rotas possíveis, é mais útil que uma apresentação sobre plataforma.
Se você está no Adobe Commerce on Cloud, verifique a sua data de enforcement agora, e não em 2027. O trabalho de dependência tem data em outubro de 2026, e a janela útil para executá-lo sem colidir com a temporada de alto volume é curta.
Como a Trezo pode ajudar
A Trezo trabalha só com Magento e Adobe Commerce desde 2009. Somos Adobe Solution Partner e AWS Partner, com certificação ISO 27001, e monitoramos as lojas dos nossos clientes 24 horas por dia, 7 dias por semana. Em sustentação e em upgrades, ajudamos a manter a cadência de patches e de dependências que o modelo escolhido exige.
Se essa conversa está em aberto na sua operação, fale com nossos especialistas.
Perguntas frequentes
É a oferta SaaS da Adobe: uma plataforma de comércio multi-inquilino, totalmente gerenciada e sem versão visível, em que a Adobe aplica as atualizações. Por ser versionless, ela fica fora da política de upgrade obrigatório que vale para o Adobe Commerce on Cloud.
A política de enforcement da Adobe se aplica a ambientes Adobe Commerce on Cloud (PaaS). O Magento Open Source em infraestrutura própria não está nesse escopo. Em contrapartida, a manutenção de patches e de dependências é responsabilidade sua ou do seu parceiro.
A Adobe pode suspender o acesso ao admin, suspender o tráfego de entrada (a vitrine sai do ar) e, se a situação persistir, encerrar o serviço e desativar o ambiente, o que apaga os dados de forma permanente.
Para as linhas 2.4.4 e 2.4.5, 1º de junho de 2027. Para as linhas 2.4.6 e 2.4.7, 1º de junho de 2028. As linhas 2.4.8 e 2.4.9 não têm exigência de upgrade por enquanto, segundo a página da Adobe.
MariaDB/Galera 10.5 ou anterior, Elasticsearch em qualquer versão (a troca é por OpenSearch) e RabbitMQ 3.9 ou anterior. PHP, Redis e outras faixas de versão têm prazo em 31 de maio de 2027.
Faz sentido quando a operação não tem sustentação estruturada, quando manter patches e infraestrutura por conta própria custa mais do que a licença, ou quando funcionalidades exclusivas do Adobe Commerce são requisito de negócio. Não faz sentido só por receio de fim de suporte, porque esse receio se resolve com sustentação. É uma decisão de modelo operacional, e pede uma análise de custo total em um horizonte de três a cinco anos.
Não. Segundo a política de ciclo de vida da Adobe, ela não fornece correções de segurança nem de qualidade para dependências de terceiros, como PHP e MySQL, que chegam ao fim de vida durante o período de suporte. Manter as dependências em versões suportadas é responsabilidade do cliente.
