Cuánto cuesta modernizar un sistema legacy y qué lo define

El costo de modernizar un sistema legacy depende sobre todo de qué tan grande y enredado está el sistema actual, en qué estado están sus datos y qué estrategia eliges: no cuesta lo mismo llevar un sistema a la nube sin tocar el código que reescribirlo desde cero. Por eso dos proyectos de “modernización” pueden tener presupuestos muy distintos. La cifra confiable sale de un diagnóstico del código, la base de datos y los procesos, y conviene invertirla por etapas.

Esta guía no repite cómo se ejecuta una migración; eso lo explicamos paso a paso en cómo modernizar un sistema legado sin detener tu operación. Aquí nos enfocamos en el dinero: qué mueve el costo, cuánto pesa cada estrategia en términos relativos, cuánto te cuesta no hacer nada y cómo pedir y comparar cotizaciones para no pagar de más ni de menos.

¿Qué es un sistema legacy y por qué su modernización cuesta distinto en cada caso?

Definición rápida: un sistema legacy (o sistema legado, o heredado) es software que sigue sosteniendo procesos críticos de tu negocio, pero cuya tecnología, código o dependencia de personas hacen que mantenerlo, cambiarlo o integrarlo sea cada vez más caro y riesgoso.

La edad no es lo que lo define. Un sistema de 2012 bien mantenido puede no ser legado, y un libro de Excel con macros de hace tres años que solo entiende una persona sí lo es. Lo que hace que la modernización de sistemas tenga precios tan distintos es que cada sistema heredado esconde una cantidad diferente de reglas, datos y conexiones que hay que conservar.

Piensa en dos casos hipotéticos: una empresa con un sistema PHP ordenado sobre un servidor físico viejo, y otra con un sistema en Visual Basic 6 sin documentación que además exporta archivos a contabilidad y al banco. Las dos piden “modernizar”, pero el trabajo no se parece en nada.

¿Qué factores definen el costo de modernizar un sistema legacy?

1. Tamaño y reglas de negocio del sistema actual

El tamaño no se mide en pantallas, sino en reglas. Un catálogo de clientes es sencillo; un cálculo de precios con listas por cliente, descuentos por volumen, comisiones escalonadas y redondeos fiscales no lo es, aunque ocupe una sola ventana. En los sistemas heredados esas reglas suelen estar escondidas en el código, en procedimientos almacenados o en macros, y hay que descubrirlas antes de reproducirlas. Entre más reglas y más excepciones, más horas de análisis, desarrollo y pruebas.

2. Calidad y volumen de los datos

Migrar datos limpios es rápido. Migrar datos sucios es donde se va el presupuesto: clientes duplicados con distinto RFC, productos con la misma clave, fechas capturadas como texto, saldos que no cuadran desde hace años. El volumen también importa, pero menos que la calidad. Un millón de registros bien estructurados da menos trabajo que veinte mil capturados sin validaciones.

3. Documentación existente

Si hay documentación o al menos una persona que conoce el sistema y tiene tiempo para explicarlo, el diagnóstico se acorta mucho. Si no, hay que reconstruir el conocimiento leyendo código y entrevistando usuarios, y ese trabajo se cotiza.

4. Integraciones

Cada conexión con otro sistema suma: timbrado de facturación electrónica CFDI 4.0, archivos que se envían a contabilidad, conciliaciones bancarias, tienda en línea, paqueterías o un segundo sistema que lee la misma base de datos. Hay que conservar las que funcionan, reemplazar las frágiles y a veces crear nuevas. Explicamos cómo se diseñan en integración de sistemas por API.

5. Si hay que operar en paralelo

Si tu negocio no puede detenerse ni un día, el proyecto tiene que contemplar una etapa en la que el sistema viejo y el nuevo conviven: sincronización de datos entre ambos, comparación de resultados y un plan de regreso. Esa red de seguridad tiene un costo, pero casi siempre es menor que el de un arranque fallido. Un sistema que se puede apagar un fin de semana sin consecuencias es más barato de migrar.

6. La estrategia elegida

Es el factor que más mueve el total y el único que tú controlas directamente. Lo detallamos en la siguiente sección.

7. Otros factores que conviene no olvidar

• Infraestructura y licencias: son costos recurrentes, no únicos.
• Disponibilidad de tu equipo: si nadie de tu lado puede validar, el proyecto se alarga.
• Mejoras que se cuelan: “ya que estamos, agreguemos…” infla cualquier presupuesto. Primero se busca que el sistema nuevo haga lo mismo que el viejo; las mejoras van después.

