Migração de plataforma não falha por tecnologia. Falha por contexto

A maioria das migrações de plataforma de e-commerce não falha por tecnologia.

Falha na integração. Mas não da forma que as pessoas imaginam.

O problema raramente é a complexidade técnica de conectar dois sistemas. Protocolos, filas, APIs e mapeamentos de dados são problemas conhecidos, com soluções conhecidas. O problema é o conhecimento sobre como o sistema legado realmente se comporta. E esse conhecimento, quase sempre, mora na cabeça de uma ou duas pessoas, e não na documentação.

O padrão que se repete

A nova plataforma está pronta e testada. A integração com o ERP está “documentada”. O cronograma diz que a próxima etapa é conectar os dois.

É nesse momento que aparecem os comportamentos que a documentação não capturou:

• o caso de borda em que um pedido com determinado meio de pagamento segue por outro fluxo;
• a exceção fiscal que alguém tratou direto no código;
• o fluxo alternativo que foi implementado anos atrás, por alguém que hoje trabalha em outra empresa, para resolver um problema que ninguém lembra mais qual era.

É aqui que o projeto trava. Não por falta de competência técnica. Por falta de contexto, que é muito mais difícil de recuperar do que parece.

Por que contexto some

Sistemas de e-commerce acumulam decisões. Cada campanha, cada exigência fiscal, cada parceiro novo deixa uma camada. Algumas viram documentação. A maioria vira comportamento: está no código, na configuração, numa rotina agendada, na planilha de alguém.

Enquanto o sistema funciona, ninguém precisa entender por que ele funciona assim. O conhecimento fica latente, e a organização nem percebe que depende dele.

A migração é o momento em que esse conhecimento latente precisa virar explícito, de uma vez só, sob pressão de prazo. E é justamente quando se descobre que quem sabia já saiu, ou está alocado em outra frente, ou lembra só metade.

O que separa a migração que entrega da que atrasa

Não é a plataforma escolhida. É o processo de captura de conhecimento antes que ele saia pela porta com quem o tem.

Na prática, isso significa algumas coisas pouco glamourosas:

Mapear comportamento, não só interface. A documentação de integração diz quais campos trafegam. O que importa é saber o que acontece em cada caso: o pedido cancelado depois de faturado, a troca parcial, o item sem estoque depois da confirmação.

Identificar quem sabe, cedo. Toda integração crítica tem um “dono do contexto”. Descobrir quem é, e garantir tempo dessa pessoa no projeto, vale mais do que qualquer ferramenta.

Tratar exceção como requisito. O caminho feliz quase nunca derruba migração. O que derruba é a exceção que ninguém listou porque “sempre funcionou”.

Testar com dado real, o quanto antes. Dado sintético passa em qualquer teste. Dado de produção carrega os casos que ninguém lembrou de descrever.

Documentação é apólice de seguro

Há uma tendência a tratar documentação de integração como entregável burocrático, algo que se faz no fim, se sobrar tempo.

É o contrário. Documentação de integração é apólice de seguro: prêmio baixo, indenização alta. Custa pouco escrever enquanto o conhecimento está disponível. Custa muito caro reconstruir quando ele já saiu da empresa, no meio da migração, com a data de virada marcada.

Na sua última migração, o que travou foi a tecnologia, ou o contexto que ninguém tinha documentado?