Manter uma loja no Adobe Commerce Cloud custa caro. Não é só a licença anual, calculada sobre o GMV (o volume bruto de vendas) e sobre o faturamento do seu negócio: é o pacote fechado de hospedagem gerenciada, a taxa que cresce junto com o seu sucesso e uma série de recursos enterprise que muitas lojas pagam, mas nunca usam. Para quem começou a operar quando a promessa do PaaS parecia irresistível, a conta de renovação costuma chegar como um choque.

A boa notícia é que existe um caminho legítimo, testado e reversível para reduzir drasticamente esse custo sem trocar de plataforma na prática: migrar do Adobe Commerce Cloud para o Magento Open Source, rodando em infraestrutura própria na AWS ou em contêineres Docker que você controla. Antes de avançar, vale esclarecer um ponto que confunde muita gente: Magento 2 e Adobe Commerce são a mesma base de código. O que a Adobe vende sob a marca "Commerce" é o Magento com módulos enterprise adicionados, mais a camada Cloud de hospedagem. O núcleo — o mesmo que você usa hoje — é aberto e gratuito.

Neste guia, vou detalhar exatamente onde está o dinheiro que você paga, o que dá para eliminar sem prejudicar a operação, como montar a nova infraestrutura e qual é o roteiro seguro de migração. É o tipo de projeto que a Inventando Sites executa desde 2004, quando o e-commerce brasileiro ainda engatinhava, e que hoje representa uma das economias mais expressivas que uma loja de médio e grande porte pode conquistar em um único movimento.

Entenda o que você realmente paga no Adobe Commerce Cloud

Antes de cortar custo, é preciso enxergar a fatura com clareza. O modelo do Adobe Commerce Cloud reúne pelo menos quatro camadas de cobrança, e cada uma tem uma natureza diferente.

A licença calculada sobre o seu faturamento

A licença do Adobe Commerce não é um valor fixo de assinatura como um SaaS qualquer. Ela é dimensionada em faixas de GMV e de receita anual. Ou seja, quanto mais a sua loja vende, mais cara fica a licença — mesmo que o custo de servir cada pedido adicional para a Adobe seja praticamente zero. Esse é o ponto mais desconfortável do modelo: você é penalizado por crescer. Uma loja que dobra o faturamento pode ver a renovação subir para a faixa seguinte e sentir a margem encolher justamente no momento de expansão.

A camada Cloud de hospedagem gerenciada

O "Cloud" no nome não é só marketing. A Adobe entrega a infraestrutura como serviço: servidores, cache, CDN Fastly, banco de dados e ferramentas de deploy empacotados. É conveniente, mas você paga um prêmio considerável por essa conveniência, e perde flexibilidade — não escolhe livremente o tamanho das máquinas, não otimiza como quiser e fica preso ao pipeline de deploy da própria Adobe.

Recursos enterprise que talvez você nem use

O Adobe Commerce inclui módulos como B2B avançado, segmentação de clientes, regras de conteúdo dinâmico, staging de conteúdo, gestão de crédito para clientes e integração nativa com outros produtos da Adobe. São ferramentas poderosas — para quem precisa delas. Uma parcela enorme das lojas paga por esse arsenal e opera, no dia a dia, com um conjunto de funcionalidades que o Magento Open Source cobre integralmente ou que resolve com extensões pontuais e muito mais baratas.

O custo de oportunidade da dependência

Há ainda um custo invisível: a falta de controle. Cada ajuste de infraestrutura passa pelo suporte da Adobe, cada janela de manutenção obedece ao calendário deles, e cada integração precisa respeitar as restrições do ambiente Cloud. Para times técnicos maduros, isso é fricção pura.

Magento Open Source: o que muda e o que permanece igual

Aqui está o ponto que tranquiliza a maioria dos gestores quando explicamos o projeto: a experiência da sua loja, para o cliente final, não muda em nada. O catálogo, o checkout, as regras de preço, o tema, os pedidos, o histórico — tudo permanece. O que muda é a camada por baixo e a fatura no fim do mês.

