Cuánto cuesta modernizar un sistema: la respuesta honesta
No existe un precio de tabla, y conviene desconfiar de quien presenta uno. Dos sistemas con la misma antigüedad y el mismo número de pantallas pueden tener costos muy distintos, porque lo que pesa es lo que está escondido por debajo.
En la práctica, el costo es el resultado del esfuerzo necesario para entender el sistema, cambiar lo que hay que cambiar y demostrar que sigue funcionando igual. El tercer punto suele ser el más subestimado.
Estos son los ocho factores que más pesan en el presupuesto de modernización de software. Los próximos bloques explican cada uno.
- Tamaño y estado del código: cuánto hay y qué tan enredado está.
- Documentación: si existe alguna y si todavía refleja lo que hace el sistema.
- Pruebas: si hay algo que demuestre que un cambio no rompió otra cosa.
- Integraciones: con cuántos sistemas, servicios y equipos se comunica.
- Base de datos: estructura, volumen, calidad de los datos y reglas guardadas dentro de ella.
- Cantidad de perfiles y módulos: cada tipo de usuario y cada área del sistema multiplica reglas y pantallas.
- Riesgo de la operación: cuánto se detiene la empresa si el sistema se cae.
- Equipo del cliente: quién conoce las reglas de negocio y tiene tiempo para validar.
Código, documentación y pruebas: dónde vive el esfuerzo oculto
El tamaño del código importa, pero el estado importa más. Un sistema grande y ordenado, con responsabilidades separadas, es más barato de modernizar que un sistema pequeño donde la regla de negocio, el acceso a datos y la pantalla están mezclados en el mismo archivo.
La documentación define cuánto tiempo se gasta solo en entender. Sin ella, parte del trabajo es arqueología: leer código, ejecutar el sistema, preguntar a quienes lo usan y descubrir reglas que nadie recordaba que existían. Ese tiempo entra en el costo, aunque no aparezca en la propuesta.
Las pruebas son el factor más ignorado. Sin pruebas automatizadas, cada cambio exige una verificación manual para garantizar que se preservó el comportamiento anterior. Crear una base mínima de pruebas en las partes críticas antes de tocar nada suele ser una de las mejores inversiones del proyecto, porque abarata todas las etapas siguientes.
Integraciones, base de datos, perfiles y módulos
Las integraciones son donde más se desborda la estimación. Cada conexión con otro sistema, API, archivo de intercambio o equipo tiene su propio formato, sus propias excepciones y, casi siempre, alguien del otro lado que necesita participar. El error más común es contar la integración como un único ítem, sin mirar qué transporta realmente.
La base de datos pesa por dos motivos. Primero, la calidad de los datos: duplicados, campos usados para más de una finalidad y registros antiguos inconsistentes complican la migración. Segundo, la lógica escondida: procedimientos almacenados, disparadores y rutinas programadas que ejecutan reglas de negocio sin que nadie las recuerde.
Los perfiles y los módulos entran en la cuenta de forma casi lineal. Un sistema con un único tipo de usuario y pocos módulos es un problema. Un sistema con perfiles de administrador, operador, cliente y socio, cada uno con permisos y pantallas distintos, son varios problemas a la vez. Por eso, listar módulos y perfiles es el primer paso de cualquier estimación seria.
Riesgo de la operación y equipo del cliente
Cuanto más depende la empresa del sistema a cada hora, más cuidado exige la modernización, y el cuidado cuesta. Un sistema que puede estar fuera de línea por la noche permite un tipo de migración. Un sistema que atiende clientes todo el día exige ejecución en paralelo, plan de retorno y validación en cada etapa.
El equipo del cliente también entra en el precio, aunque no aparezca como una línea de costo. Si nadie en la empresa conoce las reglas o tiene tiempo para validar entregas, el proyecto avanza despacio, vuelve atrás para corregir malentendidos y cuesta más. Un responsable interno con poder de decisión, aunque sea por pocas horas a la semana, reduce ese riesgo de forma visible.
Existe además la dependencia de las personas. Si el sistema solo lo entiende un desarrollador, la modernización debe empezar capturando lo que él sabe. Hacerlo mientras todavía está disponible es mucho más barato que hacerlo después.
Modernizar o seguir como está: la cuenta que casi nadie hace
La comparación suele hacerse mal: de un lado, el valor de un proyecto; del otro, cero. Pero seguir como está no cuesta cero. Cuesta un mantenimiento cada vez más lento, correcciones que rompen otras partes, dificultad para contratar a quien trabaje con la tecnología antigua y funcionalidades nuevas que llevan mucho más tiempo del que deberían.
Está además el riesgo, que no aparece en ninguna planilla de pagos hasta que ocurre: dependencias sin soporte y sin correcciones de seguridad, servidores que nadie sabe recrear y conocimiento concentrado en una o dos personas. El costo de una caída o de una falla de seguridad suele superar al de una modernización planificada.
Esto no significa que modernizar siempre valga la pena. Si el sistema es estable, cambió poco en los últimos años, tiene pocas probabilidades de crecer y el mantenimiento es barato, dejarlo como está puede ser la decisión correcta. Se lo decimos a los clientes cuando es el caso.
- Suma el tiempo que el equipo gasta hoy en mantenimiento y correcciones, incluido lo que le quita a su trabajo principal.
- Estima cuánto tarda en publicarse un cambio simple y compáralo con lo que tardaría en un sistema ordenado.
- Haz una lista de las personas y los componentes sin los cuales el sistema no se puede mantener.
- Pregunta qué le pasa al negocio si el sistema queda fuera de línea durante un día entero.
Cómo el enfoque incremental distribuye la inversión
Reescribirlo todo de una vez concentra el gasto en un único bloque y posterga el retorno hasta el día del cambio. Si algo sale mal, el perjuicio es grande y el dinero ya se gastó. En SKAD preferimos modernizar por partes, sin detener la operación: un módulo a la vez, con el sistema antiguo y el nuevo conviviendo durante la transición.
En la práctica, la inversión queda dividida en etapas con entregas verificables. Ves el resultado de una etapa antes de aprobar la siguiente, puedes cambiar la prioridad si el negocio cambia y además te das cuenta pronto si la estimación estaba equivocada. Esto no hace que el proyecto sea necesariamente más barato en total, pero vuelve el gasto previsible y reversible. Si quieres profundizar en la decisión entre ajustar lo que existe y empezar de cero, lee cómo decidir entre refactorizar y reescribir.
También recomendamos empezar por lo que más duele o por lo que más bloquea al resto, y no por lo que parece más fácil. Así la primera etapa ya reduce el costo de mantenimiento. Conoce cómo llevamos adelante este proceso en nuestro enfoque de modernización de sistemas legados.
Qué reduce la IA en el costo de migración de un sistema legado (y qué no reduce)
La IA ayuda mucho en las partes repetitivas: leer y explicar código desconocido, generar una primera versión de la documentación, convertir fragmentos de una estructura a otra, escribir pruebas iniciales y señalar patrones duplicados. Este tipo de trabajo consumía muchas horas, y es donde el esfuerzo baja de forma más clara.
Lo que la IA no elimina es la revisión humana. Se equivoca con seguridad, no conoce las reglas de tu negocio y no sabe cuáles comportamientos extraños del sistema antiguo son errores y cuáles son funcionalidades de las que dependen los usuarios. Todo código generado pasa por la revisión de un ingeniero y por pruebas antes de ir a producción.
Desconfía de las promesas de que la IA moderniza todo sola y por una fracción del costo. Lo que hace es redirigir el tiempo del equipo: menos tipeo y conversión manual, más decisiones de arquitectura, validación y cuidado con las integraciones y los datos, que siguen siendo los puntos más delicados.
Cómo pedir un diagnóstico y un presupuesto de modernización de software comparable
Empieza por el diagnóstico. Antes de hablar de precio, una buena propuesta presupone revisar el código, la base de datos, las integraciones y la forma en que se usa el sistema. Cuando el presupuesto llega sin ninguno de estos análisis, el número es solo una suposición con apariencia de precisión.
Para comparar propuestas, pídeles a todos los proveedores la misma estructura. Esto es lo que debe constar en cada una:
- Alcance dividido por módulos o etapas, con lo que entra y lo que queda fuera.
- Supuestos sobre código, base de datos, integraciones y acceso a quienes conocen el sistema.
- Cómo el sistema antiguo sigue funcionando durante la transición y cómo es el plan de retorno.
- Estrategia de pruebas y criterios para dar cada etapa por concluida.
- Papel de la IA en el proceso y cómo se hace la revisión humana.
- Qué ocurre después de la entrega: mantenimiento, soporte y quién responde por los problemas.
Errores comunes al pedir y evaluar presupuestos
El error más común que se ve es elegir la propuesta más barata sin comparar los supuestos. Dos propuestas con valores distintos casi siempre están presupuestando alcances distintos, y la diferencia vuelve más tarde como adicional.
Otro error es exigir un precio cerrado para un sistema que nadie analizó. Si el proveedor acepta, puso la incertidumbre en el precio o la cobrará después. Dividir el trabajo en diagnóstico y etapas suele ser más honesto para ambas partes.
Por último, olvidar el mantenimiento. Modernizar y luego quedarse sin apoyo recrea el problema en pocos años. Para entender mejor cómo se estima cada tipo de proyecto, consulta también cuánto cuesta un sistema o app a medida. Y si quieres ver el resultado antes de decidir, puedes pedir un prototipo gratis de cómo sería el nuevo sistema.
De nuestra experiencia
En SKAD refactorizamos con apoyo de IA los sistemas SyncStop, 4Car, KaraokeApp, The Bee App y DEM, este último de inspección de equipos. Todos estaban hechos en PHP puro con jQuery y Bootstrap, y las aplicaciones usaban Cordova.
Hoy esos sistemas funcionan con PHP 8.3 y Slim 4 en la API, React con Vite en la web y React Native con Expo en la app. Mantuvimos el lenguaje PHP; lo que cambió fue el framework y la arquitectura. Después de la refactorización, el mantenimiento de estos sistemas quedó más liviano.
Preguntas frecuentes
¿Cuánto cuesta modernizar un sistema legado?
Depende del tamaño y el estado del código, la documentación, las pruebas, las integraciones, la base de datos, los perfiles, los módulos y el riesgo de la operación. Solo un diagnóstico del sistema permite estimar con algún criterio.
¿Modernizar sale más barato que reescribir desde cero?
No siempre, pero suele ser menos riesgoso, porque la inversión se divide en etapas y la operación continúa. Cuando el código está tan deteriorado que aprovecharlo no vale la pena, la reescritura puede ser la mejor opción.
¿La IA reduce el costo de la modernización?
Reduce el esfuerzo en tareas repetitivas, como entender código, documentar, convertir fragmentos y crear pruebas iniciales. La revisión, las decisiones de arquitectura y la validación siguen siendo trabajo humano.
¿Se puede modernizar sin detener la empresa?
Sí, con el enfoque incremental. El sistema antiguo y el nuevo conviven mientras cada módulo se migra y se valida, con plan de retorno en cada etapa.
¿Qué debo tener listo antes de pedir un presupuesto?
Acceso al código y a la base de datos, lista de módulos, perfiles e integraciones, y una persona que conozca las reglas de negocio. Si falta algo, el diagnóstico ayuda a reunirlo.
Conclusión
Antes de pedir cualquier precio, reúne lo que ya existe: acceso al código y a la base de datos, la lista de módulos, perfiles e integraciones, y el nombre de quien conoce las reglas del negocio. Con eso en mano, el diagnóstico es rápido y el presupuesto deja de ser una conjetura. Si quieres empezar por ahí, escribe a SKAD por WhatsApp y pide un diagnóstico de tu sistema legado.