Trabalho · Guilherme Di Paula

Migração de uma operação DTC enterprise para Adobe Commerce

Trocar a plataforma de uma operação de várias marcas sem parar a venda, dentro de um programa maior de integração de sistemas.

Várias marcas · ERP (SAP), pagamento, logística, CRM · 2025–2026

Contexto

Uma operação DTC de várias marcas, rodando numa plataforma SaaS, precisava migrar para Adobe Commerce dentro de um programa maior de integração de sistemas pós-aquisição. A plataforma de destino já vinha definida pelo padrão do grupo. O trabalho não era escolher a tecnologia: era trocar o motor sem parar a venda, com catálogo, base de clientes e integrações com ERP, pagamento, logística e CRM.

A decisão difícil

No começo, gastei energia tentando reabrir a escolha da plataforma. Era a briga errada. O que ameaçava a migração era o modelo operacional: ciclos de release da integração e do frontend descasados, cadastro de produto sem dono, decisões irreversíveis passando como tarefa técnica. Mudei o foco para isso.

O que fizemos

Forçamos a decisão de contingência cedo. Os cenários possíveis para a data de virada foram à mesa executiva semanas antes, em vez de a encruzilhada aparecer na véspera, quando só sobra consequência.
Definimos critérios objetivos de aceite antes de virar, e amarramos o go live a eles, não ao calendário.
Montamos a rede de segurança antes de precisar dela: plano de virada em três blocos (antes, durante e depois), war room, 30 dias de hypercare e um canal aberto para o negócio reportar, com devolutiva para cada registro.
Fizemos um go live faseado. A loja virou numa janela de madrugada, e a conclusão só foi declarada depois que a integração com o ERP estabilizou, em setembro de 2026.

O que aprendi

Plataforma é a parte mais visível de uma migração e raramente a mais arriscada. O risco mora no modelo operacional e no conhecimento do legado que está na cabeça de poucas pessoas. E decisão irreversível pede um processo diferente: a virada sem caminho de volta ganhou outro rito, não mais pressa.

De operar na plataforma dos outros a ser dono da plataforma

Internalizar a operação de e-commerce e trocar a lógica de atender demanda pela de propor.

3 e-commerces · sustentação terceirizada → time interno · 2026

Contexto

A sustentação das plataformas de e-commerce era terceirizada. O time interno recebia demanda, repassava e cobrava prazo. A operação funcionava, mas ninguém dentro de casa tinha o mapa completo de como as plataformas se comportavam e, por isso, ninguém conseguia propor além do que já estava pedido. A transição para um time interno foi aprovada em 2026.

A decisão difícil

Internalizar, com um reforço temporário de prazo fechado, em vez de trocar um fornecedor por outro. A troca seria mais rápida e menos arriscada no curto prazo, mas manteria o mesmo modelo: operar na plataforma dos outros. A aposta foi que quem é dono, mede; quem mede, propõe.

O que fizemos

Desenhamos o handover como produto, não como evento. Documentação entregue todo dia, e não no fim, com uma amostra validada antes de replicar. Depois, acompanhamento lado a lado, reversão progressiva dos papéis e operação autônoma com o time anterior em standby, até a revogação dos acessos legados.
Nomeamos em voz alta o risco que ninguém escreve: o comportamento de quem está saindo durante a transição, com plano de mitigação como qualquer outro risco.
Criamos um fórum mensal de review de plataformas, que não é review de projeto. A abertura presta contas do que foi pedido na edição anterior antes de mostrar qualquer número novo, e cada pedido vira item de backlog com dono no negócio e prazo.
Separamos as portas de entrada: demanda nova entra pelo produto, incidente pelo suporte, e a liderança decide só a prioridade entre produtos.

O que aprendi

Ser dono muda a conversa com o negócio: o time deixa de explicar por que não deu e passa a chegar com número e proposta. Também aprendi que fórum executivo precisa de caminho assíncrono, com um resumo de uma página e a gravação, porque a agenda de quem decide nunca é garantida. E que número vem antes de adjetivo.

IA aplicada em produção, não em piloto

Ferramentas que tiram horas de trabalho da operação e transformam "otimizar para IA" em tickets com dono.

2 ferramentas em uso · campanhas e GEO

Contexto

IA em e-commerce costuma parar no piloto. A régua aqui foi outra: só conta o que entra na rotina do time e tira trabalho real da operação.

A decisão difícil

Decidir o que não automatizar. A tentação era colocar IA em cima dos processos como estavam. O caminho foi o inverso: entender o processo, simplificar e só então automatizar. Automatizar processo ruim só faz o erro acontecer mais rápido.

O que fizemos

Uma plataforma interna de campanhas, sem código. Quem monta a campanha passou a ser o próprio time de negócio, sem fila de chamado para a engenharia. A montagem caiu de 20 horas para 1 hora, e a engenharia saiu do caminho crítico para cuidar da plataforma.
Uma ferramenta de GEO que construí e que o time usa, que avalia 48 sinais de legibilidade de um e-commerce para motores de IA. Ela é determinística: o mesmo site gera o mesmo resultado, o que permite comparar mês a mês.
Diagnóstico que vira trabalho: cada achado sai como ticket com severidade, dono sugerido (desenvolvimento, conteúdo ou e-commerce) e evidência. “Otimizar para IA” deixa de ser intenção e vira backlog.

O que aprendi

O primeiro achado mudou a pergunta: o problema não era os robôs de IA conseguirem entrar no site, e sim entenderem o que encontravam. E ferramenta que vira régua precisa dizer quando não conseguiu medir. Falhar em silêncio é pior do que não medir.