La respuesta corta
Las tres opciones no se encuentran en un mismo continuo. Repair aborda el síntoma, Refactor modifica una implementación sin alterar el comportamiento, y Rebuild cambia el modelo subyacente. La decisión se basa en una pregunta clave: ¿el problema reside en cómo se implementaron las cosas, o en lo que se definió inicialmente?
Si el modelo de datos es sólido y el problema se presenta en automatizaciones complejas y permisos intrincados, entonces es un Refactor. Si el mismo objeto se utiliza en tres procesos contradictorios y no se puede generar informes sobre él, esto indica un problema de raíz, y en ese caso, Rebuild entra en consideración.
Cuatro pruebas decisivas
| Prueba | Apunta a Refactor | Apunta a Rebuild |
|---|---|---|
| Modelo de datos | Válido, sufre de exceso de campos | Objetos que sirven a propósitos contradictorios |
| Origen del problema | Rendimiento, duplicidad de automatizaciones | Imposibilidad de generar informes o de extender |
| Alcance de los usuarios afectados | Parcial, se puede aislar | Universal en todos los procesos |
| Costo de las pruebas de regresión | Se puede probar un área específica | Cualquier cambio requiere regresión completa |
Tres indicadores que apuntan en la misma dirección son suficientes para tomar una decisión. Una división entre los indicadores generalmente significa que el problema es más local de lo que parece.
Por qué un Rebuild es más costoso de lo estimado
La estimación habitual considera la reconstrucción. Sin embargo, casi siempre omite cuatro elementos: la migración de datos históricos con todas sus excepciones acumuladas, la reconstrucción de las integraciones, cada una acordada con terceros, un período de funcionamiento en paralelo donde conviven ambos sistemas, y una capacitación completa y nueva para todos los usuarios.
En la práctica, estos cuatro elementos suelen constituir más de la mitad del costo. Una organización que considera un Rebuild y no los ha valorado está comparando una manzana con media naranja.
El camino práctico: Reemplazo gradual
Incluso cuando la decisión es Rebuild, ejecutarlo como un proyecto de "detener y reemplazar" es un riesgo en sí mismo. El enfoque que funciona es un reemplazo área por área:
- Se construye el nuevo modelo junto al antiguo - nuevos objetos, sin tocar lo existente.
- Se transfiere un proceso completo - con sus usuarios, datos e informes.
- Se desactiva el equivalente antiguo - este es el paso que la mayoría de las organizaciones postergan, y es lo que duplica el proyecto.
- Se repite hasta que el sistema antiguo esté vacío.
El tercer paso es la prueba. Un sistema donde tanto lo antiguo como lo nuevo coexisten en paralelo durante un año ha aumentado los costos y no ha reducido la deuda.
Lo que debe cambiar en cualquier caso
Ambos enfoques fallan si el mecanismo de cambio permanece inalterado. Una gobernanza mínima —quién aprueba un cambio en el modelo, qué pruebas son obligatorias antes de la implementación, y quién es el propietario de cada área— es la condición necesaria para evitar regresar al mismo punto. La priorización de la deuda se detalla en Priorización de la deuda técnica de Salesforce, y los signos de advertencia previos en 8 señales de una actualización de Salesforce.
Resumen
La elección no es entre "reparar" o "empezar de nuevo", sino entre corregir una implementación o corregir una definición. En la mayoría de los casos que parecen ser un Rebuild, se esconde un modelo de datos sólido que ha sido enterrado bajo una década de automatizaciones; esto se limpia en fases, no mediante una eliminación total.