Serviço

Migração de sistema legado sem perder um registro

Mapeamento campo a campo, reconciliação com o sistema antigo e cutover fora do horário comercial. O histórico vai junto e a operação não para.

184.320
registros reconciliados em uma migração
5 a 10
ensaios completos antes da virada
0
divergências em aberto no momento do cutover

Por que a migração é adiada há três anos

O sistema antigo todo mundo sabe que precisa sair. Ele trava, ninguém mais dá suporte, o relatório sai errado e a pessoa que entendia dele saiu da empresa. Mesmo assim ele fica — porque o medo de perder histórico é maior que o incômodo de conviver com o problema.

Esse medo é legítimo: migração malfeita perde registro, duplica lançamento e desmonta o fechamento contábil. O que resolve não é coragem, é método — e um método que produz prova antes de virar a chave, não depois.

Como fazemos

  1. Inventário

    Levantamos tudo que existe na origem, inclusive o que ninguém usa há anos. Migração que começa pelo que 'é importante' descobre tarde que o campo esquecido era o que amarrava dois cadastros.

  2. De-para campo a campo

    O documento mais chato e mais importante do projeto: origem, destino, regra de conversão e o que fazer com o que não tem equivalente. Aprovado por quem opera, não só por quem contrata.

  3. Ensaios

    Rodamos a migração em ambiente de teste quantas vezes for preciso — normalmente entre cinco e dez. Cada rodada é medida, e a seguinte começa do zero, para não mascarar erro com correção manual.

  4. Reconciliação

    Totais, contagens e saldos conferidos contra o sistema antigo, com relatório de divergência. Nenhum cutover acontece com divergência em aberto — é o critério que torna a virada uma decisão e não uma aposta.

  5. Cutover

    Fora do horário comercial, com janela definida, plano de retorno testado e o sistema antigo em modo leitura por um período. Na segunda-feira, ninguém percebe.

O que você recebe

  • Documento de de-para completo, campo a campo
  • Relatório de reconciliação com totais conferidos contra a origem
  • Plano de cutover com janela, responsáveis e plano de retorno
  • Sistema antigo em modo leitura durante o período de convivência
  • Histórico completo migrado, consultável no sistema novo

Com o que trabalhamos

  • PostgreSQL
  • SQL Server
  • Oracle
  • Python
  • Airbyte
  • dbt
  • AWS

Comece pelo diagnóstico

Sete dias, sem custo e sem compromisso. Você sai com um plano de ação, uma estimativa de esforço e o caminho mais curto para o seu caso.

Mais de 90 operações já rodam com a gente

Perguntas frequentes

Quanto tempo a operação fica parada?

O cutover roda fora do horário comercial e a janela típica é de 4 a 12 horas, dependendo do volume. Em operação que não pode parar, fazemos a virada em modo de convivência: os dois sistemas ficam de pé, com o antigo em leitura, e a troca acontece por área.

E se der errado no meio da virada?

Existe plano de retorno testado nos ensaios, não escrito no dia. Até um ponto definido da janela, a decisão de voltar é reversível e o sistema antigo volta a receber lançamento. Passado esse ponto, seguimos — e é por isso que ele é decidido antes, com o cliente.

Dá para migrar só uma parte e deixar o resto para depois?

Dá, e muitas vezes é o certo. Cadastro e histórico costumam vir primeiro; movimentação antiga pode ficar em consulta no sistema legado por um tempo. O que não dá é migrar metade de um mesmo processo — isso cria dois lugares de verdade para o mesmo dado.

O sistema antigo não tem banco documentado. Muda alguma coisa?

Muda o prazo do inventário, não a viabilidade. Nesse caso a engenharia reversa é feita a partir do banco e do comportamento do sistema, e o de-para leva mais tempo para fechar. É comum: a maioria dos legados que migramos não tinha documentação nenhuma.