¿Qué soluciones de modernización de sistemas legacy existen y cuánto pesa cada una?

No existe una sola forma de modernizar. Estas son las siete soluciones más comunes, ordenadas aproximadamente de menor a mayor esfuerzo. En un mismo proyecto es normal combinar dos o tres según el módulo.

Estrategia	Qué cambia	Complejidad relativa	Tiempo típico (orientativo)	Cuándo conviene
Rehospedar (llevar a la nube)	Solo la infraestructura	Baja	Semanas	Servidor físico en riesgo, sin respaldos o sin acceso remoto
Actualizar versión	Lenguaje, framework o base de datos	Baja a media	Semanas a algunos meses	El código sirve, pero la plataforma salió de soporte
Envolver con API	Se agrega una capa de integración	Baja a media	Semanas a algunos meses	Necesitas conectar el sistema con otros sin reescribirlo aún
Refactorizar	Estructura interna del código	Media	Meses, de forma continua	El lenguaje sigue vigente y el código es rescatable
Reemplazo gradual (strangler fig)	Todo, módulo por módulo	Media a alta, repartida en etapas	Varios meses a más de un año	Sistemas críticos que no pueden detenerse
Reescritura completa	Todo de una vez	Alta	Varios meses a más de un año	Sistemas pequeños o con reglas muy bien documentadas
Sustituir por SaaS o ERP comercial	Se adopta un producto existente	Variable: baja en desarrollo, alta en adaptación de procesos	Semanas a varios meses	Procesos estándar, sin una ventaja competitiva en el software

Los tiempos son orientativos y no son una cotización. Dependen del tamaño del sistema, del estado de los datos y de la disponibilidad de tu equipo para validar.

Rehospedar o llevar a la nube

Mueves el sistema y su base de datos a un servidor en la nube sin tocar el código. Ganas respaldos automáticos, disponibilidad y acceso desde cualquier lugar, pero el software sigue siendo el mismo. Es el paso más barato y suele ser el primero cuando el riesgo inmediato es un servidor viejo en un cuarto de la oficina. Lo ofrecemos dentro de nube e infraestructura.

Actualizar versión

Llevas el sistema a una versión con soporte del lenguaje, el framework o la base de datos, con los ajustes mínimos para que siga funcionando. Un ejemplo típico es PHP: según el calendario oficial de versiones de PHP (consultado en noviembre de 2026), PHP 8.2 deja de recibir parches de seguridad el 31 de diciembre de 2026, y todas las versiones anteriores ya no los reciben. Explicamos cómo hacerlo con cuidado en actualizar PHP sin romper tu sistema.

Envolver con API

Construyes una capa que expone las funciones o los datos del sistema viejo a tu tienda en línea, una app de vendedores o un tablero de reportes. No resuelve los problemas internos del legado, pero te deja integrarte ya, y esa misma API la puede usar después el sistema nuevo.

Refactorizar

Mejoras la estructura interna del código sin cambiar lo que hace: separas reglas de negocio de la interfaz y agregas pruebas automatizadas. Solo tiene sentido si la tecnología sigue vigente; si no, es pulir algo que de todos modos tendrás que reemplazar.

Reemplazo gradual tipo strangler fig

El sistema nuevo crece alrededor del viejo y lo sustituye módulo por módulo. Una capa intermedia decide qué sistema atiende cada función, hasta que el legado se queda sin trabajo y se apaga. La guía de Microsoft sobre el patrón Strangler Fig lo describe así y advierte que no es la mejor opción para sistemas pequeños, donde reemplazar todo es sencillo, ni cuando no puedes interceptar las solicitudes ni modificar el sistema viejo o su base de datos.

Su costo total puede ser parecido o algo mayor que una reescritura, porque durante un tiempo mantienes dos sistemas y la capa que los une. La diferencia es que el gasto se reparte en etapas, cada una entrega valor y el riesgo de un arranque fallido baja mucho.

Reescritura completa

Construyes el sistema nuevo y lo sustituyes de una sola vez. Es la opción con más riesgo de sobrecosto, porque el sistema viejo contiene reglas que nadie documentó y que aparecen hasta el día del arranque. Funciona bien en sistemas pequeños o muy bien documentados.

Sustituir por un SaaS o ERP comercial

A veces la mejor modernización es dejar de tener software propio. Si tus procesos son estándar, un SaaS o un ERP comercial puede ser suficiente, y el proyecto se reduce a migrar datos, configurar y capacitar. El costo cambia de forma: pagas menos en desarrollo, pero aparecen licencias por usuario que no terminan y el trabajo de adaptar tu operación al producto. Lo comparamos en ERP a la medida vs. comercial.

