Casi todos los equipos con los que trabajamos llegan con la respuesta ya decidida y buscando permiso. Unos quieren tirarlo todo porque el repositorio les da asco. Otros se niegan a tocar nada porque hace tres años alguien intentó una reconstrucción y la empresa casi cierra. Ninguno de los dos grupos ha recorrido las bifurcaciones completas que exige refactorizar o reescribir el árbol de decisión.

Lo que descubrimos después de acompañar 34 procesos de este tipo entre 2021 y 2025 es que la decisión se toma, de media, en la tercera semana. Y en 19 de esos 34 casos se revisó más tarde, cuando ya había un coste hundido de entre 40.000 y 180.000 euros. No es un problema de criterio técnico. Es un problema de orden: se responde la pregunta final antes de haber respondido las cuatro que la condicionan.

Aquí vamos a recorrer el esquema entero, en el orden en que importa, con las cifras que manejamos internamente. Sin la parte cómoda de «depende del contexto».

Por qué la pregunta binaria ya está mal formulada

¿Cuántas opciones reales hay? Si tu respuesta es dos, el problema empieza ahí.

En nuestros proyectos manejamos siete rutas distintas, y solo dos de ellas son los extremos que todo el mundo discute. Entre arreglar lo que hay y partir de una hoja en blanco existen la extracción de servicios por dominio, la sustitución progresiva con un proxy delante, la reconstrucción solo de la capa de presentación, el cambio de motor de datos manteniendo la lógica, y el congelamiento funcional con desarrollo paralelo limitado a producto nuevo. Cinco caminos intermedios que la conversación binaria borra del mapa.

Ese segundo camino tiene nombre propio: el patrón strangler fig consiste en poner una capa de enrutado delante de la aplicación antigua e ir desviando funcionalidad hacia módulos nuevos hasta que lo viejo queda vacío y se apaga. No es una tercera opción filosófica, es la consecuencia práctica de haber respondido bien a los nodos que vienen después.

La cosa es que el lenguaje nos traiciona. Cuando un CTO dice que hay que empezar de cero, en el 70% de los casos que hemos documentado no está describiendo una estrategia técnica: está describiendo un estado emocional respecto a la base existente. Lo comprobamos de forma bastante tonta pero reveladora: en 2023 empezamos a pedir a los equipos que describieran la opción deseada sin usar ninguno de los dos verbos, ni refactorizar ni reescribir. Las descripciones resultantes coincidían con una ruta intermedia en 11 de 16 sesiones. (Sí, nosotros firmamos dos de las cinco que no.)

El coste de plantearlo como un sí o un no

Una decisión binaria obliga a una negociación de suma cero con negocio. Tú pides seis meses, te dan dos, y acabas haciendo media reconstrucción: lo peor de las dos vías. Hemos visto ese resultado exacto en cinco empresas, y en cuatro terminó con la plataforma antigua todavía viva dieciocho meses después del plazo prometido.

Si en vez de una pregunta cerrada presentas un mapa de siete salidas con coste y riesgo asociados, la conversación cambia de registro. Ya no estás pidiendo fe. Estás presentando opciones.

Si el modelo de datos no admite migración, el camino está decidido

La primera bifurcación del árbol no es arquitectónica, es de datos: si tus registros actuales no se pueden transformar al modelo nuevo con una pérdida de información aceptable y dentro de una ventana de mantenimiento que el negocio tolere, la opción de empezar de cero queda eliminada antes de discutirla. No por criterio técnico, sino por aritmética de clientes.

Es la única bifurcación que no admite matices. Antes de hablar de arquitectura, frameworks, deuda técnica o moral de la gente que lo mantiene, hay que mirar el esquema de base de datos. Si la respuesta a la pregunta anterior es no, la discusión sobre rehacerlo todo ha terminado: perderías datos de clientes reales, y eso ya no lo decide ingeniería.

Las tres señales que invalidan la migración

Encontramos siempre las mismas tres. Campos de texto libre usados como almacén de estructuras: un campo notas que contiene JSON a veces, CSV otras veces, y texto humano el resto. Registros con identidad ambigua, donde el mismo cliente real existe como cuatro filas sin relación declarada. Y lo peor, reglas de negocio codificadas en el propio estado de los datos: ese cliente con el campo tipo = 7 que tiene un descuento especial porque en 2019 alguien lo acordó por teléfono y nunca se documentó.

Cómo medirlo en dos días

Nosotros corremos un perfilado de columnas sobre la tabla principal y las cinco más relacionadas. Si más del 15% de ellas tienen cardinalidad o formato inconsistente, la migración limpia está descartada: habrá que arrastrar el esquema antiguo dentro de la aplicación nueva, lo que significa que no estás empezando de cero, estás empezando con la mochila puesta y mintiéndote al respecto.

