Migrar o motor de decisão é uma das operações mais delicadas em uma empresa de crédito. O sistema antigo — por pior que seja — está tomando decisões reais. Paralisá-lo é inaceitável. Migrar errado é catastrófico. A boa notícia: com o plano certo, a migração pode ser feita sem interrupção, com validação rigorosa e rollback instantâneo.
Quando migrar faz sentido
Sinais de que é hora de migrar:
- Mudanças levam semanas — alterar uma regra exige deploy de código completo
- Sem versionamento — ninguém sabe qual política estava ativa em março
- Sem observabilidade — você sabe o approval rate, mas não por quê
- Latência inaceitável — decisões levam 10+ segundos
- Sem backtesting — mudanças vão para produção na esperança de que funcionem
- Vendor lock-in — o sistema atual é caro, inflexível e sem roadmap
As 7 etapas da migração
Etapa 1: Inventário e mapeamento
Antes de migrar, documente tudo que existe:
- Quantas políticas ativas? Quantas regras por política?
- Quais fontes de dados são consultadas? Quais APIs?
- Quais modelos (scorecards, ML) estão em produção?
- Qual o volume diário de decisões por produto/canal?
- Quais integrações downstream consomem a decisão?
- Quais SLAs de latência existem?
Etapa 2: Definir o escopo da migração
Raramente faz sentido migrar tudo de uma vez. Defina:
- Produto piloto — escolha o produto com menor risco e volume moderado
- Scope freeze — durante a migração, não adicionar funcionalidades novas ao sistema antigo
- Critérios de sucesso — métricas que definem quando a migração está completa (concordância > 99%, latência < SLA)
Etapa 3: Replicar políticas no novo motor
Reimplementar cada política, regra e modelo no novo sistema. Não "melhorar" durante a migração — o objetivo é paridade funcional.
- Usar o inventário da Etapa 1 como checklist
- Testar cada regra individualmente com test cases conhecidos
- Verificar edge cases: valores nulos, limites de faixa, combinações raras
Etapa 4: Shadow mode
O novo motor roda em paralelo com o antigo:
- Cada request vai para ambos os motores simultaneamente
- Apenas a decisão do motor antigo é utilizada na operação real
- As decisões do novo motor são registradas para comparação
- Relatório diário de concordância: quantas decisões iguais vs diferentes
Concordância: % de decisões idênticas entre antigo e novo (target: > 99%)
Divergências classificadas: Cada divergência é erro do novo motor ou melhoria?
Latência comparativa: Novo motor é mais rápido que o antigo?
Impacto simulado: Se usássemos o novo motor, o que mudaria em approval rate e default rate projetado?
Etapa 5: Traffic split gradual
Quando shadow mode confirma paridade, começar a enviar tráfego real para o novo motor:
- Semana 1: 5% do tráfego → novo motor
- Semana 2: 20% (se métricas OK)
- Semana 3: 50%
- Semana 4: 100%
Em qualquer ponto, se métricas degradarem, reverter instantaneamente para 0%.
Etapa 6: Validação pós-migração
- Comparar KPIs (approval rate, default rate, latência) pré vs pós migração
- Verificar audit trail: todas as decisões estão sendo registradas corretamente?
- Testar explanations: motivos de negação estão corretos?
- Validar integrações downstream: sistemas que consomem a decisão estão recebendo no formato esperado?
Etapa 7: Decommission do sistema antigo
- Manter sistema antigo em standby por 30-60 dias (rollback de emergência)
- Exportar dados históricos para o novo sistema
- Desligar integrações do sistema antigo
- Documentar a migração para auditoria
Erros comuns na migração
- "Big bang" — migrar 100% do tráfego de uma vez; alto risco sem possibilidade de comparação
- "Melhorar enquanto migra" — adicionar funcionalidades novas durante a migração; impossível isolar causa de divergências
- Sem shadow mode — confiar que o novo motor "funciona" sem validação em paralelo
- Ignorar edge cases — a maioria das divergências está em valores nulos, limites de faixa e combinações raras
- Sem rollback plan — se algo der errado, não ter como reverter em minutos
No Decision Stack™
O Decision Stack™ suporta shadow mode nativo: o novo pipeline roda em paralelo sem afetar a operação. Traffic split configurável por percentual. Relatório automático de concordância. Rollback instantâneo via versionamento de políticas.
Como a Sinky facilita migrações
A Sinky oferece shadow mode nativo: seu motor atual continua operando enquanto o Sinky Studio processa as mesmas solicitações em paralelo. O relatório de concordância mostra divergências classificadas (erro vs melhoria). Traffic split é configurável via dashboard. Rollback é instantâneo — uma política anterior pode ser restaurada em segundos.
Perguntas frequentes
Quanto tempo leva?
4-8 semanas para operações simples, 3-6 meses para média complexidade, 6-12 meses para operações complexas com múltiplos produtos e alta regulação.
O que é shadow mode?
O novo motor roda em paralelo sem afetar a operação real. Decisões são comparadas para validar paridade antes de migrar tráfego.
Preciso migrar tudo de uma vez?
Não. Migração gradual: comece com 5-10% do tráfego, aumente progressivamente conforme a validação confirma paridade.
