Quando a Implementação Não Termina · 09 de outubro de 2026 · 8 min

Salesforce ou CWS Platform: quem refaz a loja quando a plataforma muda de framework?

Um comparativo pela ótica da engenharia: o que acontece com o que a equipe construiu quando a base técnica da loja muda.

Homem de cardigã verde segura uma caneca diante de uma mesa de trabalho, com um colega de costas diante de um quadro branco ao fundo.

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

Para o CTO, o custo de uma plataforma de comércio B2B não termina na implantação. Ele continua em cada ciclo de atualização: o que a equipe precisa reescrever, testar e publicar de novo para seguir em uma versão que recebe evolução. A pergunta deste comparativo é essa: quando a base técnica da loja muda, quem refaz o trabalho?

Salesforce e CWS Platform respondem de formas diferentes, e nenhuma das duas respostas é errada em si. Elas pedem equipes, calendários e orçamentos diferentes.

O que a Salesforce resolve bem

A Salesforce entrega uma estrutura consolidada para unificação de dados corporativos e gestão do ciclo de vida de clientes em escala global. No Data 360, dados de múltiplas origens entram no lakehouse e são modelados inicialmente como Data Lake Objects (DLOs), sendo posteriormente mapeados para Data Model Objects (DMOs) para aplicar regras de resolução de identidade e gerar perfis unificados. A governança dessa ingestão e consulta é controlada programaticamente, inclusive com o uso de Data 360 SQL e APIs específicas por tenant, permitindo disparar ações automatizadas via webhooks externos ou eventos de plataforma.

No ambiente transacional de compras, o B2B Commerce viabiliza a criação de portais com componentes Lightning e Experience Builder, com importação assíncrona de produtos, listas de preços e entitlements via arquivos estruturados. A solução permite gerenciar compradores por contas e grupos, delegando o processamento final a checkouts customizados construídos por provedores e integrações externas.

Para a gestão comercial e relacionamento, o ecossistema conecta o Sales Cloud para estruturação de pipelines, territórios e divisão de receitas entre equipes, enquanto o Marketing Cloud expõe interfaces REST e SOAP para orquestração de jornadas e mensagens multicanal. A camada de agentes autônomos Agentforce complementa a suíte permitindo combinar instruções em linguagem natural com rotinas condicionais programáticas em Agent Script, viabilizando testes automatizados via CLI e conexões de mensageria por endpoints REST dedicados.

Onde a arquitetura diverge

A divergência que pesa na sustentação está no que acontece com o que a sua equipe construiu quando a base técnica da loja muda.

Comparação em dois painéis: à esquerda, loja com componentes sob medida, substituídos na mudança de framework; à direita, portal parametrizado em versão única.

A própria documentação da Salesforce registra dois pontos sobre esse ciclo:

