Cómo modernizar un SaaS heredado con desarrollo asistido por IA

Un SaaS heredado es software que el negocio sigue vendiendo o sigue usando, y que el equipo actual tiene miedo de tocar. El acceso funciona. Las facturas salen. Quien sabía por qué existe una regla concreta se fue hace tres años. Modernizar es hacer que ese sistema vuelva a poder cambiarse sin parar la empresa.

El desarrollo asistido por IA cambia la velocidad de parte de la escritura. No quita la necesidad de entender el producto.

Por qué se moderniza

El detonante rara vez es “preferimos un framework más nuevo”. Es uno de estos:

• Las publicaciones tardan semanas porque cada cambio pone en riesgo una función que no tiene que ver.
• El framework o el entorno de ejecución están fuera de soporte, y los parches de seguridad ya no son rutinarios.
• Los clientes nuevos piden integraciones que la arquitectura antigua encarece.
• Contratar es difícil porque la base es una que nadie quiere aprender.
• Los informes son hojas de cálculo exportadas del producto, porque el producto no responde la pregunta.
• Un comprador, un auditor o un cliente grande ha hecho preguntas de seguridad y privacidad que el sistema no puede contestar con limpieza.

Una interfaz nueva, por sí sola, no es modernización. Si las reglas de la base de datos y las integraciones siguen siendo opacas, has cambiado la piel del riesgo.

Reconstruir, refactorizar o avanzar por partes

Lo que recomendamos por defecto es ir por partes. Pon un límite alrededor de un flujo, construye la versión nueva de ese flujo, migra sus datos y ponlo en producción mientras el resto del sistema antiguo sigue. Una reescritura completa se justifica cuando el código antiguo no se puede acotar, o cuando estás retirando comportamiento a propósito en lugar de conservarlo.

GoNow Luma es nuestro propio producto, construido como plataforma y no rescatado del código heredado de un cliente. Demuestra que diseñamos y entregamos software. No demuestra que el SaaS de otra persona se pueda sustituir del mismo modo, ni en el mismo plazo.

Dónde ayuda de verdad programar con IA

Usado por alguien que sabe leer el resultado, un asistente sirve para:

• Redactar el repetitivo alrededor de una especificación que has escrito: formularios, clientes de API, pantallas CRUD, modelos tipados.
• Proponer pruebas para un comportamiento que ya has descrito, incluidos los casos límite que te acordaste de mencionar.
• Explicar un módulo desconocido para que una persona confirme la explicación contra el código.
• Refactors repetitivos: renombrar, extraer una función, convertir un patrón que ya es coherente.
• Primeros borradores de scripts de migración, que después una persona ejecuta contra una copia de los datos.

Es un mal autor único de:

• Precios, permisos, facturación y cualquier cosa que mueva dinero o datos personales.
• Reglas de negocio no documentadas. El modelo inventará una regla verosímil. Verosímil no es lo mismo que cierto.
• Arquitectura. Propondrá con gusto tres estructuras incompatibles en una tarde.
• Una “reescritura completa” a partir de un zip del repositorio antiguo. El resultado compila más a menudo de lo que se comporta.

El patrón productivo es un desarrollador sénior que enuncia la restricción, revisa el diff y rechaza las partes que solo son fluidas. El patrón improductivo es pegar el repositorio en una ventana de chat y pedir el producto nuevo.

Entiende lo que el sistema hace de verdad

Antes de elegir una arquitectura de destino, escribe el comportamiento. El código fuente es una entrada. No es toda la entrada.

• Habla con quien lo usa cada día. Pregunta qué se saltan.
• Lee los tickets de soporte y las excepciones de facturación. Los casos límite viven ahí.
• Lista los roles y qué puede ver y cambiar cada uno.
• Lista los trabajos que corren cuando nadie mira: facturas, importaciones, correos, webhooks, recálculos nocturnos.
• Identifica los informes de los que dependen clientes o contabilidad. Son requisitos, aunque parezcan un botón de exportar.

Si no puedes describir un flujo sin abrir el código, no estás listo para sustituirlo. Estás listo para investigarlo.

Ingeniería inversa sin engañarte

En un sistema con poca documentación, el método fiable es aburrido:

1. Elige un resultado de negocio, por ejemplo “un responsable crea un cliente y el cliente recibe una invitación”.
2. Recórrelo en una copia de pruebas y anota cada estado en el que puede estar la pantalla.
3. Sigue ese camino en el código y en la base de datos.
4. Escribe la regla en una frase que un colega pueda corregir. “La invitación caduca a los 14 días” es un requisito. “La tabla de usuarios tiene una columna de token” es un detalle de implementación.
5. Repite con los flujos que ingresan o protegen ingresos. Deja la cola larga hasta que esos estén a salvo.

Las herramientas de IA pueden narrar un archivo mientras haces esto. Contrasta la narración con el código. Donde el código y quienes operan no coinciden, quienes operan suelen describir un fallo que se ha convertido en proceso. Decide de forma explícita si el sistema nuevo va a conservar ese fallo.

