Como escolher um parceiro para refatorar um monólito crítico sem parar a operação

A decisão técnica correta quase nunca é binária. Em sistemas maduros, a melhor resposta costuma ser uma combinação de refatoração incremental com estrangulamento de domínios críticos, deixando a reescrita total só para casos extremos. Quando um fornecedor vende "reconstrução completa" como solução padrão, acenda o alerta. Reescrever parece limpo no slide, mas costuma introduzir risco de prazo, perda de conhecimento e quebra de funcionalidades que o negócio já depende para funcionar. O CFO e o CTO precisam olhar para o mesmo quadro: custo de continuar, custo de mexer e custo de não fazer nada. Se o sistema falha em performance, exige deploys lentos e consome uma parte desproporcional do time em correções, isso já é custo operacional. Esse raciocínio é o mesmo que usamos quando ajudamos empresas a transformar backlog técnico em roadmap de valor, como discutido em como transformar backlog técnico em roadmap de produto orientado por valor. Quando a plataforma ainda entrega receita, atende clientes enterprise ou sustenta operação regulada, a decisão costuma ser por etapas. Primeiro estabiliza, depois isola o que mais dói, então cria módulos com limites claros, e só depois corta dependências maiores. Se você quiser um bom parceiro, procure quem consiga explicar esse caminho com clareza, inclusive dizendo o que não vai fazer agora. A OrbeSoft trabalha muito nessa lógica de reduzir risco antes de prometer velocidade. Em vez de começar com uma grande entrega de código, começamos com audit técnico, mapeamento de dependências e desenho do plano de transição. Isso faz diferença especialmente quando o monólito está acoplado a processos críticos ou integrações que não podem parar.

Um plano de transição bem desenhado reduz ansiedade interna e evita o erro de tentar modernizar tudo de uma vez. O primeiro bloco deve ser de observação e auditoria, com acesso a repositórios, pipelines, incidentes, métricas e entrevistas com quem opera o sistema. Sem isso, qualquer estimativa é frágil. A partir daí, a equipe define domínios prioritários, checkpoints de risco e uma rota de entregas que preserve a operação. Nos primeiros 30 dias, o foco é entender o comportamento real da aplicação, identificar módulos de maior impacto e criar visibilidade. Nos 30 dias seguintes, entra a primeira onda de refatoração com baixo risco, testes e medições claras. Nos últimos 30 dias, o trabalho precisa consolidar padrões, transferir conhecimento e deixar o time interno com artefatos que sustentem a próxima etapa. Esse modelo combina bem com times que já estão sobrecarregados e precisam de ajuda para destravar sem perder a governança. Se a sua empresa também está avaliando a melhor forma de receber um time externo, vale cruzar esse plano com como preparar sua empresa para receber uma equipe alocada e com governança prática para equipes alocadas, porque a qualidade da transição depende tanto do parceiro quanto da sua estrutura interna. Na prática, a entrega boa não termina com "código pronto". Ela termina com documentação útil, critérios de rollback, monitoramento estabelecido, decisão clara sobre ownership e um time interno menos dependente de heróis. Se isso não estiver no plano, a compra está incompleta.

O primeiro erro é comprar velocidade sem diagnóstico. Quando a empresa contrata uma squad para "fazer acontecer" sem entender onde está o gargalo, normalmente acaba pagando para automatizar uma decisão errada. O segundo erro é aceitar uma proposta que não separa estabilização, refatoração e migração. Isso mistura tudo e impede qualquer leitura de progresso. Outro problema recorrente é não definir quem decide o quê. Em projetos críticos, a tensão entre CEO e CTO é estrutural, não pessoal. O CEO quer previsibilidade de negócio, o CTO quer sustentabilidade técnica. Um parceiro maduro precisa atuar exatamente nesse ponto, ajudando a traduzir risco técnico em decisão executiva. Esse tipo de alinhamento é o mesmo que abordamos em como alinhar CEO e CTO ao contratar um squad externo. Também vemos falhas quando não existe estratégia de saída. O sistema é refatorado, mas o conhecimento continua concentrado em uma pessoa ou em um fornecedor que não documentou o suficiente. Para evitar isso, inclua code escrow quando fizer sentido, plano formal de transferência e critérios de encerramento de fase. Em contratos alocados, code escrow e cláusulas de saída podem ser o que separa autonomia real de dependência disfarçada. Por fim, cuidado com propostas que vendem "modernização total" sem tocar em observabilidade, testes e operação. Em sistemas que suportam operação real, a refatoração precisa ser pensada como mudança de sistema e de processo. Sem isso, a empresa troca um monólito por outro problema mais elegante.