A Resposta Curta
As três opções não estão no mesmo contínuo. Repair trata o sintoma, Refactor modifica a implementação sem alterar o comportamento, e Rebuild altera o modelo subjacente. A decisão é determinada por uma pergunta: o problema reside na forma como as coisas foram implementadas ou no que foi definido desde o início?
Se o modelo de dados estiver correto e a dor for devido a automações complicadas e permissões intrincadas, isso é um Refactor. Se o mesmo objeto for usado por três processos conflitantes e não for possível gerar relatórios sobre ele, isso é a raiz do problema, e então o Rebuild entra em pauta.
Quatro Testes Decisivos
| Teste | Aponta para Refactor | Aponta para Rebuild |
|---|---|---|
| Modelo de Dados | Adequado, sofre com excesso de campos | Objetos que atendem a propósitos conflitantes |
| Origem da Dor | Desempenho, duplicação de automações | Impossibilidade de relatar ou expandir |
| Escopo dos Usuários Afetados | Parcial, pode ser isolado | Abrangente em todos os processos |
| Custo do Reteste | Pode-se testar uma única área | Qualquer alteração requer regressão completa |
Três linhas que apontam para a mesma direção são suficientes para a decisão. A divisão entre as linhas geralmente significa que o problema é mais local do que parece.
Por Que o Rebuild É Mais Caro do Que o Estimado
A estimativa usual considera apenas a reconstrução. Ela quase sempre ignora quatro itens: a migração de dados históricos com todas as exceções acumuladas, a reconstrução das integrações, cada uma acordada com um terceiro, um período de execução paralela em que ambos os sistemas convivem, e o treinamento completo para todos os usuários.
Na prática, esses quatro itens geralmente representam mais da metade do custo. Uma organização que considera um Rebuild e não os precificou está comparando maçãs com meias laranjas.
O Roteiro Prático: Substituição Gradual
Mesmo quando a decisão é Rebuild, executá-lo como um projeto "parar e substituir" é o próprio risco. O caminho que funciona é a substituição área por área:
- Construa o novo modelo ao lado do antigo - novos objetos, sem tocar no existente.
- Migre um processo completo - com seus usuários, dados e relatórios.
- Desligue o equivalente antigo - este é o passo que a maioria das organizações adia, e é o que torna o projeto duplicado.
- Repita até que o antigo esteja vazio.
O terceiro passo é o teste. Um sistema em que o antigo e o novo convivem em paralelo por um ano gerou custos e não reduziu débitos.
O Que Precisa Mudar em Qualquer Caso
Ambos os caminhos falham se o mecanismo de mudança permanecer o mesmo. Uma governança mínima – quem aprova uma mudança no modelo, qual teste é obrigatório antes da implantação e quem é o proprietário de cada área – é a condição que impede o retorno ao mesmo ponto. A priorização do débito em si é detalhada em Priorização de Dívida Técnica Salesforce, e os sinais de alerta em 8 Sinais de uma Atualização de Sistema Salesforce.
Resumo
A escolha não está entre "consertar" e "recomeçar", mas entre corrigir a implementação e corrigir a definição. Na maioria dos casos que parecem ser um Rebuild, um modelo de dados saudável está oculto, enterrado sob uma década de automações – e isso se limpa em ondas, não com uma varredura.