Trocar a asa de um avião em pleno voo parece absurdo, e é exatamente essa a tarefa de quem precisa modernizar o ERP que mantém uma rede de varejo no ar. O sistema que calcula imposto, baixa estoque e fecha o caixa não pode desligar nem por uma hora de pico, porque a loja não para. A boa notícia é que a engenharia de software resolveu esse problema com um padrão de nome curioso, o Strangler Fig, e ele descreve com precisão como trocar a asa sem o avião cair.
A tese contraintuitiva vem antes de qualquer ferramenta. Reescrever o ERP do zero, em uma virada de chave, é o caminho mais arriscado, não o mais seguro. Estudos de mercado apontam que parcela relevante dos projetos de substituição completa de ERP estoura prazo, custo ou termina cancelada (Deloitte, levantamento sobre falhas em ERP, 2018, a validar). O risco mora na ambição da virada única. O Strangler Fig troca a virada por uma migração contínua, e é essa continuidade que protege a operação.
O que é o padrão Strangler Fig e por que ele cabe no varejo?
Strangler Fig é um padrão de modernização que encapsula o sistema legado atrás de uma camada de roteamento e substitui suas funções aos poucos, sem desligá-lo. O nome veio de uma figueira tropical que cresce em volta de outra árvore e a substitui devagar, sem um momento único de troca (Fowler, 2004). No varejo, isso significa que o caixa continua emitindo nota enquanto, por trás, um módulo novo assume uma função de cada vez.
A metáfora da asa explica o desenho. Você não desliga o avião para trocar a asa. Você monta a asa nova ao lado, transfere a sustentação pouco a pouco e só remove a antiga quando a nova já segura o peso. No ERP, a asa nova é um conjunto de serviços modernos; a sustentação que migra é cada fluxo de negócio; e o piloto que decide o ritmo é a camada de roteamento. Enquanto a transferência acontece, o avião voa. A loja vende.
O contexto brasileiro torna a metáfora literal. O ERP de varejo no país concentra a regra fiscal, e essa regra muda com frequência: a Nota Técnica 2025.002 já adequou o leiaute de NF-e e NFC-e para os campos de IBS e CBS da Reforma, com cálculo na nota a partir de agosto de 2026 (Portal NF-e, 2025). Um sistema preso ao modelo antigo precisa acompanhar a reforma e modernizar a arquitetura ao mesmo tempo. Desligar para reescrever, nesse cenário, é desligar no pior momento possível.
Como o API gateway vira a camada que troca a asa?
O API gateway é o ponto único de entrada que recebe toda requisição e decide para onde mandá-la, e é nele que mora a lógica de troca da asa. Um API gateway, em termos simples, é um porteiro de software: autentica quem chega, aplica limite de uso, registra o tráfego e encaminha a chamada para o destino certo (AWS Prescriptive Guidance, a validar). No Strangler Fig, esse porteiro roteia cada chamada ou para o ERP legado, ou para o serviço novo.
No começo, o gateway manda quase tudo para o legado. Uma função de baixo risco, como consulta de catálogo ou de saldo de estoque, é a primeira a apontar para um serviço novo. Conforme a confiança cresce, funções mais críticas migram: precificação, depois faturamento, depois fechamento de caixa. A ordem racional começa pelo que é mais leitura e menos transação, porque ali o erro custa menos (Microsoft Azure Architecture Center, a validar). O cliente do balcão e o do e-commerce não percebem a troca acontecendo.
| Função do ERP | Risco de migrar primeiro | Quando mover na asa |
|---|---|---|
| Consulta de catálogo e estoque | Baixo (leitura) | Primeira onda |
| Recomendação e reposição | Médio (apoio à decisão) | Segunda onda |
| Precificação e promoção | Médio a alto | Terceira onda |
| Faturamento e fiscal | Alto (transação crítica) | Onda final, sob contingência |
Fonte: AWS Prescriptive Guidance e Microsoft Azure Architecture Center sobre Strangler Fig e API gateway (a validar). O gateway também entrega três ganhos além do roteamento: um contrato estável de API, que protege PDV e marketplace de mudanças no fundo; observabilidade, porque mede latência e erro por rota; e uma porta segura para agentes de IA consumirem a operação sem tocar o legado direto.
"O padrão Strangler Fig permite migrar funcionalidades de forma incremental, substituindo gradualmente partes específicas do sistema legado, ao mesmo tempo em que o sistema antigo continua a operar até que a substituição se complete." Martin Fowler, descrição do padrão Strangler Fig Application (Fowler, 2004)
Trocar a asa em quatro ondas, sem desligar o avião
- Onda 1Encapsular o legadoO API gateway vira porta única e roteia quase tudo ao ERP antigo.
- Onda 2Migrar a leituraCatálogo, estoque e recomendação apontam para serviços novos.
- Onda 3Migrar a decisãoPrecificação e promoção mudam de asa com baixo risco.
- Onda 4Migrar a transaçãoFaturamento e fiscal por último, sob contingência.
Por que preservar o banco de dados acelera a modernização?
Preservar o banco no início evita o erro mais caro da migração, que é mexer no dado mestre e no front ao mesmo tempo. No varejo, o banco do ERP costuma ser a fonte de verdade de produto, cliente e fiscal, com anos de trilha de auditoria que a SEFAZ pode exigir. Manter esse banco como referência enquanto a asa nova cresce reduz divergência e dá tempo de validar cada serviço novo contra o dado real.
A decomposição segue domínios, não tabelas soltas. Abordagens de Domain-Driven Design sugerem recortar a operação em contextos delimitados, como Estoque, Compras, Fiscal e Financeiro, e dar a cada um seu próprio serviço (Evans, 2003). Em vez de copiar o banco inteiro, o desenho moderno publica eventos de negócio, como Pedido Criado ou Cupom Emitido, que alimentam os serviços novos sem acoplar ao banco legado. O dado mestre fica onde está, e o novo cresce ao lado, lendo eventos.
A consistência cobra cuidado. ERP de varejo tem transação que cruza muitas tabelas, com garantia forte de integridade, e externalizar uma função sem plano gera o que arquitetos chamam de consistência eventual, quando dois sistemas concordam só depois de um intervalo. Por isso a ordem de migração importa tanto quanto a tecnologia. Mover faturamento antes de estoque, sem orquestração, troca um monólito por um conjunto de serviços ainda mais frágil, o chamado monólito distribuído.
Por que não desligar o avião
Quais são os riscos reais de modernizar com a loja aberta?
O risco maior é a fase de convivência, em que o legado e o novo rodam juntos e a complexidade dobra. Durante essa fase há duas lógicas a manter, dado a sincronizar e bug que atravessa a fronteira entre os dois mundos. Mal conduzida, a migração entrega um sistema mais frágil que o monólito original (Fowler, 2004). A disciplina de roteamento e a governança de arquitetura são o que separam o ganho do desastre.
O segundo risco é organizacional. Em muitas casas de software, a equipe que cuida do legado e a que constrói o novo vivem separadas, com prioridades distintas, e a urgência do legado consome o tempo da migração. Sem um acordo de governança que proteja a capacidade do time novo, a asa nova nunca termina de crescer. O Strangler Fig é tanto um padrão técnico quanto um acordo de gestão sobre onde o esforço vai.
O terceiro risco é confundir modernização com enfeite. A leitura sóbria do mercado pesa aqui: a Gartner projeta que mais de 40% dos projetos de IA agêntica sejam cancelados até o fim de 2027, em geral por falta de valor claro e de governança (Gartner, projeção 2027). Modernizar o ERP para habilitar front web, mobile e IA só compensa se cada onda entregar valor mensurável, como uma função que antes travava e passou a fluir. Migrar por moda repete o erro da reescrita, só que mais devagar.
O que a modernização destrava no front e na IA?
A asa nova destrava o que o monólito segurava: front web e mobile responsivos, e a porta para a IA embarcada. Com a operação exposta como API limpa pelo gateway, o mesmo estoque que abastece o ERP passa a abastecer um PDV Web, um app de vendedor e um agente de IA, sem reescrever o fundo. A reposição preditiva, por exemplo, lê o giro pela API e devolve a sugestão ao comprador, tema que detalhamos em reposição preditiva.
A IA exige um pré-requisito que a modernização entrega de graça. O agente de IA só age bem sobre dado estruturado e regra formalizada, e é exatamente isso que a decomposição por domínio produz. Quem moderniza com Strangler Fig termina com a operação legível por máquina, base que vale hoje em conversão humana e amanhã em prontidão para o agente de compra, como tratamos em backend legível por máquina.
O efeito de margem aparece na continuidade. Cada onda de migração reduz o custo de manter hardware e código antigo, e libera o time para evoluir produto em vez de apagar incêndio. A asa nova não chega pronta; ela cresce enquanto o avião voa, e cada função migrada é uma venda que não parou. Para o passo de decisão de quem ainda opera sistema antigo, veja trocar o ERP legado sem parar.
Dá para modernizar seu ERP sem big bang?
O padrão Strangler Fig (Fowler, 2004) substitui o legado função por função, atrás de um gateway de roteamento. Quatro perguntas para saber por onde começar.
Você consegue colocar um gateway/roteamento na frente do ERP atual?
Dá para migrar uma função (ex.: fiscal) sem mexer no resto?
Você tem contrato/observabilidade entre os módulos?
O legado consegue conviver com o novo durante meses?
Contexto e transparência
A Onclick (ONCLICK SISTEMAS DE INFORMAÇÃO LTDA., fundada em 1999, em Marília-SP) integra o portfólio da Nuvini (Nasdaq: NVNI). Em 10 de junho de 2026, a Nuvini comunicou que se aproxima do fechamento da aquisição de 51% da operação americana da Beyondsoft, em um negócio que forma uma plataforma de tecnologia com cerca de US$ 148 milhões de receita pro forma e mais de 22 mil clientes em 15 países (fonte pública: GlobeNewswire, 10 de junho de 2026). Os planos de produto aqui descritos refletem capacidades de mercado e a tese de retaguarda da Onclick; a empresa não autoriza promessas de funcionalidade não divulgadas publicamente, e este conteúdo separa fato público de inferência editorial.