A migração não precisa ser big-bang. Um guia operacional em quatro fases para tirar regras do Drools e levar para uma plataforma BRMS gerenciada com coexistência paralela, validação A/B e rollback em segundos. Testado em projetos reais com seguradoras e financeiras brasileiras.
Tecnologia
Existem dois cenários típicos em que essa conversa começa.
No primeiro, o CTO já decidiu sair do Drools. A conta do TCO foi feita, o Comitê aprovou, a nova plataforma foi escolhida. Agora vem a parte mais difícil: como tirar regras críticas de produção e colocar em outro lugar sem que isso vire um trimestre de pânico operacional.
No segundo, a decisão ainda não foi tomada, mas o medo de migrar é exatamente o que está segurando ela. "Drools tem cinco anos rodando, ninguém quer mexer." Esse é o lock-in real do open source que nunca aparece nos slides do fornecedor original.
Este artigo é para os dois cenários. Vamos descrever a abordagem de migração que vimos funcionar em projetos com seguradoras, financeiras e operações de logística enterprise no Brasil. Sem retórica de "transformação digital". Apenas o que fazer, em que ordem, e onde o projeto costuma quebrar quando você não presta atenção.
A primeira tentação em migração é fazer tudo de uma vez. Reescreve toda a base de regras na nova plataforma, valida em ambiente paralelo durante alguns meses, escolhe uma data de cutover, sobe a nova versão num final de semana e desliga o Drools na segunda-feira.
Esse modelo falha em quase todos os projetos enterprise pelas mesmas três razões: você descobre regras esquecidas em produção apenas quando elas falham depois do cutover; o teste paralelo nunca cobre 100% dos casos reais; e o rollback exige restaurar não só código, mas o estado dos sistemas downstream que já consumiram decisões da nova plataforma.
A indústria tem nome para o anti-padrão: big bang rewrite. Em 2004, Martin Fowler descreveu uma alternativa que virou referência, o padrão Strangler Fig. A ideia é simples: em vez de substituir o sistema antigo de uma vez, você cresce o sistema novo em torno dele, redirecionando tráfego gradualmente até que o legado fique sem função e possa ser desligado. Microsoft Azure documenta o padrão na arquitetura oficial. AWS prescribe. Thoughtworks usa em quase todo projeto de modernização.
Para migração de motor de regras, o padrão se aplica perfeitamente. As regras de negócio são naturalmente modulares (por domínio, por linha de produto, por país). Você não precisa migrar tudo junto. Pode migrar pricing primeiro, validar três meses, depois aceitação de risco, depois comissionamento.
A seguir está a versão operacional desse padrão aplicada especificamente a Drools, em quatro fases.
Antes de migrar qualquer regra, você precisa saber quais regras tem. Parece óbvio. Não é.
Em quase todos os projetos de migração de Drools que acompanhamos, a primeira surpresa é descobrir que a base de regras é maior do que a documentação diz. Regras escritas há três anos por engenheiros que saíram, regras temporárias que ficaram permanentes, regras duplicadas em arquivos DRL diferentes, regras que ninguém sabe se ainda estão em uso.
A fase 1 entrega quatro artefatos:
1. Catálogo completo de regras ativas. Não vale o que está no Confluence. Vale o que está no código de produção. Ferramenta direta: rodar uma análise estática dos arquivos .drl, .xls e .dmn na branch master e mapear cada rule por nome, autor original, data da última modificação, e quem consulta via API.
2. Mapa de consumidores. Quem chama o Drools hoje? Qual sistema, qual endpoint, em que volume, qual SLA. Esse mapa é a base do roteamento na fase 3.
3. Classificação por criticidade. Cada regra recebe um label: crítica (decisão financeira, regulatória ou de risco direto ao cliente), importante (decisão operacional com impacto mensurável), suporte (lookups, formatação, transformação). Migra-se na ordem inversa: suporte primeiro, importante depois, crítica por último.
4. Mapa de dependências entre regras. Drools tem o problema clássico do Rete: uma regra pode disparar outra, que dispara outra, num efeito cascata. Sair dessa amarra exige entender quais regras se chamam mutuamente. Em projetos enterprise reais, encontramos cascatas de até oito níveis. Migrar uma regra no meio da cascata sem mapear isso é receita para incidente em produção.
Output da fase 1: o catálogo, o mapa de consumidores, a classificação e a planilha de dependências. Sem esses quatro, a fase 2 não começa.
Tempo típico: três a cinco semanas, com um arquiteto sênior alocado em tempo integral e meio tempo de cada engenheiro que conhece bem partes específicas do código atual.
Armadilha: pular a fase 1 porque "já temos a documentação no Confluence". Em todos os projetos onde tentamos isso, a documentação cobria entre 40% e 70% da realidade. Os 30% restantes só apareceram em produção, depois.
Com o inventário pronto, monta-se a infraestrutura de coexistência.
Dois componentes precisam existir antes de migrar a primeira regra:
A fachada (proxy/router). Um componente leve que fica entre os sistemas consumidores e os motores de regras. Recebe todas as chamadas que hoje vão direto para Drools e decide para onde encaminhar: continuar no Drools, mandar para a nova plataforma, ou (essa é a parte importante) mandar para os dois ao mesmo tempo em modo shadow.
Implementação razoável: API Gateway (Kong, Apigee, AWS API Gateway) com regras de roteamento por path ou header, mais lógica de comparação assíncrona. Time-to-build: duas a três semanas. Reuso de componentes que muitas operações já têm: alto.
A nova plataforma em ambiente próximo ao de produção. Não vale rodar a nova plataforma em ambiente compartilhado de desenvolvimento. Precisa ser pré-produção, com configuração de capacity, integração com identidade corporativa, logging direcionando para os sistemas de observability já existentes, e SLA monitorado. Plataformas gerenciadas modernas entregam esse setup em uma a duas semanas. Cluster próprio Drools pode levar mais.
Com fachada e plataforma destino prontas, a primeira regra é migrada. Uma regra de suporte, baixo risco, baixo volume, sem dependências. O propósito não é entregar valor ainda, é validar o pipeline inteiro.
A regra é reescrita no formato da nova plataforma. A fachada começa a roteá-la em modo shadow: a chamada vai para os dois motores, compara-se o resultado, mas o sistema downstream continua usando a resposta do Drools. Diferenças são logadas e investigadas. Quando o time tem confiança de que a nova plataforma replica o comportamento do Drools em 100% dos casos observados, o roteamento é invertido: agora a nova plataforma responde, e o Drools roda em shadow.
Esse padrão de "shadow inverso" é a única forma realmente segura de migrar regra crítica. Você nunca expõe o cliente final à versão nova sem ter visto ela responder corretamente milhares de vezes em produção primeiro.
Output da fase 2: fachada operacional, nova plataforma em pré-produção com SLA validado, e a primeira regra de suporte rodando em shadow (e depois inversamente).
Tempo típico: quatro a seis semanas.
Armadilha: querer migrar uma regra crítica como teste. A primeira regra precisa ser de baixo risco. Você está testando o pipeline, não a regra. Em um projeto recente, o time quis começar pela regra de aprovação de crédito acima de R$ 50 mil. Levaram dois meses para resolver a coragem de inverter o shadow. Quando começam por uma regra de transformação de CEP, em três semanas estavam confiantes para passar para regras maiores.
Com pipeline validado e a primeira regra migrada, começa o trabalho de volume.
A migração avança em ondas, agrupadas por domínio funcional:
Cada onda segue o mesmo protocolo de três etapas: migrar regras para a plataforma destino, rodar em shadow durante 2 a 4 semanas, inverter quando o time de operação assina o aceite formal.
A inversão nunca acontece sem três checagens obrigatórias: equivalência 100% nos casos observados em shadow, performance dentro do SLA acordado (latência p99, throughput), e plano de rollback testado em ambiente de homologação no dia anterior.
O rollback merece destaque. Em uma plataforma BRMS gerenciada moderna, reverter uma regra ativa para uma versão anterior é uma operação de segundos. Você seleciona a versão na interface e ativa. Em Drools, rollback envolvia geralmente um deploy de versão anterior do artefato e reinício de cluster, com janela de manutenção. Nas primeiras ondas, é comum acionar rollback uma ou duas vezes. Quando esse processo é instantâneo, o time da operação ganha confiança para acelerar.
Output da fase 3: 80% a 95% das regras de produção rodando na nova plataforma. Drools continua ativo para o restante.
Tempo típico: quatro a seis meses, dependendo do volume total de regras.
Armadilha: acelerar ondas porque "está dando certo". A pressão para encerrar a migração rápido é real. O CFO quer parar de pagar dois times de infra, o roadmap de novas regras está represado. Mas as ondas finais são justamente as regras críticas reguladas, onde um erro custa muito mais do que toda a economia da migração. Vimos um projeto em que o time pulou de 2 semanas de shadow para 4 dias na onda final para "ganhar tempo no trimestre". Resultou em um incidente de aceitação de risco que precisou reverter para o Drools, com cinco dias de operação degradada e auditoria interna formal. Disciplina nas ondas finais paga ela mesma muitas vezes.
A última fase é onde muitos projetos param e nunca terminam.
Quando 90% das regras migraram, é tentador deixar os 10% restantes rodando em Drools "porque agora não tem urgência". Esse é o pior cenário possível: você paga dois times de infra, mantém dois pipelines de deploy, dois sistemas de monitoramento, dois conjuntos de runbook. O custo operacional do "quase migrado" é maior do que o da migração inteira.
Decomissionamento tem três etapas obrigatórias:
1. Migrar as regras finais. As últimas 5%-10% costumam ser as regras que ninguém quer tocar: regras antigas com histórico complexo, regras com dependências externas que ninguém documentou bem, regras escritas por um engenheiro específico que saiu. Encare. Aloque o melhor arquiteto, dê o tempo necessário, e migra.
2. Remover a fachada. Quando todas as regras migraram, a fachada não tem mais propósito. Os consumidores passam a chamar a nova plataforma diretamente. A fachada pode ficar como uma camada de logging adicional, mas o roteamento dinâmico para Drools deixa de existir.
3. Desligar Drools. Cluster, banco de dados, ferramentas de build, contas de monitoramento. Tudo desativado, com um período de "modo arquivo" de 30 a 90 dias antes da remoção definitiva, caso apareça alguma chamada esquecida.
Output da fase 4: Drools desligado. Plataforma única em produção. Time de infra liberado para outras prioridades.
Tempo típico: quatro a oito semanas, dominantemente o item 1.
Somando as fases para um caso de uso enterprise típico (200 a 800 regras em produção, 3 a 5 sistemas consumidores, requisitos regulatórios em pelo menos um domínio):
Total: 6 a 10 meses para migração completa, com a maior parte do valor de negócio sendo entregue a partir da semana 16 (quando as ondas 2-3 começam a destravar autonomia para as áreas).
Esse cronograma assume equipe interna de 2 a 3 engenheiros dedicados, suporte do fornecedor da nova plataforma para os componentes específicos, e patrocínio executivo claro para as decisões de cutover de cada onda.
CTO que conduz migração precisa de três métricas semanais no painel:
Cobertura de regras migradas. Percentual do total de regras de produção que já está na nova plataforma. Curva típica: lenta nas primeiras 4-6 semanas (alinhando o pipeline), acelera nas semanas 8-20, desacelera nas últimas (regras complexas).
Taxa de divergência shadow. Percentual de chamadas em shadow onde a nova plataforma respondeu diferente do Drools. Esperado: muito alto nas primeiras semanas (10%+), convergindo rapidamente para perto de zero antes de inverter cada onda. Se a divergência não converge, não inverter. É sinal de que ainda há lógica não mapeada.
Tempo entre rollbacks. Quantos dias de operação sem rollback. Cresce ao longo do projeto. É a métrica que dá confiança ao Comitê de que o projeto está saudável.
Em projetos que acompanhamos, a migração não costuma travar nos pontos técnicos. Trava em três outros lugares: na resistência organizacional ("o time de pricing não quer mudar a forma de trabalhar"), na falta de patrocínio executivo para as decisões duras (qual onda atrasar, qual regra crítica acelerar), e na descoberta tardia de regras que ninguém sabia que existiam (porque a fase 1 foi feita correndo).
Esses três pontos são gerenciáveis quando o projeto começa com clareza de objetivos no Comitê e inventário levado a sério. Quando algum dos dois falta, a migração entra em loop e o orçamento estoura.
A migração não é uma decisão para "quando der tempo". É uma decisão de janela: começar quando há clareza sobre o destino e capacidade operacional para conduzir, antes que o custo do legado fique grande demais para ser interrompido.
Em projetos onde o tempo médio entre cutovers de onda é de seis a oito semanas, decisões de migração tomadas em janeiro estão entregando valor mensurável até o terceiro trimestre. Decisões adiadas para "quando der" se tornam projetos eternos.
Se sua operação está nesse ponto (Drools rodando, custo crescendo, autonomia represada), vale conversar com nosso time sobre o roteiro específico para sua arquitetura. Em 45 minutos é possível mapear o tamanho do projeto, o cronograma realista e os pontos onde o risco se concentra. E se quiser ver como a plataforma Abaccus se posiciona como destino dessa migração, a página de alternativa ao Drools traz a comparação direta dos critérios objetivos.
