Hay una conversación que tengo varias veces al año con clientes nuevos. Llegan diciendo "creo que mi aplicación necesita una reescritura completa", me describen los síntomas, y normalmente la respuesta honesta es que no, no hace falta tirarlo todo abajo, pero sí hay tres o cuatro cosas concretas que están sangrando dinero y nadie las está mirando. Otras veces, la conversación es al revés — el cliente piensa que su app "funciona razonable" y resulta que está pidiendo a gritos un refactor.
Refactor no significa reescribir desde cero. Reescribir desde cero es casi siempre una mala idea, y cuando lo es, casi siempre lo es por razones distintas a las técnicas. Refactor significa intervenir en partes concretas del código, la infraestructura o el proceso para que la aplicación deje de costarte más de lo que aporta. Voy a darte siete señales objetivas que, cuando aparecen, suelen indicar que esa intervención toca ya. Y al final, tres señales que parecen graves pero suelen no serlo.
1. Los despliegues tardan más de 30 minutos o dan miedo
Un despliegue saludable en 2026 dura entre 3 y 10 minutos en una app de tamaño medio, se lanza automáticamente desde un commit a una rama protegida, y nadie tiene que vigilar nada. Si el tuyo tarda más, requiere intervención manual, o el equipo cruza los dedos cada vez que se despliega un viernes, hay un problema gordo de proceso.
Los despliegues lentos no son solo molestia: son el síntoma visible de un proceso que desincentiva publicar cambios pequeños y frecuentes. Cuando publicar duele, el equipo acumula cambios para no pasar por el suplicio dos veces. Cuando acumula cambios, cada despliegue es más grande, más arriesgado y más doloroso. Es una espiral que termina con releases mensuales que generan tres bugs en producción cada vez. Romperla cuesta unas semanas de trabajo en CI/CD y se nota inmediatamente en la velocidad del equipo.
2. Más de cinco bugs en producción al mes
Una aplicación madura, en mantenimiento estable, debería generar entre cero y dos incidencias en producción al mes. Si llevas meses con cinco o más bugs serios cada mes — incidencias que afectan a usuarios reales, no warnings de log — tu aplicación está pidiendo intervención. No es que esté "mal escrita", probablemente. Es que algo en el proceso de desarrollo, testing o despliegue se está dejando bugs pasar al cliente.
Lo primero que miro en estos casos es la cobertura de tests automatizados sobre los caminos críticos, no sobre el total. Si tu app procesa pagos, ¿hay tests del flujo de pago end-to-end? Si genera facturas, ¿hay tests del cálculo de impuestos? Muchas veces el equipo se enfoca en tener "alta cobertura" general y descuida los flujos donde un bug cuesta dinero real al cliente o a su negocio.
3. Cero tests automatizados (o "tests" que nadie ejecuta)
No tener tests no es necesariamente grave en una app pequeña que apenas cambia. Pero en cuanto la aplicación crece, tiene varios desarrolladores tocándola, o vive más de dos años, la falta de tests automatizados se convierte en un freno enorme. Cada cambio se vuelve arriesgado, cada refactor se pospone, y el código se osifica.
La peor variante de este problema es el equipo que sí tiene tests escritos, pero el CI los ignora, o llevan meses fallando, o nadie los ejecuta antes de mergear. Eso es peor que no tenerlos: te da una sensación falsa de seguridad mientras los bugs siguen colándose. Si tu pipeline lleva meses con "tests fallando que vamos a arreglar pronto", lleva meses sin tests funcionales.
4. El framework está sin soporte o muy desactualizado
.NET Framework 4.8 sigue funcionando, pero Microsoft no le añade ya características nuevas y solo recibe parches de seguridad. .NET 6 perdió soporte en noviembre de 2024. .NET 8 lo perderá en noviembre de 2026. Si tu app está en versiones sin soporte vigente, no es que vaya a explotar mañana, pero cada mes que pasa estás acumulando deuda y exponiéndote a vulnerabilidades sin parche.
Actualizar el framework no es tan caro como la gente cree, especialmente si el código no es muy retorcido. La parte difícil suelen ser las dependencias antiguas que ya no se mantienen y hay que sustituir, y la integración con sistemas legacy que asumen versiones concretas. Una auditoría de versiones de framework y dependencias se hace en uno o dos días y te dice exactamente qué cuesta ponerte al día.
5. El equipo dice "no se puede tocar X"
Cuando un developer del equipo te dice "esa parte no se toca, es muy delicada", o "si modificamos eso se rompe todo lo demás", o "lo hizo Fulanito hace cinco años y ya no está", estás escuchando código intocable. Y código intocable es código que cada año tiene más probabilidades de explotar cuando menos te lo esperes.
Esto pasa típicamente con módulos centrales — cálculo de comisiones, generación de informes contables, lógica de precios — que se escribieron con prisa, sin tests, y nadie ha querido reescribir porque "ya funciona". Cuando llega el cambio inevitable, lo arreglan con un parche encima del parche, y la deuda crece. Identificar esos módulos, escribirles tests que documenten su comportamiento actual, y luego refactorizarlos paso a paso, es uno de los trabajos más rentables que puede hacer un freelance senior. Lo he visto recuperar el control de una codebase en seis u ocho semanas en proyectos que llevaban dos años bloqueados.
6. Los tiempos de respuesta empeoran año a año
Si tu aplicación tarda hoy el doble en cargar que hace dos años, sin que hayan subido los usuarios concurrentes, algo está mal y no es la nube. Es muy probable que sea la base de datos: queries que escalan mal a medida que crecen los datos, índices que se quedaron obsoletos, o el clásico problema N+1 multiplicándose con el volumen.
Estos problemas son baratos de detectar (un día de profiling con MiniProfiler o equivalente) y normalmente baratos de resolver. Pero hay que hacerlos a tiempo. Cuando un cliente espera ocho segundos a que cargue una pantalla, no espera, abandona. He visto apps que tenían un problema de un solo índice mal configurado y al añadirlo bajaron tiempos de respuesta de 12 segundos a 400 milisegundos. Pero hasta que alguien se sienta a mirarlo de verdad, no aparece.
7. El coste de cloud sube sin que suba el tráfico
Si tu factura de Azure o AWS sube cada trimestre pero los usuarios y los datos no, lo que está pasando es que tu app es cada vez más ineficiente. Más conexiones a base de datos sin cerrar, más memoria que no se libera, más llamadas innecesarias a servicios externos. Y eso lo pagas en infraestructura sin obtener nada a cambio.
Una auditoría de coste cloud bien hecha suele ahorrar entre el 20 y el 40 % de la factura mensual con cambios que no afectan al usuario final. El ROI es inmediato: si tu factura es de 800 € al mes y conseguimos bajarla a 500 €, los 300 € mensuales pagan el trabajo en pocas semanas. Es de los servicios con peor relación calidad-precio que hay en el mercado, en el sentido bueno: cuesta poco y devuelve mucho.
Las 3 falsas señales que confunden a mucho cliente
No todo lo que parece grave lo es. Estas tres son las "alarmas falsas" más comunes con las que llegan los clientes pensando que su app está en crisis cuando en realidad están bien.
Tener muchas líneas de código
El número absoluto de líneas no significa nada por sí mismo. Una app de 50.000 líneas puede ser perfectamente sana, y una de 5.000 puede ser un infierno si está mal estructurada. Lo que importa es la complejidad ciclomática por método, la cohesión de los módulos y si el código es comprensible para alguien que llega nuevo al proyecto. Sonarqube en un día te da una foto honesta de esto.
Ver warnings en los logs
Los logs llenos de warnings asustan, pero la mayoría suelen ser ruido: warnings de librerías de terceros, advertencias sobre features deprecated en versiones futuras, mensajes informativos categorizados como warning por error. Lo que importa son los errors y las excepciones que llegan a producción. Si esos están controlados, los warnings pueden esperar.
"El código es antiguo"
Que un código se escribiera en 2018 no lo hace malo. Si funciona, está testeado, se mantiene, y no tiene dependencias rotas, el código de 2018 es perfectamente válido en 2026. Lo que envejece mal es el código sin tests, sin documentación y con dependencias abandonadas — y eso puede pasar igual con código escrito ayer.
Qué hacer si ves tres o más de estas señales
Si te has reconocido en tres o más de las siete señales reales, lo más sensato es hacer una auditoría técnica antes de plantear cualquier reescritura. La auditoría te da un mapa: qué está sangrando, qué está estable, qué se puede tocar primero, qué hay que dejar para más adelante y qué se puede ignorar.
Sin ese mapa, los presupuestos de "rehacer todo" son enormes y casi siempre acaban mal — porque rehacer una app entera mientras la actual sigue dando servicio es un proyecto monstruoso. Con el mapa, normalmente descubres que dos meses de intervención bien dirigida resuelven el 80 % de los problemas. Y solo si la app está tan podrida que el coste de mantenerla supera al de reemplazarla, entonces sí se plantea reescritura — pero entonces es una decisión con datos, no con pánico.