Modernizar o sistema em que ninguém se atreve a mexer, uma capacidade de cada vez.
Décadas de regras de negócio vivem em COBOL, PL/I, Oracle Forms e nas primeiras versões de Java e .NET. Recuperamos essas regras, construímos uma rede de segurança de testes e avançamos capacidade a capacidade por trás de uma fachada, com execuções em paralelo e reconciliação antes de desligar o que quer que seja.
Para organizações com sistemas críticos em vários países, onde não há margem para paragens nem para regras perdidas.
04Reconstruir uma fatia por trás de uma fachadaSistema
05Executar em paralelo e reconciliarSistema
06Analisar as diferençasPessoa
07Mudar e desativarPessoa
O portefólio é avaliado e a arquitetura de destino acordada. As regras de negócio são recuperadas do código com apoio de IA e verificadas por pessoas. Os testes de caracterização formam uma rede de segurança. Cada capacidade é reconstruída por trás de uma fachada e executada em paralelo com o sistema antigo; as diferenças são analisadas e corrigidas antes de o responsável do negócio aprovar a mudança e a parte antiga ser desativada.
Antes e depois
O que muda na forma de trabalhar
Hoje
Com o sistema
Hoje
Hoje: Cada alteração é um risco
Pequenas alterações regulamentares levam meses, porque ninguém consegue prever o que mais uma alteração vai afetar.
Com o sistema
Com o sistema: Alterações apoiadas em testes
Os testes de caracterização registam o que o sistema faz hoje, para que cada alteração mostre o seu efeito antes de entrar em produção.
Hoje
Hoje: O conhecimento está a reformar-se
As pessoas que percebem o código estão perto da reforma, e a documentação deixou há muito de corresponder ao sistema.
Com o sistema
Com o sistema: Regras escritas e verificadas
As regras de negócio recuperadas do código ficam documentadas em linguagem clara e confirmadas pelos especialistas do negócio.
Hoje
Hoje: Os planos de substituição total encalham
Os programas de substituição completa prometem uma única data de passagem que continua a mudar enquanto os custos crescem.
Com o sistema
Com o sistema: Valor entregue por fatias
As capacidades passam uma a uma para trás de uma fachada. Cada fatia entra em produção sozinha e pode ser revertida.
Hoje
Hoje: Dados presos em estruturas antigas
Os novos serviços e os casos de utilização de IA não chegam aos dados sem extrações frágeis e processamentos noturnos em lote.
Com o sistema
Com o sistema: Dados disponíveis por APIs
Os domínios migrados expõem os seus dados através de APIs documentadas, reconciliadas com o sistema antigo até à sua desativação.
Fluxo de trabalho
Como funciona o fluxo de trabalho
Uma abordagem «strangler fig»: o novo sistema cresce à volta do antigo, capacidade a capacidade. O ciclo entre a execução em paralelo e a reconstrução é onde acontece a maior parte do trabalho real.
Fluxo de trabalho ilustrativo
7 passos · 3 pontos de controlo humano
Legenda
Sistema
Agente de IA
Pessoa
Ponto de controlo humano
Via de exceção
Modernização de sistemas legados: fluxo ilustrativo com ciclo de reconciliação
Ler o diagrama em texto
O percurso principal vai da avaliação do portefólio e da recuperação das regras de negócio, passando pela construção de uma rede de segurança de testes de caracterização e pela reconstrução de uma capacidade por trás de uma fachada, até à execução em paralelo do sistema antigo e do novo e, por fim, à mudança e à desativação da parte antiga.
As pessoas aprovam a arquitetura de destino, verificam cada regra recuperada e aprovam cada mudança: são esses os pontos de controlo humano.
Quando a execução em paralelo mostra resultados diferentes, a fatia sai do percurso principal para ser analisada por engenheiros e especialistas do negócio, e regressa ao passo de reconstrução até o sistema antigo e o novo baterem certo.
01
Passo 1: Avaliar o portefólioPessoa
Inventário das aplicações, mapeamento das dependências e dos fluxos de dados, e uma decisão por aplicação: desativar, manter, realojar, mudar de plataforma, reconstruir ou substituir. Os domínios são mapeados para encontrar as junções onde é possível dividir o sistema em fatias.
Ponto de controlo humano
O seu comité de arquitetura aprova a arquitetura de destino e a ordem das fatias.
02
Passo 2: Recuperar as regras de negócioAgente de IA
A análise de código com apoio de IA lê COBOL, PL/I, JCL, Oracle Forms e versões antigas de Java ou .NET, e redige documentação, grafos de chamadas e um catálogo de regras de negócio.
Ponto de controlo humano
Engenheiros e especialistas do negócio verificam cada regra extraída antes de ser usada como especificação. As regras não verificadas ficam assinaladas como tal.
03
Passo 3: Construir a rede de segurançaSistema
Os testes de caracterização são gerados a partir de entradas e saídas de produção anonimizadas, para que o comportamento atual, incluindo as suas particularidades, fique registado antes de qualquer alteração.
04
Passo 4: Reconstruir uma fatia por trás de uma fachadaSistema
Uma fachada de encaminhamento ou uma camada de APIs é colocada à frente do sistema antigo. Uma capacidade é reconstruída como um novo serviço, com os seus dados migrados e mantidos sincronizados.
05
Passo 5: Executar em paralelo e reconciliarSistema
O sistema antigo e o novo processam as mesmas transações. Os resultados e os dados são comparados automaticamente e cada diferença é reportada por regra e por registo.
06
Passo 6: Analisar as diferençasPessoa
Engenheiros e especialistas do negócio decidem se cada diferença é um defeito do novo serviço, um defeito do antigo ou uma alteração intencional, e devolvem a fatia para ser corrigida.
Via de exceção: Resultados diferentes· Regressa ao passo 4
07
Passo 7: Mudar e desativarPessoa
O tráfego da capacidade passa para o novo serviço através da fachada. Após um período estável, o código antigo e os seus dados são desativados e arquivados.
Ponto de controlo humano
O responsável do negócio aprova cada mudança com base nos resultados da reconciliação. A reversão através da fachada continua disponível até à desativação.
Componentes
O que construiríamos
01
Mapa do portefólio e das dependências
Inventário, mapeamento das interfaces e dos fluxos de dados, e um modelo de domínio que mostra onde o sistema pode ser dividido em fatias.
Salesforce como novo front officePlataformaSalesforce
Plataforma de integração e gateway de APIs
Cloud ou centro de dados de destino
Controlos
Controlos previstos desde o desenho
Limites de acesso
A análise de código corre num ambiente que controla, sem envio de código-fonte para serviços que não aprovou. Os dados de produção usados em testes são anonimizados antes de saírem da zona de produção.
Revisão humana
As regras recuperadas são verificadas por engenheiros e especialistas do negócio antes de se tornarem especificações. Cada mudança é aprovada pelo responsável do negócio com base nos resultados da reconciliação, com reversão disponível.
Auditabilidade
Cada regra do catálogo remete para o código de onde veio e para a pessoa que a verificou. Os relatórios de reconciliação são guardados como evidência de cada mudança.
Proteção de dados
A migração de dados segue um mapeamento documentado, com contagens de registos e somas de verificação, e os dados pessoais são minimizados nos conjuntos de teste. As regras de conservação acompanham os dados.
Transparência da IA
Quando a IA redige documentação ou código, o resultado é identificado, revisto e versionado como qualquer outro artefacto de engenharia.
Indicadores
O que mediríamos
Acordamos estes indicadores consigo durante a avaliação e acompanhamo-los por fatia, e não apenas para o programa no seu conjunto.
O que mediríamos
Indicador
Porque é importante
Como o mediríamos
01Tempo de implementação de alterações
Porque é importanteO sinal mais claro de que o sistema se está a tornar mais fácil de alterar.
Como o mediríamosTempo entre o pedido de alteração aprovado e a entrada em produção, nas partes antigas e nas modernizadas.
02Estado da reconciliação
Porque é importanteMostra se o novo serviço se comporta de facto como o antigo onde deve.
Como o mediríamosPercentagem de transações e registos que coincidem durante a execução em paralelo, com as diferenças em aberto por causa.
03Cobertura das regras
Porque é importanteAs regras desconhecidas são o principal risco de qualquer substituição.
Como o mediríamosPercentagem de regras de negócio recuperadas que foram verificadas por especialistas do negócio e estão cobertas por testes.
04Peso do legado
Porque é importanteA modernização compensa quando os componentes antigos são de facto desligados.
Como o mediríamosCapacidades, caminhos de código, processamentos em lote e licenças desativados, acompanhados por fatia.
Não fixamos metas antes de existir uma linha de base.
Implementação
Como o poríamos em produção
Fase 01
Avaliação
Portefólio, dependências, domínios e riscos. Escolhemos uma primeira fatia que seja importante para o negócio, mas que possa ser revertida.
Critérios de saída
Arquitetura de destino aprovada
Ordem das fatias acordada
Acesso a testes e dados assegurado
Fase 02
Primeira fatia
Recuperação de regras, rede de segurança, fachada e uma capacidade reconstruída, executada em paralelo com o sistema antigo.
Critérios de saída
Reconciliação dentro da tolerância acordada
O responsável do negócio aprova a mudança
Reversão testada
Fase 03
Fatia a fatia
As capacidades seguintes percorrem o mesmo caminho, cada uma com a sua própria execução em paralelo e decisão de mudança.
Critérios de saída
Cada fatia reconciliada e mudada
Conhecimento transferido para a sua equipa
Fase 04
Desativação
O código antigo, os processamentos em lote e os repositórios de dados são arquivados e desligados.
Extensões à medida do ERP e sistemas de fábrica, migrados a par de uma migração para SAP S/4HANA.
Exemplo ilustrativo
O sistema de apólices de uma seguradora
Situação
Uma seguradora com operações em Portugal e Espanha calcula prémios e gere apólices num sistema em mainframe partilhado pelos dois países. Cada país tem alterações de produto pendentes, e dois dos programadores que conhecem o código estão perto da reforma.
Sistema
As regras são recuperadas e verificadas por país e por produto. Uma fachada encaminha primeiro os cálculos de um ramo para um novo serviço, que corre em paralelo com o mainframe até os resultados baterem certo.
Controlo humano
Os especialistas de produto de cada país verificam as suas regras. O responsável do negócio de cada país aprova a mudança; a reversão através da fachada continua disponível.
O que mediríamos
Estado da reconciliação por país e por ramo, cobertura das regras e tempo de implementação da próxima alteração de produto.
Portugal
Modernizar segundo as regras europeias
Grupos com operações em Portugal e noutros Estados-Membros correm muitas vezes o mesmo núcleo legado para vários países, cada um com as suas alterações regulamentares em fila de espera. Organizamos a modernização para que as variantes nacionais avancem uma fatia de cada vez, com o sistema antigo e o novo reconciliados para cada jurisdição antes de qualquer coisa ser desligada.
Os serviços modernizados ficam em plataformas desenhadas a pensar no Regime Jurídico da Cibersegurança (Decreto-Lei n.º 125/2025, em vigor desde 3 de abril de 2026), que transpõe a Diretiva NIS2. Nos bancos e nas seguradoras aplica-se também o DORA; em Portugal, as autoridades competentes são o Banco de Portugal, a ASF e a CMVM, cada uma relativamente às entidades que supervisiona.
As regras do Regulamento dos Dados sobre a mudança de prestador de serviços de tratamento de dados são uma razão para manter os dados portáveis desde a primeira fatia. Quando os registos contêm dados pessoais, os mapeamentos de migração e os dados de teste seguem o RGPD.
Perguntas sobre a modernização de sistemas legados
01Porque não substituir todo o sistema de uma vez?
Porque uma única passagem concentra todo o risco numa data, e o negócio espera anos por qualquer benefício. Avançar capacidade a capacidade permite que cada fatia se prove numa execução em paralelo, entre em produção sozinha e seja revertida se for preciso.
02A IA consegue traduzir o nosso COBOL para Java?
A tradução linha a linha tende a produzir código tão difícil de alterar como o original. Usamos a IA para ler e documentar o código antigo e para redigir regras e testes, e depois desenhamos os novos serviços como deve ser. Cada regra recuperada é verificada por pessoas antes de ser usada.
03Os nossos especialistas estão a reformar-se. Como recolhem o que sabem?
Através de sessões estruturadas em que os especialistas reveem as regras recuperadas e os testes de caracterização. O conhecimento deles fica em documentação e em testes que permanecem com a sua equipa, e não na nossa cabeça.
04Isto também se aplica ao SAP ECC?
Sim. Os mesmos princípios aplicam-se à correção de código à medida e a uma migração para SAP S/4HANA: avaliar o que ainda é usado, recuperar e testar o que importa e avançar por passos controlados.
05Durante quanto tempo funcionam o antigo e o novo lado a lado?
Até os resultados da reconciliação cumprirem a tolerância acordada com o responsável do negócio, e tempo suficiente para cobrir processos periódicos como o fecho do mês ou do ano.
Diga-nos que sistema o está a travar e o que depende dele. Sugerimos uma primeira fatia e a forma de a provar com segurança, sejam quais forem os países que serve.