Una hoja de ruta que se pueda parar

Una hoja de ruta útil tiene fases que dejan el negocio en un estado en el que podrías parar.

1. Mapa. Flujos, datos, integraciones, riesgos. Una decisión escrita sobre reescritura o partes.
2. Hazlo seguro de cambiar. Control de versiones, un entorno de pruebas, copias de seguridad que hayas restaurado una vez, y pruebas suficientes alrededor de los flujos que vas a tocar. Si nada de eso existe, es el primer proyecto.
3. Prototipa la parte arriesgada. El flujo que todo el mundo cita como la razón de que una reescritura sea imposible. Un prototipo demuestra el enfoque. No es la migración.
4. Sustituye esa parte en producción. Un camino, vigilado, con forma de volver atrás.
5. Repite. La siguiente parte empieza cuando la anterior está estable, no cuando lo dice una diapositiva.

Las fechas pertenecen a la parte que tienes delante. Una sola fecha para “la plataforma nueva” es un deseo.

Datos y bases de datos

La mayoría de las modernizaciones fallan en los datos, no en la interfaz.

• Inventaría tablas, quién escribe en ellas y qué columnas no sabe explicar nadie.
• Decide cuál es la fuente de verdad durante el solapamiento. Dos aplicaciones escribiendo el mismo cliente se van a desviar.
• Migra con un script repetible contra una copia. Y otra vez. La primera ejecución es un ejercicio de descubrimiento.
• Mantén estables los identificadores allí donde los guardan sistemas externos.
• Planifica el histórico: facturas, registros de auditoría y datos que estás obligado a conservar. “Empezamos de cero” suele ser inaceptable para los clientes, y a veces ilegal.
• Haz una copia de seguridad que hayas demostrado que puedes restaurar antes de la primera escritura en producción.

PostgreSQL es una elección sólida y habitual para datos nuevos de aplicación. No es una razón para tirar una base de datos que se entiende y sigue sirviendo. Mueve el modelo de datos cuando el modelo es el problema.

Seguridad y privacidad

Una reescritura es el momento en que los atajos viejos se convierten en incidentes nuevos.

• Mapea los datos personales y por qué los tienes. En el Reino Unido y en la UE eso incluye una base jurídica, una conservación y una forma de atender el acceso y la supresión. Esta consultoría opera desde España. Tu producto puede tener deberes propios. Pide consejo para las jurisdicciones a las que de verdad sirves, en lugar de copiar una lista de un blog.
• Sustituye el almacenamiento casero de contraseñas y la lógica casera de sesión por un enfoque mantenido.
• Revisa los encargados, incluido cualquier proveedor de IA cuya API reciba contenido de clientes. No pegues datos personales de producción en un prompt porque era cómodo.
• Los secretos se quedan fuera del repositorio y fuera de la transcripción del chat usada para generar una función.
• Registra el acceso a datos sensibles. Si el sistema antiguo tenía una pista de auditoría, el nuevo necesita un equivalente antes del cambio.

El código de autenticación generado por IA es una fuente frecuente de errores seguros de sí mismos. Trátalo como borrador y prefiere una librería que ya se mantenga.

Integraciones

Lista cada sistema que te llama o al que llamas: pagos, correo, SMS, CRM, contabilidad, inicio de sesión único, webhooks de clientes. Para cada uno, anota la dirección, las credenciales, qué pasa cuando falla y si el otro lado puede cambiar.

Algunos proveedores no se van a mover a tu calendario. Entonces el sistema nuevo tiene que hablar el protocolo antiguo durante un tiempo. Ese adaptador es trabajo real. Presupuéstalo.

Aston Education es una web y una integración de ofertas con una plataforma de selección, no una reescritura de un SaaS heredado. Entra en esta conversación solo como recordatorio de que el sistema externo suele marcar el ritmo.

Una arquitectura práctica

Para un producto B2B típico que necesita un front nuevo y un back más tranquilo:

• Una aplicación web renderizada en servidor, a menudo Next.js u otro framework parecido, para que las páginas obvias no dependan de un paquete grande en el cliente.
• Pocos servicios de backend. Uno suele bastar hasta que la carga o el tamaño del equipo obliguen a separar.
• Una base de datos relacional, trabajos en segundo plano para lo que tenga que reintentarse, y una cola donde el trabajo pueda fallar por su cuenta.
• La autorización en un solo sitio, comprobada en el servidor, no solo escondida en la interfaz.

Los microservicios, un bus de eventos nuevo y tres proveedores cloud son la forma en que un producto pequeño adquiere la carga operativa de uno grande. Añádelos cuando una restricción medida lo exija.

La web pública de marketing es otra pregunta. Si está en un CMS que se muere, puedes reconstruir la web en su propio calendario. No bloquees un arreglo de seguridad por un cambio de marca.

Pruebas

La suite de pruebas antigua, si existe, documenta la intención. No la tires porque la sintaxis sea vieja.

