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.
Lemos o que existe: código, banco de dados, integrações e as pessoas que operam o sistema todo dia. Você recebe a lista de módulos, com o quanto cada um é crítico, o quanto muda e o que quebra se parar, e o plano por etapas, com prioridade e risco de cada uma. Escopo e prazo fixos.
Migração por partes, com o legado no ar. O novo assume função por função, com rollback possível a cada etapa. Nada de virada num fim de semana.
O sistema novo operando e medido. O legado sai de cena quando não resta nada crítico nele, não antes.
A decisão
Sistema legado raramente é uma coisa só. É um conjunto de módulos com idades, criticidades e taxas de mudança diferentes, e cada um pede uma decisão. A modernização de sistemas começa por separar esse bloco em partes: nem tudo precisa ser reescrito, e o mais caro é descobrir isso depois.
Módulo estável, raramente alterado e que não bloqueia nada fica como está. Mexer nele é gastar dinheiro para adicionar risco. Manter por decisão, e não por omissão, é ter escrito o porquê, junto com o gatilho que faria isso mudar.
Tirar o sistema de onde ele está e levar para outro lugar, em geral do datacenter para a nuvem, mexendo o mínimo possível no código. Resolve dor de custo, de capacidade ou de fim de contrato de hospedagem. Sistema difícil de alterar continua difícil depois de mudar de endereço.
Faz sentido quando a tecnologia base saiu de suporte, quando não existe mais no mercado quem saiba mantê-la ou quando a arquitetura impede uma mudança de negócio que já foi decidida. Fora desses casos, costuma ser a saída mais cara para um problema que tinha saída mais barata.
Trocar por um produto de mercado resolve quando o processo não é o que diferencia a empresa. Decidir isso antes de começar é o que separa modernização de retrabalho caro.
Caso real · Registro de imóveis · ONR
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 para o ONR 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.
Caso real · Transporte de cargas · GOL
No transporte de cargas de uma companhia aérea, cada venda precisa virar fatura, boleto e lançamento contábil sem atraso e sem erro. O sistema legado de vendas não conversava com a plataforma financeira do grupo, e comercial, fiscal e contábil funcionavam separados, costurados por trabalho manual. Construímos a integração de ponta a ponta com o SAP, da venda registrada ao boleto no canal digital, sem substituir o sistema de vendas, que seguiu operando.
Perguntas frequentes
É o sistema que a empresa herdou de outra época e do qual a operação ainda depende. Sistema antigo que funciona não é problema. Sistemas legados viram problema quando passam a definir o que o negócio pode ou não fazer: travam o lançamento, encarecem cada mudança e concentram o conhecimento em duas ou três pessoas.
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 borda, sem trocar o que sustenta a operação. Na GOL, o sistema legado de vendas de cargas passou a conversar com a plataforma financeira do grupo, da venda ao boleto, sem intervenção manual e sem substituir o sistema de vendas. Quando o legado não tem API, existem outros caminhos: banco de dados, arquivo ou automação da própria interface. Veja a consultoria e integração SAP.
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.
Sim. Em São Paulo o atendimento é presencial: a reunião de diagnóstico acontece no seu escritório, em qualquer região da capital. No resto do país o trabalho é remoto, o que vale para empresas do Rio de Janeiro, Belo Horizonte, Brasília, Porto Alegre, Goiânia, Fortaleza ou de qualquer outra cidade.
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.