O Magento Open Source é a edição gratuita e de código aberto da mesma plataforma. Ele inclui:

  • Catálogo completo com produtos simples, configuráveis, agrupados, virtuais e bundle
  • Carrinho e checkout nativos, com suporte a múltiplos meios de pagamento
  • Gestão de pedidos, faturas, remessas e devoluções
  • Regras de preço de carrinho e de catálogo (promoções e descontos)
  • Multi-loja e multi-idioma na mesma instalação
  • Gestão de estoque com o Multi-Source Inventory (MSI)
  • Toda a API REST e GraphQL, idêntica à edição Commerce

O que fica de fora são os módulos exclusivamente enterprise. Na prática, a diferença relevante para a maioria das operações se resume a alguns pontos: o B2B nativo, a busca com o Adobe Live Search/Sensei, a segmentação avançada de clientes e o staging de conteúdo. E cada um deles tem substituto: Elasticsearch ou OpenSearch com módulos de busca resolvem a pesquisa; extensões de mercado cobrem B2B; e a maioria das lojas simplesmente não usa staging de conteúdo com a frequência que justifique o custo.

Se a sua operação depende genuinamente de recursos B2B pesados, vale conhecer nossa abordagem específica para lojas B2B e integrações complexas dentro de projetos Magento, porque em alguns casos a recomendação honesta é permanecer no Commerce — e nós dizemos isso com clareza quando é verdade.

Onde está a economia real

Vamos aos números conceituais. A economia de sair do Adobe Commerce Cloud vem de três frentes que se somam.

1. Eliminação da licença

Essa é a mais óbvia e a mais expressiva. A licença do Adobe Commerce some por completo — o Magento Open Source não cobra nada por uso, faturamento ou GMV. Você pode dobrar ou triplicar as vendas sem que um único centavo da sua margem seja consumido por uma taxa de licença.

2. Infraestrutura sob medida

No Cloud, você paga por um pacote dimensionado pela Adobe. Em infraestrutura própria — seja AWS, Google Cloud ou um provedor com boa relação custo-benefício — você paga exatamente pelo que usa e otimiza continuamente. Contêineres Docker permitem empacotar a aplicação de forma enxuta, e o autoescalonamento garante que você só pague por capacidade extra nos picos reais, como Black Friday, voltando ao patamar normal depois.

3. Limpeza de dependências e módulos enterprise

Toda migração séria é também uma faxina. Ao sair do Commerce, revisamos cada módulo instalado, cada dependência do composer.json, cada extensão de terceiros paga. É comum encontrar módulos enterprise ativos que ninguém usa, extensões duplicadas e assinaturas de serviços que podem ser substituídas por alternativas open source. Essa limpeza, além de reduzir custo direto de licenças de terceiros, deixa a aplicação mais leve e rápida.

Como montar a infraestrutura própria (AWS e Docker)

A parte que mais assusta os gestores é a infraestrutura. "Se a Adobe cuidava disso, quem vai cuidar agora?" A resposta é: uma arquitetura bem desenhada, automatizada e monitorada — que na verdade oferece mais controle e previsibilidade do que o Cloud. Veja os componentes essenciais de uma stack Magento Open Source em produção.

Aplicação em contêineres Docker

O coração da operação é a aplicação Magento empacotada em contêineres Docker. Isso significa PHP-FPM na versão suportada, Nginx como servidor web, e a base de código versionada. A conteinerização garante que o ambiente de desenvolvimento, de homologação e de produção sejam idênticos — o famoso "funciona na minha máquina" deixa de existir. E o deploy passa a ser reprodutível, com rollback em segundos se algo der errado.

Banco de dados gerenciado

O MySQL (ou MariaDB) pode rodar em um serviço gerenciado como o Amazon RDS, que cuida de backups automáticos, réplicas de leitura e failover. Você tem a robustez de um banco gerenciado sem o preço embutido do pacote Cloud da Adobe.

Cache e sessões com Redis

O Magento usa Redis para cache e sessões. Um serviço gerenciado como o Amazon ElastiCache, ou um contêiner Redis dedicado, mantém a performance alta. É aqui que boa parte da velocidade percebida pelo cliente é construída.

Busca com OpenSearch ou Elasticsearch

A busca do Magento depende de um motor de indexação. O OpenSearch (fork open source do Elasticsearch, disponível como serviço gerenciado na AWS) entrega a mesma qualidade de busca por catálogo, filtros por camadas e sugestões — sem a dependência do Live Search enterprise.