• Caracteriza los flujos que vas a mover con pruebas que describan entradas y salidas, antes de cambiar la implementación.
• Mantén una copia de pruebas con datos realistas, con los datos personales quitados o sintetizados.
• Que pruebe el flujo una persona que no lo ha escrito.
• Compara salidas en lo que tiene que coincidir: un total de factura, un permiso, una fila de informe.
• Automatiza las comprobaciones de regresión que estás harto de hacer a mano.

Un pipeline en verde que nunca ejecuta el cálculo de facturación no es aseguramiento de calidad.

La supervisión humana es el control

Reglas que el equipo tiene que seguir:

• El código generado lo revisa alguien que entiende el flujo.
• El prompt no es la especificación. La especificación es una nota corta en la pull request.
• Las dependencias que sugiere un modelo se comprueban por mantenimiento y licencia antes de añadirse.
• Nada de datos de producción en los prompts. Nada de secretos en los prompts.
• Si nadie puede explicar una función generada, no se integra.

El asistente no baja el listón. Aumenta el volumen de código que tiene que cumplirlo.

Riesgos que conviene nombrar en la propuesta

• Comportamiento perdido. Un tipo de contrato raro, una anulación manual, una regla de un cliente concreto.
• Una convivencia larga. Dos sistemas, y un equipo manteniendo los dos porque la fecha de corte se fue.
• Datos que no viajan de ida y vuelta. Informes que ya no cuadran con las cifras del año pasado.
• Dependencia, trasladada y no quitada. Una plataforma nueva de la que no puedes salir no es una modernización.
• Exceso de automatización. Un asistente que cambia registros sin una persona en el camino lo hará mal y a volumen.

La mitigación es partes más pequeñas, una forma de volver atrás y una persona responsable del diff.

Qué mueve de verdad el coste y el plazo

Estos factores no se resumen en un porcentaje fijo de ahorro por la IA.

• Cuántos flujos tienen que comportarse exactamente como hoy.
• Lo limpios que están los datos, y si el histórico tiene que moverse.
• Cuántos sistemas externos hay, y si los controlas.
• Los requisitos de seguridad, privacidad y auditoría de tu mercado.
• Si el producto puede cambiar, o solo la implementación.
• Si alguien sigue conociendo las reglas antiguas.
• Quién va a alojar y cuidar el sistema nuevo.

La ayuda de la IA reduce tiempo en código repetitivo y especificado. No quita el descubrimiento, la conciliación de datos ni el trabajo de ganarse la confianza en la pantalla nueva. Una propuesta que cita un ahorro garantizado por la IA está adivinando.

Un prototipo del flujo más arriesgado suele ser la primera compra correcta. El prototipado rápido es para esa pregunta. Un prototipo que responde “¿puede vivir este flujo en la arquitectura nueva?” es útil. Un prototipo que solo se parece a una home nueva no lo es.

Una secuencia que se puede parar

1. Escribe los resultados que tienen que sobrevivir, y los que vas a dejar.
2. Elige refactorizar, ir por partes o reconstruir con la tabla de arriba. Anota por qué.
3. Pon las redes: una restauración que hayas probado, un entorno de pruebas, control de acceso, un despliegue que puedas deshacer.
4. Especifica un flujo con el detalle suficiente para que quien implemente no invente las reglas.
5. Construye esa parte. Revisa cada cambio generado. Pruébala con escenarios reales incómodos.
6. Migra los datos de esa parte y ponla con un grupo pequeño.
7. Planifica la siguiente parte solo cuando esta esté estable.

Si el paso 4 no se puede escribir, no empieces el 5. Otro prompt no va a descubrir una regla que nadie ha enunciado.

Valida con un prototipo

Un prototipo sale bien cuando responde una pregunta con nombre.

Buenas preguntas: si una excepción de facturación se puede representar en el modelo nuevo, si un cliente puede terminar la tarea sin el paso antiguo de back-office, y si una integración sigue aceptando las cargas que tienes que enviar.

Preguntas flojas: si un modelo puede generar la aplicación entera para el viernes, y si la base nueva va a reducir los costes un tercio.

Dale al prototipo una copia de datos anonimizados, el rol incómodo y la integración que falla. Después continúa, estrecha el alcance o para. Parar es un resultado legítimo.

La casa de este trabajo es apps a medida y SaaS. Si el sistema heredado es una web pública y no un producto, empieza por la guía de migración.

Límites de esta guía

Esto es práctica de trabajo de entrega, no un benchmark de un proveedor. No cita un porcentaje de aceleración por programar con IA, porque el rango honesto depende de la tarea y de quien revisa. Para las consecuencias en buscadores de sustituir una web pública, usa la documentación de cambios de sitio de Google y la guía de funciones de IA. Para los deberes de privacidad, usa el regulador que cubre a tus clientes.

Revisada en noviembre de 2026. Nada de aquí es un plazo fijo ni un ahorro garantizado.