Adobe Commerce as a Cloud Service: três releases em cinco semanas, um sinal para o seu roadmap

No início de outubro, a Adobe colocou em produção a primeira release de outono do Adobe Commerce as a Cloud Service (ACCS), a sua edição totalmente SaaS. Vista isoladamente, a lista — uma API REST para as regras de preços de catálogo, carrinhos de administração isolados, um webhook de envio enriquecido — parece canalização. Mas é a terceira entrega em cinco semanas, e nenhum dos comerciantes envolvidos planeou qualquer atualização para a receber. Se está neste momento a arbitrar um orçamento de upgrade ou de replatforming, esse ritmo é uma informação mais importante do que cada funcionalidade isolada.

Cinco semanas de entregas, zero projetos de migração

O detalhe vive nas notas de release do ACCS; eis o fio condutor.

• 8 de setembro: o núcleo passa à versão 2.4.9, juntamente com uma API de sincronização de configuração entre ambientes, consultas de stock por origem em GraphQL, a ligação de uma conta PayPal distinta por site e regras de preços de carrinho programáveis no tempo.
• 22 de setembro: devoluções com anexos, visibilidade do stock por origem na loja, seleção guiada de origens para envios multi-armazém, papéis de empresa legíveis por API.
• Início de outubro: uma API REST completa para as regras de preços de catálogo (criar, pesquisar, agendar), preços personalizados nas linhas do carrinho, carrinhos de administração isolados da loja, eventos para ligar uma plataforma externa de e-mails transacionais e salvaguardas mais apertadas: reCAPTCHA nos carregamentos, bloqueio do registo de empresas por convidados, limites na API em massa.

Três leituras de arquiteto

• O B2B muda-se para o SaaS. Papéis de empresa expostos por API, moradas de empresa utilizáveis em todo o ciclo de venda, dados da empresa injetados nos webhooks de envio, controlo dos registos de empresas: release após release, as peças B2B — historicamente o argumento da versão instalada — vão aterrando do lado cloud. O ACCS já não visa apenas catálogos simples.
• Cada funcionalidade nasce com a sua API. Nada é entregue apenas para o ecrã de administração: tudo chega com o seu ponto de entrada REST ou GraphQL, o seu webhook ou o seu evento. Um exemplo eloquente: o webhook de tarifas de envio transporta agora o identificador e os atributos da empresa cliente, precisamente para que uma aplicação App Builder conceda portes grátis sem voltar a chamar o Commerce. A personalização já não vive no núcleo: escreve-se ao lado, fora do processo.
• O projeto de upgrade desaparece; o seu custo, não. Na linha instalada, o calendário oficial prevê uma versão funcional por ano, em maio, numa linha 2.4 suportada durante três anos, complementada por correções de segurança. Do lado SaaS, as funcionalidades chegam em contínuo. O orçamento de atualização não se evapora: transforma-se em vigilância das notas de release, testes automatizados dos seus percursos críticos e disciplina nas suas integrações.

Se hoje está em 2.4.x

Nada de conclusões precipitadas: a 2.4.9, lançada em maio, abre três anos de suporte, e uma plataforma instalada bem mantida continua a ser uma escolha racional — sobretudo quando as suas personalizações vivem no código do núcleo. O reflexo certo não é migrar, é instruir o processo de decisão.

• Inventarie as suas personalizações e classifique-as em duas colunas: realizável por API, webhook ou App Builder — ou a exigir código dentro do processo. Essa segunda coluna mede a sua verdadeira distância ao ACCS muito melhor do que a faturação.
• Subscreva alguém às notas de release, mesmo sem projeto SaaS: desenham a direção do produto e, portanto, a lista de personalizações que amanhã a sua equipa já não terá de manter.
• Orce o cenário SaaS em paralelo com qualquer orçamento de upgrade para 2027: uma comparação honesta inclui reformar personalizações entretanto tornadas nativas, não apenas o custo de migração.

Se já está no ACCS

O ritmo sustentado impõe higiene: ler as notas antes de cada janela de release, repetir automaticamente os percursos de compra depois de cada uma e vigiar os seus webhooks e quotas — os novos limites da API em massa e o reCAPTCHA nos carregamentos mostram que a Adobe está também a apertar as salvaguardas em produção.

A verdadeira pergunta de 2026 já não é cloud ou on-premise: é se o seu negócio cabe em APIs. Três releases em cinco semanas acabaram de a tornar muito concreta.