¿Rehacer o modernizar un sistema? Cómo decidir

La pregunta “¿rehacer o modernizar un sistema?” casi nunca tiene una respuesta única para todo el sistema. Lo que funciona es decidir módulo por módulo con tres preguntas:

1. ¿La tecnología tiene soporte? Si el lenguaje o la herramienta ya no se mantiene, refactorizar tiene poco sentido. Por ejemplo, Microsoft indica en su declaración de soporte de Visual Basic 6.0 que el entorno de desarrollo dejó de tener soporte el 8 de abril de 2008 y recomienda reemplazar esas aplicaciones con tecnología moderna, aunque el runtime sigue funcionando en las versiones de Windows con soporte.
2. ¿El código es entendible? Si alguien puede leerlo y cambiarlo sin miedo, se puede rescatar. Si cada cambio rompe otra cosa, es candidato a reemplazo.
3. ¿Ese módulo te diferencia? Si es un proceso estándar, quizá lo cubre un producto comercial. Si es la forma en que cotizas, produces o distribuyes y te da ventaja, vale la pena conservarlo en software propio.

Si tu sistema vive en Access, VB6 o FoxPro, revisa la guía específica sobre migrar Access, VB6 o FoxPro a web. Si lo que tienes es un conjunto de hojas de cálculo que creció demasiado, empieza por pasar de Excel a un sistema web.

Cuándo no conviene modernizar todavía

Ser justos también es decir cuándo esperar:

• El sistema funciona, tiene soporte y nadie lo necesita integrar. Si el riesgo es bajo, basta con asegurar respaldos y documentar lo esencial.
• El proceso va a cambiar pronto. Si vas a reorganizar un área o cambiar de modelo de negocio, modernizar antes es construir sobre algo que se moverá.
• No hay nadie de tu lado que pueda validar. Un proyecto sin usuarios clave disponibles se alarga y se encarece.
• Un producto comercial resuelve el 90% sin desarrollo. En ese caso, migrar datos hacia él puede ser la opción más económica.

¿Cuánto cuesta no modernizar un sistema heredado?

No vamos a darte una cifra, porque depende de tu operación y cualquier número genérico sería inventado. Pero sí podemos señalar dónde se va el dinero cuando un sistema legado sigue igual:

• Seguridad. Un sistema sobre componentes sin parches queda expuesto a vulnerabilidades conocidas que ya nadie va a corregir. Un incidente puede significar datos de clientes expuestos o días sin operar.
• Dependencia de una persona. Si solo una persona entiende el sistema, cada vacación, enfermedad o renuncia es un riesgo para la operación, y esa persona tiene un poder de negociación que no siempre está en tu contrato.
• Fallas y lentitud. Cada error tarda más en corregirse y cada cambio pequeño cuesta semanas. Ese tiempo es dinero, aunque no llegue en una factura.
• Imposibilidad de integrarse. Si el sistema no se conecta con tu timbrado de CFDI, tu banco o tu tienda en línea, alguien recaptura datos todos los días. Recapturar es pagar dos veces por la misma información, con más errores.

El costo de no modernizar es real, pero también lo es el de modernizar mal. Por eso conviene empezar por un diagnóstico que te diga qué riesgos son urgentes y cuáles pueden esperar.

¿Cómo pedir y comparar cotizaciones de modernización?

Dos propuestas para “modernizar el sistema” pueden ser incomparables si no especifican lo mismo. Pide que cada una detalle:

• Diagnóstico incluido o previo: quién revisa el código, la base de datos y los procesos, y qué entregable produce.
• Estrategia por módulo: qué se rehospeda, qué se actualiza y qué se reemplaza, y por qué.
• Migración de datos: si incluye limpieza, scripts versionados, ensayos y conciliación de saldos, o solo “pasar la información”.
• Operación en paralelo y plan de regreso: si están contemplados y cuánto duran.
• Pruebas: quién prueba, con qué casos y si hay pruebas automatizadas.
• Infraestructura y costos recurrentes: hosting, licencias, soporte y mantenimiento después del arranque.
• Propiedad: que el código, la documentación y los accesos queden a nombre de tu empresa.
• Qué queda fuera: lo más revelador de una propuesta suele ser lo que no incluye.

Cuando una cotización es mucho más baja que las demás, casi siempre omite migración de datos, pruebas o la operación en paralelo. Explicamos cómo detectarlo en software barato vs. caro: qué incluye cada cotización, y los factores generales de precio están en cuánto cuesta un software a la medida.