CDN e cache de borda

No Cloud, a Adobe entrega o Fastly. Em infraestrutura própria, você usa Cloudflare, Amazon CloudFront ou o próprio Fastly contratado diretamente, geralmente por um custo menor e com regras de cache totalmente sob seu controle. Combinado com o Full Page Cache do Magento (idealmente com Varnish), o resultado é um site rápido e resiliente.

Automação de deploy e monitoramento

O diferencial de uma operação madura está na automação. Pipelines de CI/CD para build e deploy, monitoramento com alertas (uso de CPU, memória, tempo de resposta, filas), logs centralizados e backups testados. Esse é exatamente o tipo de operação contínua que estruturamos no nosso serviço de outsourcing de TI e sustentação de e-commerce, para que a sua equipe não precise virar especialista em infraestrutura da noite para o dia.

Tabela comparativa: Cloud x infraestrutura própria

Componente Adobe Commerce Cloud Magento Open Source próprio
Licença Percentual sobre GMV/receita Zero
Hospedagem Pacote fechado da Adobe AWS/Docker sob medida
CDN Fastly incluído (preço embutido) Cloudflare/CloudFront/Fastly direto
Banco de dados Gerenciado pela Adobe RDS ou contêiner sob seu controle
Busca Live Search enterprise OpenSearch/Elasticsearch
Deploy Pipeline da Adobe CI/CD próprio, rollback rápido
Escalabilidade Dentro do plano contratado Autoescala real por demanda
Controle Limitado pelo suporte Total

O roteiro de migração passo a passo

Migrar uma loja em produção sem quebrar vendas exige método. Este é o roteiro que seguimos, e cada etapa existe para reduzir risco.

Passo 1: Auditoria completa da loja atual

Levantamos tudo: versão do Magento, lista de módulos enterprise em uso, extensões de terceiros, customizações no código, integrações ativas (ERP, gateway de pagamento, transportadoras, marketplaces), volume de catálogo, volume de pedidos e picos de tráfego. Esse diagnóstico define o esforço real e revela o que pode ser eliminado.

Passo 2: Mapeamento de dependências enterprise

Identificamos cada funcionalidade que depende de módulos exclusivos do Commerce e decidimos, uma a uma, o destino: substituir por extensão open source, reimplementar de forma customizada, ou descontinuar porque não agrega valor. Esse é o coração da economia e o ponto que mais exige experiência para não deixar buracos funcionais.

Passo 3: Montagem do ambiente de destino

Provisionamos a nova infraestrutura em AWS/Docker, replicando a arquitetura descrita acima. Tudo é montado em paralelo, sem tocar na loja em produção. Configuramos banco, cache, busca, CDN e pipelines de deploy.

Passo 4: Migração da base de código e dos dados

Convertemos a base do Commerce para Open Source, removendo os módulos enterprise e ajustando o composer.json. Migramos o banco de dados — produtos, categorias, clientes, pedidos, avaliações, tudo. Cada integração é reconectada e testada isoladamente.

Passo 5: Homologação e testes

Rodamos a loja completa no ambiente novo com um espelho dos dados reais. Testamos checkout de ponta a ponta, todos os meios de pagamento, cálculo de frete, emissão de nota, sincronização de estoque e os fluxos administrativos. Fazemos testes de carga para validar o comportamento em pico.

Passo 6: Cutover e go-live

O corte final é planejado para a janela de menor tráfego. Congelamos alterações, fazemos a última sincronização de dados (delta), apontamos o DNS e monitoramos de perto nas primeiras horas. Como toda a infraestrutura antiga continua de pé por alguns dias, o rollback é sempre possível.

Passo 7: Estabilização e otimização

Nas semanas seguintes, ajustamos cache, otimizamos consultas, calibramos o autoescalonamento e documentamos a operação. A partir daí, a loja roda mais barata, mais rápida e sob controle total.

Se você quer um caminho ainda mais rápido para colocar uma nova loja Magento no ar em paralelo, vale conhecer o nosso Magento Express, formato acelerado de implantação, que compartilha boa parte dessa mesma engenharia de infraestrutura enxuta.

Ganhos que vão além da economia direta

Reduzir custo é o motivo que abre a conversa, mas a migração para infraestrutura própria costuma entregar benefícios que não aparecem na fatura e que, no médio prazo, valem tanto quanto a economia.

