Substituir sistema legado por SaaS pronto ou modernizar?

O sistema que roda a operação tem quinze, vinte anos. Foi escrito em Delphi, VB6, Access ou numa versão antiga de alguma linguagem web, o programador que o criou já não está por perto e cada ajuste demora mais do que deveria. Enquanto isso, o mercado oferece SaaS para quase tudo: gestão de obras, distribuição, clínicas, assistência técnica, transporte. Assinar um deles parece o jeito mais rápido de virar a página.

Às vezes é mesmo. Em outras, a empresa descobre meses depois da virada que o sistema antigo fazia coisas que ninguém tinha listado, e passa a compensar essas lacunas com planilhas, controles manuais e pequenos sistemas paralelos. O problema não estava no SaaS escolhido. Estava em decidir sem saber o que o legado realmente fazia.

Este texto mostra como fazer essa conta antes de assinar: o que levantar no sistema antigo, como medir a aderência de um produto de mercado e quando modernizar o legado faz mais sentido do que substituí-lo.

Resposta curta: mapeie o que o sistema antigo faz que nenhum SaaS do seu segmento faz. Se a diferença são telas antigas e processos genéricos, assinar um SaaS e migrar os dados resolve, e costuma ser o melhor caminho. Se a diferença são regras que sustentam o diferencial da operação, o SaaS vai exigir dobrar o processo ou criar sistemas satélites, e modernizar o legado (ou construir só a parte que diferencia) tende a sair melhor.

Por que o SaaS parece a saída mais simples

O argumento a favor do SaaS é forte e, em boa parte, verdadeiro:

• Alguém cuida da infraestrutura. Servidor, backup, atualização de segurança e disponibilidade passam a ser responsabilidade do fornecedor.
• O produto evolui sem projeto seu. Novas funcionalidades chegam pela própria assinatura e, nos produtos consolidados, as adequações a mudanças legais e fiscais do segmento costumam vir junto.
• Acaba a dependência de uma pessoa. Em vez de um programador que conhece o sistema de cor, há uma empresa com suporte, documentação e outros clientes usando a mesma coisa.
• Interface atual. Acesso pelo navegador, aplicativo no celular, telas que a equipe nova entende sem treinamento longo.
• Ecossistema. Muitos SaaS de segmento oferecem API e integrações prontas com ferramentas comuns de mercado.

Tudo isso é real. O ponto cego está em outro lugar: a comparação costuma ser feita entre a demonstração do SaaS, que mostra o fluxo ideal, e as dores do sistema antigo, que são visíveis. O que o legado faz bem, silenciosamente, não aparece em nenhum dos dois lados da mesa.

Inventário de regras: o que o sistema antigo faz que ninguém lembra

Um sistema que roda há anos acumula decisões de negócio dentro do código. Algumas foram pedidas por um diretor que saiu, outras nasceram de um problema com cliente, outras de uma exigência fiscal específica do seu ramo. Ninguém lista essas regras porque elas simplesmente funcionam.

O inventário é o trabalho de trazer essas regras para a superfície antes de decidir. Na prática, ele combina quatro fontes.

Conversas com quem opera

Pergunte a cada área o que o sistema faz "sozinho". As respostas costumam vir assim: "ele bloqueia o pedido se o cliente estiver com título vencido há mais de tantos dias, exceto para a rede X", "ele calcula a comissão diferente quando o produto é de linha promocional", "ele não deixa fechar a ordem de serviço sem a foto do equipamento". Cada frase dessas é uma regra.

Leitura do código e do banco

Rotinas agendadas, gatilhos no banco, procedimentos armazenados e relatórios que alimentam outras áreas raramente aparecem nas conversas. Se o sistema não tem documentação, o caminho é o mesmo de assumir um sistema legado sem documentação: acessos garantidos, cópia do código e do banco, e leitura dirigida pelas perguntas do negócio.

Exceções e casos especiais

Os campos "observação", os cadastros com nomes estranhos e os clientes tratados de forma diferente escondem regras. Um código de cliente que dispara uma tabela de preço própria é regra de negócio, mesmo que ninguém a chame assim.

Saídas que alguém consome

Liste todo arquivo, relatório, etiqueta, integração e e-mail que o sistema gera, e quem depende de cada um. Muitas vezes a contabilidade, um parceiro logístico ou um cliente grande recebem algo num formato que só o legado produz.

Classificando o que foi encontrado

Com a lista em mãos, classifique cada item em três grupos:

1. Genérico: qualquer sistema do segmento faz, talvez de outro jeito. Cadastro, emissão de documento, controle de estoque básico.
2. Costume: parece regra, mas é só o jeito que a empresa se acostumou a trabalhar. Pode mudar sem perda.
3. Diferencial: está ligado a margem, prazo, qualidade ou relacionamento com o cliente. Se mudar, o resultado muda.

Essa classificação precisa ser feita com o negócio, não só com a TI. E vale ser rigoroso no grupo "costume": parte do que parece intocável é hábito, e um SaaS bem escolhido pode até melhorar o processo.

Aderência do SaaS: o que é configuração e o que é processo dobrado

Com o inventário pronto, a avaliação do SaaS deixa de ser uma demonstração e vira um teste. Para cada regra da lista, a pergunta é: como o produto atende isso?

As respostas caem em quatro níveis:

• Atende nativamente: a funcionalidade existe e cobre o caso.
• Atende por configuração: parâmetros, campos personalizados, fluxos de aprovação ou regras que o próprio fornecedor previu. Sobrevive às atualizações e é responsabilidade de quem usa o produto.
• Atende por extensão: via API, automações ou integrações do marketplace do fornecedor. Funciona, mas cria algo que a empresa precisa manter.
• Não atende: a regra vai precisar sair do processo ou ser feita fora do produto.

Peça ao fornecedor que mostre cada regra diferencial funcionando, com dados parecidos com os seus, e confirme por escrito o que é recurso atual e o que está apenas no planejamento. Recursos de SaaS mudam com frequência, para mais e para menos, e só o fornecedor pode confirmar o que vale hoje.

Quando a regra não é atendida, sobram duas saídas. A primeira é dobrar o processo: a equipe passa a trabalhar do jeito que o produto permite. Para regras do grupo "costume", isso é ótimo. Para regras do grupo "diferencial", é abrir mão de parte do que faz o cliente escolher a sua empresa. A segunda é completar o SaaS por fora, e é aí que surgem os sistemas satélites.

Dados históricos, migração e convivência dos sistemas

Mesmo quando o SaaS atende bem, a troca tem um custo que a demonstração não mostra: os dados.

Histórico. Anos de pedidos, ordens de serviço, prontuários ou movimentações. Nem todo SaaS aceita importar histórico completo, e alguns aceitam só cadastros e saldos. Decida o que precisa ir, o que pode ficar disponível apenas para consulta num banco de arquivo e o que pode ser descartado dentro das exigências legais do seu ramo.

Qualidade. Sistemas antigos costumam ter cadastros duplicados, campos usados para fins diferentes ao longo dos anos e códigos sem padrão. A migração expõe tudo isso. Os cuidados com inventário, limpeza, de-para e conferência estão em migração de dados entre sistemas.

Convivência. Raramente dá para desligar o legado num dia e ligar o SaaS no outro. Por algumas semanas ou meses, os dois sistemas convivem, e é preciso decidir quem é a fonte da verdade de cada informação nesse período. Se o legado for um sistema de gestão central, o roteiro de troca de ERP sem parar a operação se aplica quase inteiro: data de virada, integrações provisórias, plano de retorno.

Saída futura. Antes de assinar, confirme com o fornecedor como você exporta seus dados se um dia quiser sair. Isso é parte da decisão, não um detalhe para depois.

Sistemas satélites: o custo escondido de completar o SaaS

Satélite é todo sistema, planilha ou automação criado para fazer o que o produto principal não faz. Um aplicativo para o técnico de campo registrar algo que o SaaS não prevê, uma planilha que calcula a comissão especial, um robô que copia dados de uma tela para outra, um pequeno sistema web para a aprovação que o produto não suporta.

Um ou dois satélites bem feitos, integrados pela API oficial, são uma arquitetura legítima. O problema começa quando eles se multiplicam:

• Cada satélite tem seu próprio custo de manutenção, e nenhum deles aparece no orçamento original da troca.
• A integração depende do SaaS, e mudanças no produto podem quebrar o que foi construído em volta dele.
• O conhecimento se espalha. Parte da regra está no SaaS, parte na planilha, parte no robô. Ninguém tem a visão completa.
• A dependência de pessoa volta. O satélite feito às pressas por alguém da equipe repete exatamente o problema que motivou a saída do legado.

Um sinal claro de que o SaaS não serve: o inventário mostra que as regras diferenciais precisariam de vários satélites, e eles concentrariam justamente a parte mais importante da operação. Nesse cenário, a empresa terá um sistema sob medida de qualquer forma, só que fragmentado e sem desenho.

Tabela comparativa: SaaS pronto x modernizar o legado

