Neste artigo
Integrar sistemas que não conversam custa entre R$ 8 mil e R$ 80 mil, e quase toda a variação vem do lado que você não controla. Se o outro sistema oferece uma interface documentada e estável, o trabalho é previsível e fica na faixa de baixo. Se ele só exporta arquivo ou exige acesso direto ao banco, o risco sobe e o prazo deixa de ser estimável com honestidade.
Este texto compara os quatro caminhos possíveis de integração, com faixa de custo e o modo típico de falha de cada um. A escolha entre eles raramente é livre, porque ela é imposta pelo que o sistema de destino oferece. Descobrir isso antes de orçar é o que separa uma proposta honesta de uma renegociação constrangedora no meio do projeto.
Quais são os quatro caminhos de integração?
Os quatro caminhos abaixo estão em ordem de preferência técnica, e descer uma linha significa aceitar mais fragilidade permanente. A ordem não é questão de gosto, é consequência de quanto cada abordagem depende de coisas que podem mudar sem aviso. Interface oficial muda com versionamento e aviso prévio na maioria dos fornecedores sérios. Automação de tela muda quando alguém reposiciona um botão numa terça-feira qualquer.
| Caminho | Faixa de custo | Quando é possível | Risco principal |
|---|---|---|---|
| Interface oficial documentada | R$ 8k a R$ 25k | O fornecedor expõe e mantém | Mudança de versão sem aviso |
| Troca de arquivo agendada | R$ 10k a R$ 35k | Só existe exportação e importação | Dado desatualizado entre as rodadas |
| Leitura direta no banco | R$ 15k a R$ 50k | Você tem acesso e permissão formal | Quebra a cada atualização do sistema |
| Automação de tela | R$ 20k a R$ 80k | Último recurso, sem outra porta | Quebra quando a interface muda |
| Fonte: faixas praticadas em projetos de integração que entreguei, apurado em setembro de 2026. | |||
A leitura direta no banco de outro sistema merece um aviso à parte, porque parece barata e raramente é. O fornecedor não garante estabilidade da estrutura interna, já que ela não faz parte do contrato com você. Uma atualização de rotina reorganiza tabelas e derruba a integração sem que ninguém tenha errado. Além disso, gravar direto no banco de terceiro contorna as validações da aplicação e corrompe dado de formas difíceis de rastrear.
Por que a automação de tela sai mais cara no fim?
Porque ela não é integração de verdade, é imitação de uma pessoa usando o sistema pela interface visual. Funciona bem no dia da entrega e quebra na primeira vez que alguém do outro lado mexe num campo. O custo real dela não está na construção, está na manutenção permanente que ela cria. Cada atualização do sistema de destino vira um chamado de conserto no seu.
Ainda assim ela é a resposta certa quando não existe outra porta e o processo manual custa mais caro que o conserto ocasional. Sistema legado sem interface e sem acesso ao banco deixa poucas alternativas honestas. O importante é contratar isso sabendo o que está sendo contratado, com orçamento de manutenção explícito. Vender automação de tela como integração definitiva é o que gera frustração depois. A comparação completa está em RPA ou integração de sistemas.
O que perguntar antes de fechar preço?
São quatro perguntas, e as respostas mudam o orçamento em várias vezes para cima ou para baixo. Fechar preço sem elas significa aceitar um risco que ninguém mediu, geralmente o fornecedor. Nenhuma delas exige conhecimento técnico profundo para ser feita por quem contrata. Todas podem ser respondidas em uma conversa curta com quem administra o sistema de destino.
Existe documentação da interface e ela está atualizada? Documentação desatualizada é quase equivalente a documentação ausente, porque alguém vai descobrir a diferença testando e cobrando por isso. Pedir um exemplo real de chamada funcionando resolve a dúvida em minutos. Fornecedor que não consegue mostrar isso está sinalizando o tamanho do trabalho.
Quem do outro lado responde quando quebrar? Integração sem contato técnico do fornecedor vira investigação às cegas, e isso consome semanas de projeto. Ter um nome e um canal definido antes de começar muda completamente o prazo de resolução. Sem isso, cada problema pequeno vira uma espera indeterminada.
Qual o volume e a frequência de verdade? Sincronizar mil registros por dia e um milhão por hora são projetos diferentes, com arquiteturas e custos diferentes. Estimativas otimistas de volume geram sistemas que funcionam no teste e travam em produção. Medir o volume real antes evita redesenhar tudo depois.
O que acontece quando a sincronização falhar? Precisa existir resposta definida para dado duplicado, dado perdido e reprocessamento de um período. Sem essa definição, o sistema corrompe silenciosamente e ninguém percebe por meses. É a pergunta que mais economiza dinheiro e a que menos costuma ser feita.
Como evitar que a integração corrompa dado?
A técnica principal é tratar cada operação como algo que pode rodar duas vezes sem causar estrago. Rede falha, processo morre no meio e a segunda tentativa é inevitável em qualquer sistema real. Na prática isso significa identificar cada registro por uma chave estável vinda do sistema de origem. Antes de gravar, o sistema confere se aquele identificador já entrou e ignora a repetição.
Junto disso entra registro detalhado de tudo que passou, com data, identificador e resultado de cada operação. Investigar divergência entre dois sistemas sem esse histórico é praticamente impossível e consome dias. O registro também permite reprocessar um período específico quando algo dá errado. Esse cuidado é o mesmo que sustenta um discovery técnico honesto, descrito em discovery técnico antes do preço.
Sincronizar em tempo real ou em lote?
Tempo real custa mais caro para construir e muito mais caro para operar, então ele precisa ser justificado por necessidade concreta. Lote agendado resolve a maioria dos casos de empresa com uma fração da complexidade. A pergunta certa é quanto tempo o dado pode ficar desatualizado sem causar prejuízo real. Se a resposta for uma hora, não existe motivo para construir sincronização instantânea.
Sincronização em lote também é mais fácil de reprocessar quando algo falha, porque a janela é bem definida. Em tempo real, uma falha de dez minutos deixa um buraco difícil de identificar depois. O arranjo intermediário que funciona bem é lote frequente, rodando a cada poucos minutos. Ele entrega quase a percepção de tempo real com a robustez operacional do lote.
Vale integrar tudo ou só o essencial?
Só o essencial, e a definição prática de essencial é aquilo que hoje alguém digita duas vezes em sistemas diferentes. Integração existe para eliminar trabalho repetido e erro de digitação, não para criar espelho perfeito entre bases. Espelho completo multiplica pontos de falha sem entregar valor proporcional. A tentação de sincronizar tudo aparece porque parece mais organizado, e organização não é o objetivo.
Começar por um fluxo único, colocar em produção e medir durante trinta dias custa uma fração do projeto completo. Esse período revela o que realmente importa e o que só parecia importar na reunião de levantamento. Quase sempre a segunda fase fica menor do que estava no plano original. Para casar essa decisão com a escolha entre comprar pronto ou mandar fazer, o comparativo está em sistema de gestão, comprar pronto ou mandar fazer. Para o desenho técnico da troca de mensagens entre sistemas, o padrão transactional outbox resolve bem o caso de entrega confiável.