Performance sob seu controle

No Cloud, a performance é o que a Adobe entrega dentro do plano contratado. Em infraestrutura própria, você calibra cada componente: dimensiona os servidores para o seu perfil de tráfego, ajusta o Varnish e o Redis, otimiza as consultas ao banco e escolhe a CDN com as regras de cache que fazem sentido para o seu catálogo. Lojas que migram frequentemente conseguem melhorar o tempo de resposta simplesmente porque passam a poder mexer onde antes não podiam. E performance, em e-commerce, é conversão e SEO — cada segundo a menos no carregamento se traduz em mais vendas e melhor posição no Google.

Liberdade de deploy

O pipeline de deploy do Cloud é conveniente, mas rígido. Com infraestrutura própria e CI/CD sob seu controle, você decide quando e como publicar, faz deploys menores e mais frequentes, e tem rollback em segundos. Times que valorizam agilidade sentem essa diferença todos os dias. Essa autonomia é parte do que estruturamos em projetos de desenvolvimento e sustentação de loja Magento.

Fim do acoplamento com o ecossistema Adobe

Estar no Cloud cria uma dependência que vai além da técnica: cada decisão de infraestrutura passa pelo suporte e pelo calendário da Adobe. Ao migrar, você recupera a soberania sobre a própria operação — escolhe fornecedores, negocia contratos de cloud diretamente e não fica refém de um pacote único.

Segurança e conformidade sem o Cloud

Uma preocupação legítima que sempre surge: "se eu saio do Cloud, perco a segurança gerenciada?". A resposta honesta é que você troca segurança gerenciada por segurança configurada — e, feita corretamente, ela é tão robusta quanto, com a vantagem de ser transparente e sob seu controle.

Uma infraestrutura própria bem construída inclui: certificados TLS e HTTPS em tudo, um WAF (firewall de aplicação web) via Cloudflare ou AWS WAF para filtrar tráfego malicioso, segregação de rede com o banco de dados isolado do acesso público, backups automáticos e testados, gestão de segredos (senhas e chaves) fora do código, e um processo disciplinado de aplicação de patches de segurança do Magento assim que são liberados.

Sobre a LGPD: a responsabilidade pela proteção dos dados dos seus clientes é sua em qualquer cenário, Cloud ou não. Com infraestrutura própria em provedores sérios como a AWS, você tem total controle sobre onde os dados residem, quem acessa e como são protegidos — o que, para muitas empresas, é mais confortável do que depender de um pacote fechado. A disciplina de segurança contínua é justamente um dos pilares do nosso serviço de outsourcing de TI, garantindo que a loja não fique vulnerável por falta de manutenção.

O ciclo de manutenção depois da migração

Sair do Cloud significa assumir a manutenção que a Adobe fazia — e é importante encarar isso com clareza, porque é o principal receio dos gestores. A boa notícia é que essa manutenção é previsível, automatizável e muito mais barata do que a licença que você elimina.

O ciclo saudável de uma loja Magento Open Source em produção envolve: monitoramento contínuo (disponibilidade, tempo de resposta, uso de recursos e filas), aplicação regular de patches de segurança, atualizações de versão planejadas em janelas controladas, backups verificados periodicamente (backup que nunca foi testado não é backup), e otimização contínua de performance conforme o catálogo e o tráfego crescem.

Nada disso exige um time interno de DevOps. Pode ser feito com automação bem montada e uma rotina disciplinada, ou delegado integralmente a um parceiro. O ponto central é que a economia da licença cobre com folga o custo dessa sustentação, deixando saldo positivo expressivo. É por isso que a conta fecha a favor da migração na esmagadora maioria dos casos de médio e grande porte.

Riscos reais e como neutralizá-los

Nenhum projeto de migração é isento de risco, e seria desonesto dizer o contrário. Os riscos existem e são gerenciáveis.

Perda de funcionalidade enterprise. Se algum recurso é realmente essencial, ele precisa ser substituído antes do go-live, não depois. O mapeamento do Passo 2 existe justamente para isso.

Downtime no cutover. Com planejamento de janela, sincronização delta e DNS com TTL baixo, o tempo de indisponibilidade fica em minutos, muitas vezes imperceptível para o cliente.