Nenhuma coluna ganha em todas as linhas. A tabela serve para mostrar onde está o peso da sua decisão: se as linhas que mais importam para você são as de cima, o inventário de regras decide.

Quando escolher cada caminho

Sinais de que o SaaS pronto é a melhor escolha

• O inventário encontrou poucas regras diferenciais, e o SaaS atende a maioria delas por configuração.
• O sistema antigo é, no fundo, cadastro, emissão de documentos e relatórios que qualquer produto do segmento faz.
• Boa parte do que parecia regra era costume, e a equipe aceita trabalhar do jeito do produto.
• A empresa não quer, ou não pode, manter uma equipe técnica para cuidar de software.
• O segmento tem produtos maduros, com API documentada e uma base grande de usuários.

Nesses casos, insistir no legado ou construir algo novo seria gastar onde não precisa. Assine, migre com cuidado e desligue o sistema antigo.

Sinais de que modernizar o legado faz mais sentido

• As regras que sustentam margem, prazo ou relacionamento com o cliente não cabem em nenhum produto avaliado.
• A conta de satélites passa de dois ou três, e eles cobririam a parte mais importante da operação.
• O núcleo do sistema antigo funciona bem; o problema real é a interface, a tecnologia desatualizada ou a dependência de uma pessoa.
• O próprio sistema é parte do que a empresa vende ou entrega ao cliente.

Modernizar não significa reescrever tudo de uma vez. O caminho mais seguro costuma ser a modernização gradual, trocando um módulo por vez, e a escolha entre reescrever ou refatorar um sistema legado depende do estado do código e de quanto conhecimento ainda existe sobre ele.

O meio-termo que muitas vezes vence

Em muitos casos, a resposta é dividir: o SaaS ou o ERP de mercado assume o que é genérico, e um sistema sob medida, bem desenhado e integrado pelos caminhos oficiais, fica só com o que diferencia. É a mesma lógica que usamos em ERP sob medida ou ERP de mercado: processo comum se compra, processo que é vantagem competitiva se constrói. A diferença para os satélites improvisados é que aqui a divisão é planejada, com fonte da verdade definida para cada dado.

Perguntas frequentes

O que é um sistema legado?

Sistema legado é um sistema antigo que continua sustentando a operação, mas foi construído com tecnologia desatualizada, como Delphi, VB6 ou Access, e costuma depender de poucas pessoas para manutenção. Ser legado não significa estar errado: muitos sistemas legados funcionam bem e guardam regras de negócio que nenhum produto de mercado reproduz.

Qual a diferença entre SaaS e software sob medida?

SaaS é um produto pronto, acessado pela internet mediante assinatura, que atende muitas empresas com o mesmo código e evolui conforme o roteiro do fornecedor. Software sob medida é construído para as regras de uma empresa específica e evolui conforme as prioridades dela, mas exige que alguém cuide da manutenção e da infraestrutura.

Dá para levar o histórico do sistema legado para o SaaS?

Às vezes só em parte. Nem todo SaaS aceita importar histórico completo, e alguns aceitam apenas cadastros e saldos. Antes de assinar, vale decidir o que precisa migrar, o que pode ficar disponível só para consulta num banco de arquivo e o que pode ser descartado dentro das exigências legais do seu ramo.

Quanto tempo o sistema legado e o SaaS precisam rodar juntos?

Depende do tamanho da operação e da migração. Raramente dá para desligar o sistema legado num dia e ligar o SaaS no outro; o mais comum é uma convivência de algumas semanas ou meses. Nesse período, é preciso definir qual sistema é a fonte da verdade de cada informação e manter um plano de retorno.

Como a Pervian Tech ajuda a decidir e a avaliar a troca

Nosso trabalho começa pelo inventário, não pela recomendação. Num diagnóstico inicial gratuito, levantamos com a sua equipe o que o sistema antigo faz, lemos o código e o banco quando for preciso e separamos o que é genérico, o que é costume e o que é diferencial. Com essa lista, ajudamos a testar a aderência dos produtos de mercado que você está considerando.

Se um SaaS pronto atende, recomendamos assinar e apoiamos a migração dos dados e a convivência dos sistemas. Quando ele não atende, propomos a modernização do legado ou a construção apenas da parte que diferencia, com fases claras dentro de um trabalho de arquitetura de software. Veja também como conduzimos a modernização de sistemas legados e outros textos da categoria modernização.

Cronograma e investimento são definidos sob consulta, depois de entender o contexto. Se essa decisão está na sua mesa, conte como o seu sistema funciona hoje.