O que duas migrações me ensinaram sobre arquitetura de software
Arquitetura de software costuma ser explicada como assunto de construção. Mas o valor que mais uso é outro: entender como uma operação que já existe vira sistema, porque é isso me permite planejar e migrar sistemas sem quebrar.
Arquitetura de software costuma ser explicada como um assunto de construção: como estruturar um sistema novo, quais camadas, quais padrões. Faz sentido, mas não é aí que ela mais me ajudou nesses anos. O valor que eu mais uso no dia a dia é outro. É entender como uma operação que já existe no mundo real vira sistema, porque é isso que permite mexer nela sem quebrar justamente por ter o conhecimento de como sistemas são feitos.
Duas experiências de migrações deixaram isso claro pra mim.
Trocar a plataforma na virada do ano
A primeira foi na virada de 2023 para 2024. Uma empresa de varejo decidiu encerrar uma loja multimarcas e concentrar tudo em uma marca só. Na prática, era sair de uma operação com 700 SKUs, um público, um layout e uma plataforma (WooCommerce) para outra com 30 SKUs, outro público e outra plataforma (Shopify). Menos loja, mais foco. Uma decisão de negócio, não técnica.
A parte técnica era manter tudo funcionando do outro lado: transportadoras, meios de pagamento, integração com o ERP. E não tem madrugada épica pra contar. O risco não era dramático, era invisível. Bastava esquecer de conectar uma transportadora, deixar um produto sem migrar ou um meio de pagamento sem parametrizar, e a operação inteira cairia no manual. Cada pedido lançado à mão, do Shopify para o ERP. Numa loja pequena talvez passasse. Num e-commerce de verdade, é o suficiente pra travar tudo no dia 2 de janeiro.
Na época eu era prestador de serviço para essa empresa. O que fez a virada acontecer no primeiro segundo do ano não foi sorte nem esforço na hora. Foi ter cada peça mapeada antes.
Migrar um ERP inteiro em 15 dias
O segundo caso foi mais apertado. Um cliente precisava sair do Simples para o Lucro Real e migrar a operação inteira para outro CNPJ, com estrutura de matriz e filial. O ERP antigo não dava conta das novas exigências fiscais, então não era "quando der": eram 15 dias, prazo imposto pela realidade tributária, não por otimismo de ninguém.
Faturamento de R$ 2 milhões por ano, dez canais de venda, transportadoras, marketplaces, estoque, picking e packing. O trabalho de verdade não foi configurar o ERP novo. Foi mapear o que já rodava. Cada processo, cada integração, como o estoque se movia, como os SKUs eram cadastrados, como cada canal conversava com o sistema. Entender tudo e reconectar do outro lado.
Deu certo, e a razão é meio sem graça de contar: deu certo porque estava mapeado. Não teve improviso de última hora porque o improviso já tinha sido resolvido antes, no papel.
O que os dois têm em comum
Olhando pros dois, o que se repete não é heroísmo. É mapeamento.
E é aqui que a arquitetura entra de um jeito que quase nunca é falado. Ela dá o vocabulário necessário pra enxergar uma operação real como sistema: quais são as entidades, como elas se relacionam, quais são os blocos e as etapas. Um pedido, um SKU, uma transportadora, um canal de venda: cada coisa do mundo real tem um lugar correspondente dentro do software. Quando você treina esse olhar, migração deixa de ser aposta. Você chega no problema real já sabendo onde ele encaixa do lado do sistema.
Por isso acho incompleta a ideia de que arquitetura serve só pra construir coisa nova. Saber como um sistema funciona por dentro, como o mundo é abstraído em modelo e como as coisas se organizam em camadas, blocos e etapas, é justamente o que te deixa mexer no que já existe com alguma segurança.
Construir do zero é a parte que todo mundo estuda. Migrar o que já está rodando, sem parar a operação, é onde esse olhar mais paga. E é a parte que quase ninguém conta.