"¿Y si cambiamos a la aplicación y algo que la planilla venía haciendo en silencio simplemente... deja de pasar?"
Una clienta me dijo esto casi textual mientras estábamos definiendo el alcance de un proyecto para reemplazar la planilla con la que su equipo de operaciones venía manejando el negocio desde hacía seis años. No le preocupaba la interfaz, ni si la nueva aplicación se iba a ver bien. Le preocupaba algo mucho más específico y mucho más difícil de ver: fórmulas que ya nadie recuerda del todo haber escrito, construidas de a un pequeño arreglo por vez durante años, cada una codificando una regla que alguien necesitó en algún martes en particular y que nunca quedó escrita en ningún otro lado.
Ese miedo es completamente razonable, y me preocuparía más un cliente que no lo tuviera. Una planilla que llevó un negocio durante años no es solo datos. Es lógica acumulada, y todo el riesgo de una migración es perder parte de esa lógica en silencio, de una forma que nadie nota hasta que un número sale mal tres meses después. Este es el proceso real que uso para asegurarme de que eso no pase.
Paso uno: leer la planilla como un documento, no como una base de datos
Antes de escribir una sola línea de código, repaso la planilla en sí: cada fórmula, cada tabla pivot, cada macro. No por encima para entender a grandes rasgos qué hace, sino leyendo cada una de verdad para encontrar dónde viven las reglas reales.
Este paso suele descubrir cosas que el propio cliente había olvidado. Una fórmula de precios con una condición enterrada tres niveles adentro que aplica un descuento distinto para un tipo de cliente específico bajo una condición específica. Una macro que da formato a un reporte de una forma muy particular porque, resulta, es exactamente el formato que el contador de alguien exigió hace años. Nada de esto está escrito en ningún documento de requerimientos, porque no existe ningún documento de requerimientos. La planilla es la documentación, lo haya pretendido alguien o no.
Uno de mis propios productos, una plataforma de conciliación de tarjetas que todavía manejo hoy, empezó exactamente así: una gran planilla, con fórmulas y tablas pivot que habían crecido en silencio hasta convertirse en el verdadero libro de reglas de cómo funcionaba la conciliación. La única forma de construir la plataforma correctamente fue repasar esa planilla línea por línea, que es exactamente el mismo paso que hago hoy con la planilla de cada cliente antes de tocar una línea de código de la aplicación.
Paso dos: definir una primera versión chica, no todo de golpe
El instinto, una vez que repasaste toda la planilla, es intentar migrarla entera de una. Yo me opongo a eso siempre. Una primera versión chica, que cubra la parte de la planilla que más importa ahora mismo, se construye y se prueba correcta mucho más rápido que un intento de replicar toda la planilla de una sola vez.
El resto no se pierde. Queda planificado para una fase posterior, y mientras tanto sigue viviendo en la planilla exactamente como siempre. Esta primera versión no necesita ser el panorama completo. Necesita ser la primera porción comprobadamente correcta de ese panorama.
Paso tres: migrar los datos y después verificar los números entre sí
Una vez construida la primera versión, se importan los datos, y ahí llega el paso que realmente responde al miedo que mi clienta nombró al principio de este artículo: se comparan los totales de la aplicación, lado a lado, contra los totales de la planilla. Mismos datos de entrada, mismo período, mismas categorías. Si un número en la aplicación no coincide con el que produce la planilla para los mismos datos exactos, eso no es un error de redondeo para pasar por alto. Es una fórmula que la aplicación todavía no reprodujo correctamente, y se rastrea y se corrige antes de que alguien dependa de la aplicación para algo real.
Esto no es una verificación única. Se corre a través de suficientes escenarios distintos, y a propósito en suficientes casos límite, como el del cliente con el descuento poco habitual, para tener confianza en que la coincidencia no es casualidad sobre un puñado de filas fáciles.
Paso cuatro: correr ambas en paralelo hasta que la aplicación se demuestre
Acá está la parte que debería ser la más tranquilizadora, y en la práctica suele serlo una vez que los clientes la ven funcionar: nadie cambia por fe. El equipo sigue usando la planilla exactamente como antes, y la aplicación corre al lado, durante el tiempo que haga falta, hasta que la aplicación produjo de forma consistente los mismos resultados que la planilla sobre datos reales y en vivo, no solo sobre los casos de prueba de la migración.
Solo una vez que ese período en paralelo demuestra la coincidencia, de forma consistente, sobre suficiente actividad real, se hace el cambio. A nadie se le pide que confíe en el sistema nuevo el primer día. Se le pide que lo vea coincidir con el viejo, una y otra vez, hasta que confiar deja de ser un salto de fe y se convierte en una conclusión obvia a partir de la evidencia que tiene enfrente.
Por qué este orden importa más que el código en sí
El código de una aplicación web que reemplaza una planilla generalmente no es la parte difícil. Leer la planilla con el cuidado suficiente para encontrar cada regla que realmente vive adentro, y después demostrar, número por número, que nada se perdió en el camino, es la parte que realmente te protege.
Si se salta el paso de lectura, migra una suposición de lo que hace la planilla en vez de lo que realmente hace. Si se salta el paso de correr en paralelo, se entera de la diferencia después de que ya te costó algo.
Lo que esto te da a cambio
Hecho de esta manera, el día que finalmente jubiles la planilla no es un salto de fe. Es el último paso de un proceso que ya demostró, con números reales, que nada se perdió en el camino. Los años de lógica enterrados en esas fórmulas no desaparecen en una reescritura. Se trasladan, se verifican, y se llevan hacia algo que de verdad está construido para crecer.
Si su negocio todavía funciona en silencio sobre una planilla de la que depende y que al mismo tiempo te genera nervios, esa es exactamente la conversación que vale la pena tener antes de tocar nada.