Integrações que dependem do ambiente Cloud. Algumas integrações foram construídas assumindo particularidades do Cloud. Elas são identificadas na auditoria e adaptadas para a nova stack. Se a sua operação usa integrações pesadas com ERP e marketplaces, esse ponto merece atenção especial, e conectamos essa discussão às nossas automações e integrações com IA quando faz sentido modernizar o fluxo em vez de apenas replicá-lo.

Falta de time para operar a infraestrutura. Esse é o receio mais comum, e a resposta é sustentação contínua. Você não precisa contratar um time de DevOps interno: pode delegar a operação para quem já faz isso.

Quando NÃO migrar

Coerência exige dizer também quando o Adobe Commerce Cloud continua fazendo sentido. Se a sua loja usa intensamente o B2B nativo com contratos, orçamentos e catálogos por empresa; se depende de segmentação avançada e conteúdo dinâmico por perfil; se a governança corporativa exige o suporte formal e o SLA da Adobe; ou se o custo da licença é irrelevante diante do faturamento — então a migração pode não valer o esforço. A recomendação honesta faz parte do serviço. Nós preferimos perder um projeto a entregar uma economia que custe caro depois.

Perguntas frequentes

Magento Open Source é a mesma coisa que Adobe Commerce?

O núcleo é o mesmo código. O Adobe Commerce (antigo Magento Enterprise) é o Magento Open Source acrescido de módulos enterprise e da camada Cloud de hospedagem. Ao migrar para o Open Source, você mantém toda a base e abre mão apenas dos recursos exclusivamente enterprise — muitos dos quais têm substitutos open source.

Vou perder meus pedidos, clientes e histórico ao migrar?

Não. A migração transfere integralmente o banco de dados: produtos, categorias, clientes, pedidos, faturas, avaliações e histórico. O cliente final não percebe diferença, porque a loja continua sendo a mesma aplicação Magento.

Quanto tempo leva um projeto de migração como esse?

Depende do tamanho do catálogo, do volume de customizações e do número de integrações. Lojas de complexidade média costumam concluir em algumas semanas, incluindo auditoria, montagem de ambiente, migração, homologação e cutover. A auditoria inicial é o que define o prazo real.

Preciso ter um time de infraestrutura próprio depois da migração?

Não necessariamente. Você pode operar internamente se tiver equipe, ou delegar a sustentação para um parceiro. O modelo de outsourcing de TI cobre exatamente isso: monitoramento, atualizações, backups e resposta a incidentes, sem que você monte um time de DevOps do zero.

A economia compensa o custo do projeto de migração?

Na grande maioria dos casos de médio e grande porte, sim, e com folga. A licença do Adobe Commerce costuma ser recorrente e crescente, enquanto a migração é um investimento único. O ponto de equilíbrio geralmente acontece em poucos meses, e a partir daí a economia é permanente.

É possível voltar para o Adobe Commerce se der errado?

Durante o projeto, sim — mantemos o ambiente antigo ativo até a estabilização, o que torna o rollback viável. Depois de estabilizada a operação no Open Source, o retorno raramente é desejado, porque significaria voltar a pagar a licença que você acabou de eliminar.

Conclusão

Sair do Adobe Commerce Cloud para o Magento Open Source em infraestrutura própria não é um downgrade — é uma decisão de engenharia e de negócio que devolve o controle da sua loja e corta um custo que só cresce. Você mantém a mesma plataforma que já conhece, elimina a licença sobre o faturamento, dimensiona a infraestrutura ao que realmente usa e faz a limpeza de dependências que ninguém nunca teve tempo de fazer.

O segredo está no método: auditoria honesta, mapeamento cuidadoso do que é enterprise de verdade, ambiente novo montado em paralelo e um cutover planejado com rollback garantido. É assim que a Inventando Sites conduz esses projetos desde 2004, com a franqueza de recomendar a migração quando ela compensa — e de desaconselhá-la quando não compensa.

Se a sua renovação do Adobe Commerce está chegando e o valor não faz mais sentido, fale com a gente pelo formulário de contato. Fazemos a auditoria inicial, mostramos onde está a economia real na sua operação e desenhamos o roteiro de migração sob medida — sem prometer o que não dá para entregar.