Toda mudança é um projeto
O que deveria levar dias leva meses, porque ninguém sabe o que mais vai quebrar. O roadmap do produto passa a ser refém do sistema.
Transformação
A modernização de sistemas legados raramente começa como problema de tecnologia. O sistema legado é um problema de negócio que se disfarça de tecnologia: ele trava o lançamento, encarece cada mudança e concentra o conhecimento em duas ou três pessoas.
O problema
Sistema antigo que funciona não é problema. O problema começa quando ele passa a definir o que o negócio pode ou não fazer.
O que deveria levar dias leva meses, porque ninguém sabe o que mais vai quebrar. O roadmap do produto passa a ser refém do sistema.
Duas ou três pessoas entendem como aquilo funciona. Férias, saída ou aposentadoria viram risco operacional real.
Licença, infraestrutura superdimensionada e horas de especialista escasso. Você paga cada vez mais para manter tudo exatamente como está.
É o sistema que sustenta o faturamento. Qualquer proposta que envolva desligá-lo por um fim de semana está fora de discussão.
Como trabalhamos
É a mesma Escada de sempre — o que muda é o problema no primeiro degrau. Veja o método completo.
Mapeamos o que existe, o que é crítico e o que pode esperar. Nem tudo precisa ser reescrito, e o mais caro é descobrir isso depois.
Migração por partes, com o legado no ar. O novo assume função por função, com rollback possível a cada etapa.
O sistema novo operando e medido. O legado sai de cena quando não resta nada crítico nele, não antes.
Caso real · Registro de imóveis
Uma certidão de registro de imóveis é documento legal: não pode ter erro, não pode demorar e precisa existir de forma padronizada em todos os cartórios do país. O processo estava fragmentado entre milhares deles. Criamos o aplicativo que unifica a pesquisa e o acesso, conectando por trás os sistemas legados dos cartórios — que não podiam parar durante a transição.
Perguntas frequentes
Quase nunca. Reescrever do zero é a opção mais cara e mais arriscada, e costuma ser a primeira que aparece na mesa. O diagnóstico separa o que precisa ser reescrito, o que só precisa ser migrado de infraestrutura e o que pode continuar como está.
É o padrão de trabalho, não a exceção. A migração acontece por partes, com o sistema antigo no ar, e cada etapa tem caminho de volta. No case de registro de imóveis, os sistemas dos cartórios seguiram operando durante toda a transição.
As três saem do mesmo diagnóstico e custam coisas diferentes. Migração de sistemas legados preserva a regra que funciona e troca a base embaixo dela; reescrita faz sentido quando a regra em si mudou; substituição por produto de mercado resolve quando o processo não é o que te diferencia. Decidir isso antes de começar é o que separa modernização de retrabalho caro.
Mais do que aparece na fatura. O custo de manutenção de sistema legado inclui o que você deixa de lançar, o tempo do time sênior preso em sustentação e o risco de quem conhece a regra sair da empresa. É esse número, e não o do projeto, que costuma justificar a modernização.
Não, e confundir custa caro. Modernização de software e modernização de aplicações legadas tratam de um sistema específico; modernização tecnológica e modernização de TI falam do parque inteiro. Modernização de sistemas empresariais — ou de software empresarial — costuma ser a primeira: o sistema que sustenta a operação e trava o resto.
Separando regra de base. Software legado ou aplicação legada raramente tem a regra errada; tem a base velha. Migração de software legado preserva a regra e troca o que está embaixo; atualização de sistemas e evolução de sistemas fazem isso aos poucos, com a operação rodando. Transformação de sistemas por reescrita total é a exceção, não o padrão.
Quando ninguém documentou e quem sabia saiu. Engenharia reversa de software recupera a regra que só existe no código; reengenharia de software reconstrói em cima dela. É o caminho para quem pergunta como substituir sistema legado sem perder o que ele faz — substituição de sistemas legados começa por saber o que substituir.
Pela leitura do que existe: código, banco, integrações e as pessoas que operam. Documentação ausente é o cenário comum, e mapear isso é parte do diagnóstico — não um pré-requisito para contratá-lo.
Varia com o tamanho e a criticidade do sistema. O que fixamos é o diagnóstico: escopo e prazo fechados, ao fim do qual você tem o plano por etapas, com prioridade e risco de cada uma — antes de assumir compromisso de projeto longo.
Às vezes. Migrar para a nuvem um sistema mal estruturado costuma só mudar o endereço do problema e aumentar a conta. A decisão entra no diagnóstico, junto com o resto.
Escopo e prazo fixos. Em poucas semanas você tem, em uma página, onde o negócio está deixando dinheiro na mesa e o que fazer com isso.