limitação registrada na documentação do fornecedor, consultada em 09/10/2026: para concluir a migração da loja para LWR, todos os componentes Aura terão de ser substituídos ("all Aura components must be replaced eventually", https://developer.salesforce.com/docs/commerce/lwr-migration/guide/prepare-for-migration.html).
limitação declarada pelo fornecedor, registrada nas release notes dele, consultadas em 09/10/2026: desde o Summer '25 o B2B Commerce para Visualforce só recebe notas de patch ("maintains only patch notes for B2B Commerce for Visualforce", https://help.salesforce.com/s/articleView?language=en_US&id=commerce.b2b_commerce_release_notes.htm&type=5).

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. O portal é montado sem código, sobre um template único parametrizado, e 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. Cliente e vendedor usam o mesmo sistema e a mesma interface, sem migração de frente de loja.

decisão	Salesforce, pelo mecanismo documentado	CWS Platform
Como a loja é construída	Portais com componentes Lightning e Experience Builder.	Portal sem código, sobre um template único parametrizado.
O que acontece na mudança de geração do front-end	A migração da loja para LWR pede a substituição de todos os componentes Aura.	Não há troca de framework do lado do cliente.
Onde a política comercial é expressa	Mapeia regras por entitlements, listas de preços e fluxos customizados integrados ao CRM.	Parâmetros no Commerce Rules Engine (CDL Workspace), alterados por configuração.
Como o fechamento do pedido é adaptado	Checkouts customizados, construídos por provedores e integrações externas.	Crédito e alçada aplicados pelas regras da plataforma no fechamento do pedido.

A decisão técnica é quanto do que a equipe constrói hoje ela aceita reconstruir quando a base da loja mudar.

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

Pela lente do CTO, a conta de sustentação tem duas partes. A primeira é o inventário do que foi customizado: componentes, fluxos e integrações que pertencem ao cliente e que ele precisa levar de uma geração para a outra. A segunda é o calendário: quando uma linha do produto passa a receber só correções, migrar deixa de ser opcional no planejamento.

Diagrama com canais de acesso convergindo para um carrinho único sobreposto à camada de regras comerciais parametrizadas.

Vale levar três perguntas a qualquer fornecedor: o que do nosso código sobrevive à próxima mudança de base técnica; quem executa a migração e em que prazo; e o que deixa de receber evolução enquanto ela não acontece.

Na CWS Platform, o que a equipe 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:

dor	por que acontece	como a arquitetura resolve
“Cada mudança na política comercial vira um projeto do integrador”	A regra de negócio tratada como extensão sob medida passa por desenvolvimento e homologação a cada alteração.	Parâmetros e alçadas são alterados por configuração no Commerce Rules Engine (CDL Workspace).
“O vendedor não vê o carrinho que o cliente está montando, e a negociação vira uma cotação paralela”	Autosserviço e CRM mantêm carrinhos separados.	Vendedor e comprador ficam no mesmo carrinho, atualizado para os dois ao recarregar a página, com as alçadas de desconto aplicadas.

Quando escolher a Salesforce

A arquitetura da Salesforce é indicada quando as demandas corporativas ultrapassam a execução estrita de comércio e exigem uma camada unificada de relacionamento e dados em nível global.

Consolidação de dados corporativos multissistema e CDP generalista. Escolha essa arquitetura quando a organização precisar unificar dados de múltiplos ecossistemas legados em um data lakehouse com resolução de identidade abrangente. O Data 360 permite mapear DLOs em modelos DMOs padronizados e executar transformações SQL em escala empresarial.

Operações com governança complexa de pipeline e múltiplos territórios globais. Escolha essa arquitetura quando a empresa exigir uma gestão profunda de força de vendas corporativa, cobrindo previsões orçamentárias de pipeline, rateio de comissões e gestão de territórios globais com múltiplas moedas. O Sales Cloud oferece estruturas nativas maduras para suportar grandes equipes comerciais distribuídas.

Desenvolvimento horizontal de agentes e orquestração de jornadas omnicanal. Escolha essa arquitetura quando o objetivo for criar fluxos conversacionais flexíveis com testes via CLI, usando Agent Script e SDKs específicos para múltiplos canais de contato. A plataforma do Agentforce e o suporte a jornadas avançadas no Marketing Cloud oferecem ferramentas extensíveis para esse nível de personalização corporativa.

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

A CWS Platform é a escolha adequada quando o objetivo é tirar do calendário da engenharia o projeto de upgrade e a manutenção de front-end próprio.

Uma versão para todos os clientes. Escolha essa arquitetura quando a equipe de engenharia não quer reservar orçamento e calendário para projeto de upgrade. Todos os clientes rodam a mesma versão da plataforma, e não há troca de framework do lado do cliente.

Loja 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.

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), o desconto do vendedor passa por alçadas com aprovação em níveis, e o limite de crédito funciona como conta corrente do cliente, concedido no CDL Workspace ou por API.

Integração por API com o que já existe. 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.