El otro nodo eliminatorio: la plataforma sin soporte

¿Justifica por sí sola la antigüedad de una tecnología rehacerlo todo? No. Un lenguaje de 2009 con soporte activo y comunidad viva no es un argumento para nada. Lo que sí cierra el árbol de golpe es el fin de vida real: cuando el proveedor ha dejado de publicar parches de seguridad, cuando la versión del motor de datos ya no recibe actualizaciones críticas, o cuando no existe camino de actualización hacia una versión mantenida.

La diferencia entre «es viejo» y «está muerto» es la diferencia entre una preferencia y una obligación. Lo comprobable es si hay un parche disponible para un CVE publicado la semana pasada. Si no lo hay y el soporte extendido de pago tampoco existe, el nodo se cierra y las rutas intermedias se reducen a dos. Si lo hay, pagar ese soporte durante dieciocho meses cuesta habitualmente menos del 5% de lo que cuesta una sustitución completa, y compra tiempo para recorrer el resto del esquema con calma.

Cuando el problema no es el código, sino la ausencia de evidencia

Aquí está la rama más poblada del esquema, y la que menos se recorre. Buena parte de quienes quieren empezar de nuevo no pueden demostrar que lo que hay en producción sea el cuello de botella.

Preguntamos siempre lo mismo: ¿cuánto tarda hoy una funcionalidad media desde la decisión hasta producción? Si la respuesta es «bueno, depende», no hay evidencia, hay percepción. Y la percepción de quien lleva dos años peleándose con el mismo repositorio es la cosa menos fiable del mundo. No porque mienta, sino porque el dolor reciente pesa más que el antiguo y nadie recuerda cuánto se tardaba en 2022.

Creíamos que esto se resolvía midiendo lead time y listo. Luego vimos lo que ocurría en una empresa de logística de Zaragoza: el tiempo de entrega era de once días, pésimo, pero al desglosarlo descubrimos que siete de esos once eran espera de aprobación de producto y validación de negocio. La aplicación era responsable de cuatro días. Una reconstrucción completa, en el mejor escenario, habría recortado dos. Veintidós semanas de trabajo para ganar dos días en un ciclo de once. Cambiamos nuestro protocolo después de aquello: ahora el desglose del tiempo por fase va antes de cualquier recomendación.

Las cuatro métricas mínimas antes de decidir

• Tiempo medio de entrega, desglosado por fase
• Porcentaje de incidencias concentradas en un mismo módulo
• Tiempo de arranque del entorno local para alguien nuevo
• Cobertura de pruebas del camino crítico de ingresos

Con esos cuatro números la conversación se vuelve otra. Si el 80% de las incidencias viven en el 12% del código, no necesitas rehacer nada: necesitas intervenir ese 12%. Nos pasó con un marketplace que facturaba 2,4 millones anuales y quería 400.000 euros de presupuesto para una reconstrucción total. Resultó que el 83% de los errores de los últimos nueve meses venían del módulo de precios. Lo aislamos y lo rehicimos en siete semanas por una fracción de aquello. El resto, feo pero estable, sigue funcionando hoy. Y ahí está la respuesta a una pregunta que casi nadie formula: sí, se pueden tratar partes distintas de la misma aplicación con estrategias opuestas a la vez.

El caso en que la evidencia sí apunta a empezar de nuevo

Existe, claro. Cuando las incidencias están distribuidas uniformemente, cuando ningún módulo se puede modificar sin romper otros tres, y cuando el arranque del entorno local supera las seis horas, el diagnóstico es estructural. (El récord que hemos visto son once horas; el equipo lo llamaba «la liturgia del lunes».) Aun así, antes de llevar cualquier propuesta al comité de dirección conviene partir de evidencia y no de impresiones, y ahí es donde hay que revisar tu repositorio, un desglose formal que entregamos en diez días laborables y que en el 40% de los casos acaba contradiciendo lo que el equipo esperaba oír.

Si tu negocio no puede dejar de entregar durante seis meses

Esta rama es brutalmente simple. Y aun así la saltan casi todos.

Imagina que mañana paras el desarrollo de producto nuevo durante veinticuatro semanas. ¿Qué ocurre? En una empresa con contratos anuales renovables y crecimiento plano, probablemente nada grave. En una que compite con tres rivales lanzando funcionalidad cada seis semanas, significa perder la ventana. Hemos visto los dos finales: una fintech catalana congeló roadmap ocho meses en 2022 y recuperó posición; una herramienta de gestión de turnos hizo lo mismo en 2023 y perdió el 31% de su base de clientes antes del relanzamiento.