¿Cómo repartir la inversión por etapas?

La modernización de un sistema legacy rara vez debería pagarse en un solo bloque. Un reparto sano, que puedes adaptar a tu caso, se ve así:

1. Diagnóstico. Inventario de funciones, reglas de negocio, modelo de datos, integraciones y riesgos. Es una inversión acotada que te da un mapa de módulos con estrategia, orden y riesgo de cada uno, y te permite comparar cotizaciones con fundamento.
2. Riesgos urgentes. Respaldos probados, llevar el sistema a la nube o actualizar la versión que ya salió de soporte. Es la etapa que más riesgo quita por cada peso invertido.
3. Integración. Una API alrededor del sistema viejo para dejar de recapturar y conectar facturación, banco o tienda en línea.
4. Reemplazo por módulos. Empiezas por el que más valor aporta o más riesgo tiene, lo pones en operación real y sigues con el siguiente. Cada módulo se cotiza y se paga por separado.
5. Apagado del legado y mejora continua. Cuando el sistema viejo ya no recibe trabajo, se apaga, se archiva el histórico en una base de consulta y el presupuesto pasa a mantenimiento y mejoras.

Después de cada etapa puedes detenerte o ajustar prioridades sin perder lo invertido, porque cada entrega funciona por sí misma.

Cómo te ayuda Tecsolt

En Tecsolt desarrollamos software desde junio de 2017 y llevamos más de 100 proyectos. Somos un equipo 100% remoto con base en León, Guanajuato, y trabajamos por etapas: empezamos con un diagnóstico de tu sistema actual y te entregamos un plan por módulos con la estrategia, el orden y los riesgos de cada uno antes de proponerte el reemplazo completo. Nuestra infraestructura principal es Google Cloud, y el código, la documentación y los accesos quedan a nombre de tu empresa desde el primer día. Conoce nuestro servicio de software y ERP a la medida o agenda una reunión para revisar tu sistema y definir por dónde empezar.

Preguntas frecuentes

¿Cuánto cuesta modernizar un sistema legacy?

No hay un precio único: depende del tamaño y las reglas de negocio del sistema actual, de la calidad de sus datos, de la documentación que exista, de las integraciones y de la estrategia que elijas. Llevar un sistema a la nube sin tocar el código es mucho más barato que reescribirlo por completo. La cifra confiable sale de un diagnóstico del código, la base de datos y los procesos, no de una tabla genérica.

¿Qué es más barato, rehacer un sistema o modernizarlo?

Casi siempre es más barato empezar por modernizar: mover la infraestructura, actualizar la plataforma o envolver el sistema con una API cuesta menos que reescribirlo. Rehacerlo conviene cuando el código ya no se puede mantener o la tecnología no tiene soporte, y aun así suele ser más seguro hacerlo por módulos que de una sola vez.

¿Cuánto tiempo tarda la modernización de un sistema heredado?

Como referencia orientativa, mover un sistema a la nube sin cambiar el código puede tomar semanas, actualizar la versión de la plataforma de semanas a algunos meses, y reemplazar un sistema administrativo por módulos varios meses o más de un año. El plazo real depende del tamaño del sistema, del estado de los datos y de la disponibilidad de tu equipo para validar.

¿Cuáles son las soluciones de modernización de sistemas legacy?

Las más comunes son rehospedar en la nube, actualizar la versión del lenguaje o la base de datos, refactorizar el código, envolver el sistema con una API, reemplazarlo gradualmente con el patrón strangler fig, reescribirlo por completo o sustituirlo por un SaaS o ERP comercial. En la práctica se combinan según el módulo y el riesgo de cada uno.

¿Qué pasa si no modernizo mi sistema legado?

El sistema puede seguir funcionando un tiempo, pero acumulas riesgos: componentes sin parches de seguridad, dependencia de una sola persona que lo entiende, fallas difíciles de corregir y la imposibilidad de conectarlo con CFDI, bancos o tu tienda en línea. Ese costo no aparece en una factura, pero se paga en recaptura, errores y oportunidades perdidas.

¿Se puede pagar la modernización de un sistema por etapas?

Sí, y es lo más recomendable. Primero se paga un diagnóstico, después se atienden los riesgos urgentes como respaldos o infraestructura, y luego se reemplazan los módulos en el orden que más valor aporta. Cada etapa tiene entregables propios y te permite ajustar prioridades con información real.

• #sistemas legados
• #modernización de software
• #costo de software
• #strangler fig
• #migración de datos