Refactorizar o reescribir un sistema: qué significa cada camino en la práctica
Refactorizar es cambiar la estructura interna del código sin cambiar lo que el sistema hace para el usuario. Reorganizas, separas responsabilidades, cambias bibliotecas y creas pruebas, todo con el sistema en producción. La refactorización de código legado se hace en pasos pequeños, y cada paso puede salir a producción.
Reescribir es construir un sistema nuevo junto al antiguo y reemplazar uno por otro al final. Hay un día de cambio, y hasta entonces la inversión no genera nada que el usuario pueda ver.
Esta diferencia cambia el perfil de riesgo. En la refactorización, el error aparece pronto y es pequeño. En la reescritura completa, el error tiende a aparecer en el momento del cambio, cuando ya se gastó casi todo el presupuesto.
Cabe decir que cambiar de lenguaje no obliga a reescribir. Se puede cambiar el framework, la arquitectura y la interfaz manteniendo el lenguaje y buena parte de la lógica. Muchas discusiones sobre reescribir terminan cuando se separa lo que está mal (la estructura) de lo que está bien (las reglas que la empresa tardó años en acertar).
Por qué la reescritura total suele salir mal
El primer riesgo es perder reglas de negocio escondidas en el código. Un sistema con diez años de uso carga cientos de decisiones que nadie documentó: el descuento que no vale para tal cliente, el redondeo que exige finanzas, el caso especial que creó un contrato antiguo. Nadie las recuerda hasta que el sistema nuevo se equivoca.
El segundo es congelar el producto. Mientras el equipo construye la versión nueva, el sistema antiguo sigue necesitando correcciones y mejoras. O mantienes dos equipos, o dejas de evolucionar el producto durante meses. El negocio no espera, así que los cambios terminan haciéndose dos veces, en el antiguo y en el nuevo.
El tercero es la estimación equivocada. Es fácil estimar lo que se ve (pantallas, informes, registros) y difícil estimar lo que no se ve: integraciones, migración de datos sucios, permisos, rutinas nocturnas. El error más común que vemos es presupuestar la parte visible y descubrir el resto a mitad de camino.
Hay además un cuarto riesgo, más sutil: el efecto del sistema nuevo. El equipo cree que esta vez lo hará todo bien, y el alcance crece. La reescritura se convierte en la oportunidad de incluir todo lo que quedó afuera, y el proyecto deja de ser un reemplazo para convertirse en un producto nuevo, con el plazo y el costo de un producto nuevo.
Cuándo reescribir software desde cero tiene sentido de verdad
Defendemos la reescritura completa en pocos casos, y todos tienen un criterio verificable.
Incluso en esos casos, recomendamos reducir el alcance a lo que el negocio usa hoy. Reescribir todo lo que hacía el sistema antiguo, incluso lo que nadie usa ya, es la forma más cara de empezar.
- La tecnología ya no tiene soporte y no hay camino de actualización: lenguaje o plataforma sin correcciones de seguridad, sin profesionales en el mercado o sin compatibilidad con lo que la empresa necesita usar.
- La arquitectura impide el negocio: por ejemplo, un sistema diseñado para un único cliente que necesita volverse multiempresa, o un diseño que no acepta integración con nada y bloquea cualquier alianza.
- El sistema es pequeño: si rehacerlo lleva pocas semanas y las reglas caben en la cabeza de quien lo usa, el costo de entender el código viejo puede ser mayor que el de escribir de nuevo.
- El sistema ya no se usa como fue diseñado: el proceso de la empresa cambió tanto que lo que existe resuelve un problema que ya terminó.
Cuándo refactorizar es la mejor opción
Refactorizar es mejor cuando el sistema funciona, los usuarios dependen de él y el problema real es que tocarlo se volvió caro o intimidante. Este es el escenario más común: el código corre, pero cada cambio toma el triple de tiempo y rompe algo lejos de allí.
En estos casos, la ganancia está en atacar los puntos que duelen: la parte que cambia todas las semanas, la que siempre se rompe, la que solo una persona entiende. No es necesario arreglarlo todo. Un módulo bien organizado, con pruebas, ya reduce el costo de cambio en esa área.
Otra señal a favor de la refactorización es que el conocimiento del negocio esté en el código y en ningún otro lugar. Si la documentación no existe y el equipo que lo construyó se fue, el código es la única fuente de verdad. Tirarlo es tirar esa memoria.
Si quieres el panorama completo de cómo se organiza este trabajo, nuestra guía sobre modernización de sistemas legados cubre las opciones de punta a punta.
La alternativa intermedia: migración incremental y el patrón strangler
Entre refactorizar por dentro y reescribirlo todo existe un tercer camino, y es el que más recomendamos para sistemas medianos y grandes: la migración incremental. El patrón más conocido se llama strangler, o higuera estranguladora, en referencia a una planta que crece alrededor del árbol hasta reemplazarlo.
En la práctica, colocas una capa delante del sistema antiguo, que decide a dónde va cada solicitud. Tomas un módulo, lo reconstruyes en la tecnología nueva y desvías solo ese tráfico. El resto sigue en el sistema viejo. Repites, módulo a módulo, hasta que el antiguo ya no reciba nada y pueda apagarse.
Las ventajas son concretas: cada módulo pasa a producción por separado, el error queda contenido, se puede volver atrás desviando el tráfico de regreso, y el producto sigue evolucionando. Además, aprendes con los primeros módulos y ajustas la estimación de los siguientes con datos reales.
El punto de atención es la base de datos. Si el sistema nuevo y el antiguo escriben en las mismas tablas sin cuidado, se estorban mutuamente. Define quién es dueño de cada dato en cada etapa y planifica la sincronización. Detallamos este tipo de cuidados en cómo migrar un sistema PHP antiguo sin detener la operación.
Este es el formato que seguimos en nuestra área de modernización de sistemas legados: etapas pequeñas, sistema en línea todo el tiempo y mantenimiento continuo después.
Preguntas para decidir entre refactorizar y reescribir
Antes de elegir, responde con honestidad a estas preguntas. Si varias respuestas son vagas, el problema es la falta de información, y el primer paso es un diagnóstico, no una decisión.
- ¿La tecnología actual todavía recibe correcciones de seguridad y hay profesionales disponibles en el mercado?
- ¿Sabemos enumerar las reglas de negocio que aplica el sistema, o solo existen en el código?
- ¿Existen pruebas automatizadas? Sin ellas, cualquier cambio, ya sea refactorizar o reescribir, se hace a ciegas.
- ¿Qué frena hoy al negocio: el costo de cada cambio, la inestabilidad, la falta de integración o un límite de arquitectura?
- ¿Podemos mantener el producto evolucionando durante meses sin entregar nada nuevo? Si no, la reescritura total queda descartada.
- ¿Cuántos módulos tiene el sistema y cuáles son independientes? Cuanto más separables, más viable es la migración incremental.
- ¿Quien entiende el sistema sigue en la empresa? Si esa persona se va a mitad del proyecto, ¿qué pasa?
- ¿Cuál es el costo de equivocarse? Un sistema que detiene la operación y un informe interno requieren apetitos de riesgo distintos.
Hoja de ruta de decisión en seis pasos
Esta es la hoja de ruta que usamos para llegar a una decisión que se sostenga ante la dirección.
El paso seis es el que más evita el arrepentimiento. Una muestra pequeña y real muestra, con datos de tu sistema, cuánto cuesta extraer una regla, migrar un dato y probar el resultado. Eso vale más que cualquier estimación hecha solo mirando la pantalla. Si quieres ver cómo queda antes de comprometerte, puedes pedir un prototipo gratis. Y para tener un orden de magnitud de la inversión, mira de qué depende cuánto cuesta modernizar un sistema legado.
- Paso 1: define el problema de negocio en una frase (por ejemplo, lanzar una funcionalidad lleva meses por culpa del código), no el problema técnico.
- Paso 2: haz el inventario: módulos, integraciones, bases de datos, rutinas programadas y quién usa cada parte.
- Paso 3: verifica los criterios de reescritura: tecnología sin soporte, arquitectura que bloquea el negocio, sistema pequeño. Si ninguno se aplica, descarta la reescritura completa.
- Paso 4: levanta las reglas de negocio, conversando con los usuarios y leyendo el código de las áreas críticas, y transfórmalas en pruebas.
- Paso 5: ordena los módulos por dolor y por independencia. Empieza por lo que duele y se puede separar.
- Paso 6: haz un piloto en un módulo pequeño, mide el esfuerzo y el riesgo, y solo entonces decide el formato y el presupuesto del resto.
Errores comunes al decidir
El error más común que vemos es decidir por la tecnología y no por el problema. Alguien quiere usar la herramienta de moda y la reescritura se vuelve una justificación. El segundo es subestimar la migración de datos, que suele ser la parte más lenta y la que más sorprende.
También es frecuente tratar la decisión como binaria. Refactorizar un módulo, reescribir otro que es pequeño y estrangular el resto es una combinación perfectamente legítima. Y, por último, planificar la modernización sin prever mantenimiento después: el sistema nuevo envejece igual que el antiguo si nadie lo cuida.
De nuestra experiencia
En SKAD, refactorizamos con apoyo de IA los sistemas SyncStop, 4Car, KaraokeApp, The Bee App y DEM (inspección de equipos). Todos eran PHP puro con jQuery y Bootstrap, y las aplicaciones usaban Cordova.
Hoy funcionan en PHP 8.3 con Slim 4 en la API, React con Vite en la web y React Native con Expo en la app. Mantuvimos el lenguaje PHP y cambiamos el framework y la arquitectura, sin partir de una página en blanco.
Después de la refactorización, el mantenimiento de estos sistemas se volvió más liviano. Por eso, cuando el sistema funciona y el problema es la estructura, nuestra inclinación es refactorizar y migrar por etapas, y no empezar todo de nuevo.
Preguntas frecuentes
¿Reescribir un sistema desde cero es siempre una mala idea?
No. Tiene sentido cuando la tecnología ya no tiene soporte, la arquitectura impide el negocio o el sistema es pequeño. Fuera de esos casos, el riesgo suele ser mayor que el beneficio.
¿Cuánto tiempo lleva refactorizar o reescribir un sistema?
Depende del tamaño, del número de integraciones, de la calidad de los datos y de la existencia de pruebas. Por eso desconfía de cualquier plazo dado sin mirar el sistema; un piloto en un módulo ofrece una base real.
¿Qué es el patrón strangler?
Es una forma de migración en la que una capa delante del sistema antiguo desvía, módulo a módulo, el tráfico hacia la versión nueva. El sistema viejo se va vaciando hasta que se puede apagar.
¿Se puede refactorizar un sistema sin pruebas automatizadas?
Se puede, pero con más riesgo. Lo mejor es crear pruebas para las reglas críticas antes de tocar nada, así sabes si el cambio preservó el comportamiento.
¿Refactorizar o reescribir: qué sale más barato?
A corto plazo la reescritura parece más simple, pero el costo real suele aparecer en reglas olvidadas, migración de datos y tiempo sin evolucionar el producto. La refactorización incremental distribuye el gasto y permite detenerse o corregir el rumbo.
Conclusión
Antes de aprobar una reescritura o una refactorización, pide un diagnóstico del sistema actual: inventario de módulos, reglas críticas, estado de las pruebas y un piloto en una parte pequeña. Con eso en la mano, la decisión deja de ser una apuesta. Si quieres, nuestro equipo hace ese diagnóstico contigo: escríbenos por WhatsApp con el botón de abajo y cuéntanos qué hace hoy tu sistema legado y dónde se atasca.