Total, que la pregunta no es técnica. Es: ¿cuál es la tasa de abandono mensual si no lanzamos nada? Si está por debajo del 1,5%, tienes margen. Si supera el 3%, la vía de la hoja en blanco está vetada por aritmética, no por opinión, y lo que te queda es la sustitución progresiva entregando valor cada dos semanas.

El escenario del equipo que ya perdió el conocimiento del sistema

Y aquí viene lo bueno, porque es la rama donde más nos equivocamos nosotros durante años.

El razonamiento habitual suena impecable: nadie del equipo original queda, nadie entiende por qué ese módulo hace lo que hace, así que empecemos de nuevo con gente que sí entienda lo que escribe. Lo defendimos en tres proyectos entre 2021 y 2022. En dos de los tres, lo construido replicó comportamientos incorrectos de la aplicación antigua porque nadie sabía cuáles eran los correctos. Acabamos con algo moderno que mentía igual que lo anterior, solo que en TypeScript.

La ausencia de conocimiento no favorece la reconstrucción. La encarece. Cuando no sabes qué hace lo que tienes, tampoco sabes qué especificar, y la especificación es el 60% del coste de una sustitución completa. El código heredado, aunque sea horrible, es la única documentación veraz que existe: hace exactamente lo que hace.

Qué hacemos ahora en este escenario

Invertimos entre tres y cinco semanas en recuperar comportamiento antes de decidir nada: instrumentamos en producción, registramos entradas y salidas reales del camino crítico, y construimos una batería de pruebas de caracterización. ¿Qué es eso exactamente? Una prueba que no verifica lo que el programa debería hacer, sino que congela lo que hace hoy, errores incluidos, para poder cambiarlo después sin romperlo. En el último proyecto de este tipo salieron 212 casos, de los cuales 19 resultaron ser fallos que el negocio llevaba años compensando a mano en hojas de cálculo. Esas cinco semanas convirtieron una propuesta de ocho meses en un plan de catorce semanas de intervención quirúrgica. Algo parecido ocurre cuando el punto de partida es un prototipo que creció sin control y nadie se atrevió a frenar: lo primero que pide el proceso de re-arquitectura de un MVP no es diseñar la solución nueva, sino averiguar con instrumentación qué estaba pasando realmente ahí dentro.

Cuánto cuesta de verdad sostener dos sistemas en paralelo

Ninguna propuesta que hayamos leído incluye bien esta cifra. Ninguna. Y es la que decide si el plan sobrevive al segundo trimestre.

El cálculo que casi todos hacen es: coste del equipo nuevo durante X meses. El real incluye cinco partidas más. Mantenimiento correctivo de la plataforma antigua, que no desaparece mientras tenga clientes dentro. Doble implementación de todo cambio normativo o urgente que llegue en el intervalo. Infraestructura duplicada. Sincronización de datos entre ambos mundos. Y la partida fantasma: la coordinación entre dos equipos que trabajan sobre la misma funcionalidad con supuestos distintos.

Partida	Estimación habitual	Coste real medido
Equipo del sistema nuevo	100%	100%
Correctivo de la plataforma antigua	0-10%	25-35%
Doble implementación de urgencias	No contemplada	12-18%
Infraestructura duplicada	5%	8-11%
Sincronización de datos	No contemplada	10-20%
Coordinación entre equipos	No contemplada	15%

Suma la columna derecha: el presupuesto real oscila entre 1,7 y 2,0 veces lo presentado. En los nueve proyectos donde pudimos auditar el gasto final contra el inicial, la media fue 1,84. El rango bajo fue 1,41, en una empresa con solo once clientes empresariales y cero urgencias normativas. El alto, 2,3.

¿Y cuánto tiempo conviven los dos? La estimación típica es tres meses de solapamiento. La mediana observada en nuestros datos es de catorce meses. Porque el último 5% de clientes nunca migra solo: siempre hay tres cuentas grandes con integraciones propias que requieren negociación comercial, no trabajo técnico.

Qué hacer si ya empezaste de cero y vas tarde

Mira, al final es la situación más frecuente en la que nos llaman. No en la semana cero: en la semana treinta.

La pregunta correcta no es si continuar o abortar. Es: ¿qué porcentaje del valor de negocio está ya cubierto y en producción con clientes reales dentro? Nada de «terminado en desarrollo». En producción, con tráfico. Si ese número supera el 40%, continuar suele ser la salida más barata. Si está por debajo del 15% después de seis meses, el proyecto no va tarde: está fallando estructuralmente, y seguir empujando añade coste sin cambiar la trayectoria.

