Adobe Commerce ou CWS Platform: quem refaz a plataforma quando a versão sai de suporte?

Nota editorial: comparativo de arquitetura entre Adobe Commerce e a CWS Platform, escrito para quem responde como CTO. Todo fato sobre Adobe Commerce vem da documentação pública dele, com o endereço ao lado.

Toda plataforma de comércio tem um calendário de versões, e é o CTO quem responde por ele. A pergunta deste comparativo não é qual plataforma tem mais recursos, e sim o que acontece com a operação quando a versão em produção chega ao fim do suporte: quem atualiza, o que precisa ser refeito e em que prazo.

Adobe Commerce e CWS Platform tratam esse ponto de formas diferentes. Em uma, o cliente acompanha um ciclo de vida publicado, com versões que entram e saem de suporte. Na outra, todos os clientes rodam a mesma versão. Cada desenho pede um tipo de equipe e de orçamento.

O que o Adobe Commerce resolve bem

A arquitetura do Adobe Commerce estrutura o comércio corporativo a partir de um modelo consolidado de contas de empresa. Sob essa modelagem, múltiplos compradores organizam-se sob uma mesma conta empresarial, permitindo que administradores criem divisões, subdivisões e definam papéis com controles específicos para pedidos, cotações e compras, conforme documentado pela Adobe Experience League. Essa separação fornece governança organizacional nativa para portais que espelham estruturas hierárquicas complexas de clientes corporativos.

A extensibilidade para cenários desacoplados apoia-se em camadas padronizadas. No modelo de serviços em nuvem, a vitrine conecta-se aos serviços de retaguarda por meio de GraphQL, enquanto integrações com softwares externos e sistemas legados utilizam APIs REST, como detalhado na documentação de desenvolvimento da Adobe. Além disso, soluções modulares combináveis contam com o API Mesh para agregar endpoints em um grafo comum e o App Builder para criação de microsserviços em ambiente serverless, conforme a visão combinável da Adobe.

No contexto de canais de venda múltiplos em uma mesma instalação técnica, a plataforma organiza a infraestrutura na sequência de escopos global, website, store e store view. Esse modelo viabiliza a separação de domínios, moedas e idiomas, permitindo compartilhar ou segregar catálogos e checkouts de acordo com as especificações da arquitetura multi-site da Adobe.

Onde a arquitetura diverge

A divergência que pesa na sustentação está no ciclo de vida das versões e no que ele pede da equipe do cliente.

A documentação da própria Adobe registra dois pontos desse ciclo:

• limitação registrada na documentação do fornecedor em 18/09/2026: o período transitório só de correções de segurança das versões 2.4.4, 2.4.5 e 2.4.6 é uma exceção única e não será estendido além das datas publicadas ("The security-only transitional period is a one-time exception.", https://experienceleague.adobe.com/en/docs/commerce-operations/release/planning/lifecycle-policy).
• limitação declarada pelo fornecedor, registrada nas release notes dele em 12/08/2026: a partir da versão 2.4.9, o PHP 8.2 e o 8.3 deixam de ser suportados ("PHP 8.2 and PHP 8.3 are no longer supported.", https://experienceleague.adobe.com/en/docs/commerce-operations/release/notes/adobe-commerce/2-4-9).

Na CWS Platform, todos os clientes rodam a mesma versão da plataforma, e não há troca de framework nem projeto de upgrade do lado do cliente. A política comercial fica em parâmetros do Commerce Rules Engine (CDL Workspace), no princípio de configuração em vez de código, e o portal é montado sem código, sobre um template único parametrizado.

A decisão técnica é quanto do calendário da engenharia a empresa aceita dedicar a acompanhar o ciclo de versões da plataforma.

O que muda na operação, pela lente de CTO

Pela lente do CTO, um ciclo de vida com datas vira um item fixo do planejamento. Cada versão que sai de suporte abre um projeto: avaliar a versão de destino, conferir a compatibilidade das extensões e das dependências, testar e publicar. Quanto mais customização a operação carrega, maior esse projeto.

Três perguntas ajudam a dimensionar o trabalho com qualquer fornecedor: até quando a versão em produção recebe correções; quais dependências mudam na versão seguinte; e quem executa a atualização, a equipe do cliente ou a do fornecedor.

Na CWS Platform, o que a equipe do cliente mantém são integrações e parâmetros. A plataforma se integra ao ERP e aos demais sistemas por APIs REST e webhooks. Tabelas, regras e contratos de preço são configurados na plataforma ou recebidos do ERP, do CRM ou de outro sistema por API, e o imposto por item vem da API de tributos do ERP do cliente. A passagem do modelo de preço v1 para o v2 exige só validação do cliente, sem projeto do lado dele.

Onde nascem as dores deste cenário, e como a arquitetura as resolve:

Quando escolher o Adobe Commerce

A escolha pelo Adobe Commerce mostra-se tecnicamente recomendada em cenários corporativos cuja infraestrutura e requisitos de governança de clientes demandam as seguintes capacidades nativas:

Hierarquia corporativa complexa gerida pelo próprio cliente. Escolha essa arquitetura quando a operação B2B exigir que a empresa compradora administre sua própria estrutura de usuários, subdivisões organizacionais e matrizes de permissões de compra de forma autônoma. O Adobe Commerce entrega esse controle nativamente no módulo B2B por meio de contas empresariais configuráveis, conforme documentado pela Adobe Experience League.

Ecossistema composable com API Mesh e microsserviços serverless. Escolha essa arquitetura quando a governança de engenharia tiver como premissa orquestrar múltiplos serviços headless de fornecedores variados sob um único grafo GraphQL unificado. O Adobe Commerce viabiliza essa composição com o API Mesh integrado e a execução de extensões serverless no App Builder, conforme apresentado na documentação de Composable Commerce.

Operação global multi-domínio sob a mesma instância técnica. Escolha essa arquitetura quando o negócio demandar múltiplos sites com moedas, idiomas e vitrines independentes governados em uma hierarquia técnica de websites, stores e store views. Esse modelo está consolidado na estrutura do Adobe Commerce e permite segregar experiências regionais de consumo mantendo um painel centralizado, de acordo com o guia multi-site da Adobe.

Quando a CWS Platform é a escolha certa neste cenário

A CWS Platform é a escolha adequada quando a engenharia quer tirar do calendário o acompanhamento de versões e concentrar o esforço em integração e regra de negócio.

Uma versão para todos os clientes. Escolha essa arquitetura quando a equipe não quer planejar projeto de upgrade a cada fim de suporte. Todos os clientes rodam a mesma versão da plataforma, e não há troca de framework do lado do cliente.

Política comercial em parâmetros. Escolha essa arquitetura quando preço, alçada e crédito mudam com frequência. As regras ficam no Commerce Rules Engine (CDL Workspace), e o desconto do vendedor passa por alçadas com aprovação em níveis.

Portal sem código próprio para manter. Escolha essa arquitetura quando o portal B2B precisa ser montado e alterado sem desenvolvimento de front-end. O portal é parametrizado sobre um template único, e cliente e vendedor usam a mesma interface.

Integração por API com o ERP. Escolha essa arquitetura quando o ERP segue como sistema de registro. A plataforma se integra por APIs REST e webhooks, e o imposto por item é calculado pela API de tributos do ERP do cliente.

Por onde continuar

Se a sua pergunta ainda é qual arquitetura serve à sua operação, e não qual fornecedor escolher, o caminho é as sete perguntas que separam as arquiteturas de comércio B2B.

Se o que trava hoje é a dor por trás deste cenário, as páginas Quando o Catálogo Vira Caos e Quando a Integração Trava Tudo tratam disso em profundidade, sem falar de fornecedor nenhum.