Entre el 15% y el 40% está la zona incómoda. Ahí la salida que mejor nos ha funcionado es ésta: congelar el alcance pendiente, elegir un único dominio funcional completo, llevarlo a producción con clientes reales en seis semanas, y decidir después con datos de operación en lugar de con optimismo de planificación. Tres de cuatro equipos que aplicaron esto descubrieron que su estimación restante estaba infravalorada entre un 60% y un 150%. Dolió, pero lo supieron en seis semanas y no en nueve meses. Cuando lo que tienes delante lo escribió un generador y no una persona, el cálculo cambia otra vez, porque conviene saber de antemano, con nuestro desglose de qué código genera Bolt, qué parte de lo generado aguanta producción y qué parte habrá que tirar antes de comprometer un plazo con negocio.

Paridad funcional: la definición que evita el limbo

Nadie define esto y por eso la convivencia se eterniza. Nuestra versión operativa es numérica: hay paridad cuando el 100% de los casos de la batería de caracterización pasan en lo nuevo, cuando el 95% del volumen de transacciones del mes anterior se procesa allí sin intervención manual, y cuando cero procesos programados siguen ejecutándose en la plataforma antigua.

El criterio de apagado es distinto y más duro: fecha fijada por contrato, comunicada a clientes con noventa días de antelación, con los datos históricos ya exportados y un plan de reversión con caducidad de catorce días. Sin fecha escrita, el sistema viejo no muere nunca; simplemente deja de tener presupuesto de mantenimiento y empieza a dar fallos que nadie reconoce como propios.

Cómo recorrer este diagrama con tu equipo en una tarde

Cuatro horas. Una sala, una pizarra, y la regla de que nadie puede pronunciar ninguno de los dos verbos hasta la última media hora.

El orden importa más de lo que parece, porque cada bifurcación elimina opciones y ahorra discusión en las siguientes. Si empiezas por la arquitectura ideal, nunca llegarás a mirar el esquema de datos.

1. Perfilar el modelo de datos actual
2. Comprobar el soporte real de la plataforma
3. Desglosar el tiempo de entrega por fase
4. Mapear incidencias por módulo
5. Calcular el abandono si se congela el roadmap
6. Evaluar el conocimiento disponible internamente
7. Estimar la convivencia con el factor 1,84
8. Solo entonces: elegir entre las siete rutas

¿Quién decide al final, ingeniería o negocio? Ninguno en solitario, y ahí es donde se cuelan las decisiones políticas disfrazadas de técnicas. Los nodos uno a cuatro los firma ingeniería porque son medibles; los nodos cinco a siete los firma negocio porque hablan de ingresos y riesgo. Si alguien firma una casilla que no le corresponde, tienes identificado el punto exacto donde la decisión dejó de basarse en datos.

Ruta	Plazo típico	Coste relativo	Riesgo sobre ingresos
Intervención incremental sobre lo existente	4-12 semanas	1x	Bajo, reversible
Sustitución progresiva con proxy	6-18 meses	2,5-4x	Medio, reversible por módulo
Construcción completa desde cero	12-30 meses	6-11x	Alto, casi irreversible

El entregable de la sesión

Una hoja. Siete rutas en filas, y cuatro columnas: semanas estimadas, coste con el multiplicador aplicado, riesgo sobre ingresos, y reversibilidad. Esa última columna es la que nadie incluye y la que más nos ha salvado: una intervención progresiva se puede abandonar en la semana diez sin perder lo hecho. Una sustitución completa, no. Con clientes dentro de medio producto nuevo, la marcha atrás cuesta más que terminar.

¿Funciona siempre esta sesión? No. Hemos tenido dos casos donde la dirección había comprometido el presupuesto públicamente y ningún dato iba a cambiar la decisión. En esos escenarios el valor del ejercicio fue otro: dimensionar bien el gasto antes de empezar, en lugar de pedir tres ampliaciones a lo largo del año.

Conclusión

Lo que casi nadie recorre entero no es un diagrama complicado: son siete preguntas en un orden concreto. Modelo de datos, soporte real de la plataforma, evidencia medida, tolerancia del negocio al silencio, conocimiento disponible, coste real de la convivencia y reversibilidad de la ruta elegida.

Recórrelas en ese orden y la respuesta final suele dejar de ser una apuesta. En nuestra experiencia, cuando un equipo llega al último paso con los seis anteriores resueltos, la elección se vuelve casi obvia y, en el 60% de los casos, ni siquiera es uno de los dos extremos que se discutían al entrar en la sala.