Modernización de sistemas heredados en Panamá: qué decidir antes de tocar una línea de código

Tienes un sistema que funciona. Lleva años corriendo, la operación depende de él y nadie lo quiere tocar. El problema es que cada cambio cuesta más que el anterior, la persona que de verdad sabe cómo funciona es una sola, y los proveedores nuevos te piden integraciones que ese sistema no sabe dar.

La pregunta que llega a nuestra mesa casi nunca es "¿modernizamos?". Es otra, mucho más difícil: qué parte, en qué orden y sin parar la operación. Este post es sobre eso: cómo decidir, qué hacer primero y qué fechas panameñas ya están puestas en el calendario de 2027.

El calendario ya está escrito

Si trabajas con bancos, les vendes o les compras servicios, esto te toca aunque no seas uno. Lo que viene está en normas que ya se publicaron, y lo verificamos leyendo los textos de la Superintendencia de Bancos de Panamá:

• Acuerdo 1-2026, de 16 de enero de 2026, sobre prevención del uso indebido de los servicios bancarios y fiduciarios. Su artículo 53 fija dos plazos de adecuación: hasta el 31 de enero de 2027 para el monitoreo que exige el parágrafo 1 del artículo 25, que obliga a seguir las operaciones por cliente y no por producto, con alertas y reportes; y hasta el 30 de junio de 2027 para el artículo 14, que exige incorporar de forma obligatoria la geolocalización inferencial como fuente primaria de evaluación de riesgo en las aperturas por medios digitales o remotos. El mismo acuerdo deroga en todas sus partes el Acuerdo 10-2015 y sus modificaciones, el 1-2013, el 8-2000 y el 10-2000.
• Acuerdo 9-2026, de 22 de septiembre de 2026, que corrió la vigencia de las disposiciones del Acuerdo 6-2026 al 31 de marzo de 2027. El propio texto explica el motivo: dar más plazo para adecuar operaciones y sistemas.
• Acuerdo 8-2026, de la misma fecha, que obliga a verificar al beneficiario antes de autorizar una transferencia y empieza a regir en un plazo de nueve meses desde su promulgación.
• Y en el lado tributario, la Resolución 201-6299 de la DGI, de 29 de julio de 2025, que actualizó los deberes de los usuarios del sistema de facturación electrónica y ya movió en enero a quien pasó los límites del facturador gratuito.

Dos de esos acuerdos cuentan su plazo desde la promulgación, no desde una fecha de calendario, así que la fecha exacta hay que confirmarla en la Gaceta Oficial. Pero el mensaje es claro: un sistema que hoy no puede responder en línea, ni dejar rastro auditable, ni mirar al cliente en lugar del producto, tiene fecha de vencimiento en 2027.

Esto no es nuevo aquí. En 2010 el banco estatal anunció que reemplazaría un sistema de unos 30 años que no soportaba banca en línea, y lo planteó por módulos, con el sistema completo previsto para tres años después. El enfoque por etapas no es una moda: en Panamá es como se ha hecho lo grande.

Cuatro caminos, no dos

La conversación suele llegar planteada como "¿lo arreglamos o lo botamos?". Hay cuatro opciones, y una de ellas se descarta demasiado rápido:

Mantener. Si el sistema cubre lo que el negocio necesita, el costo de cambio es bajo y no hay una obligación con fecha encima, modernizar es gastar sin motivo. Un sistema viejo no es un problema por ser viejo. Es un problema cuando te frena.

Modernizar por dentro. El sistema sigue siendo el mismo, pero se le cambian piezas: se actualiza la base de datos, se sube a infraestructura nueva, se reescribe el módulo que duele. Sirve cuando la lógica de negocio está bien y lo que falla es la plataforma.

Convivir. Dejas el sistema viejo haciendo lo que hace bien, normalmente contabilidad y registro, y pones lo nuevo alrededor: una capa de servicios que atiende los canales digitales y habla con el viejo. Es el camino que termina eligiendo casi todo el que no puede parar.

Reemplazar. Sistema nuevo y apagón del viejo. Es la opción que se ve más limpia en una presentación y la que más proyectos ha hundido.

Cómo decidir

El criterio no es la antigüedad, es el valor de negocio y el riesgo. Las preguntas que nos sirven para ordenar la decisión:

• ¿Cuánto cuesta hoy un cambio pequeño? Si una modificación de un formulario toma semanas, el sistema ya te está cobrando una cuota mensual en tiempo.
• ¿Cuántas personas saben cómo funciona? Si la respuesta es una, el riesgo no es técnico, es humano.
• ¿Qué pasa si se cae un lunes a las nueve de la mañana? Si nadie puede contestarlo con precisión, eso se arregla antes que cualquier modernización.
• ¿Hay una obligación con fecha? Una norma con plazo cambia el orden de todo lo demás.
• ¿El sistema puede exponer servicios? Esta es la que más pesa, y la tratamos aparte.

Convivir bien: cómo se migra sin parar

Cuando la operación no puede detenerse, el reemplazo total no es una opción razonable. Lo que funciona es aburrido y ordenado:

Una puerta de entrada delante del sistema viejo. Todas las peticiones pasan por una fachada que decide qué atiende el sistema nuevo y qué sigue yendo al viejo. Al principio todo va al viejo; después se van moviendo rutas, una a una. Nadie de afuera nota el cambio porque la dirección no cambió.

Un módulo a la vez, elegido por riesgo. Se empieza por algo que importe lo suficiente para aprender y lo bastante acotado para volver atrás. Lo que no se toca al principio: facturación, nómina y cierre contable.

Doble escritura y comparación. Durante un tiempo los dos sistemas procesan lo mismo y se comparan los resultados. Cuando coinciden durante varios ciclos reales, se apaga el viejo para ese módulo. Es la parte que más tranquilidad da y la primera que se recorta cuando aprieta el calendario; recortarla es cambiar certeza por velocidad.

Reconciliación. Mientras hay dos sistemas vivos, alguien tiene que revisar que los números cuadren. Si no está presupuestado, se hace a mano y a las semanas se deja de hacer.

Decirlo claro: convivir no es la opción barata. La fachada, la doble escritura y la reconciliación son trabajo real. Lo que compra no es ahorro, es la posibilidad de equivocarse en pequeño en lugar de en grande.

Los datos van primero

Si los datos del sistema viejo están sucios, una migración los copia sucios y además rompe lo que antes se sostenía con costumbre: el campo que alguien usaba para anotar el nombre del contacto, los códigos duplicados, los registros sin fecha. Limpiar, mapear y acordar qué es cada campo se hace antes de escribir la lógica nueva, no después.

Criterios de salida, escritos

Antes de apagar algo tiene que estar claro qué significa "está bien": qué transacciones deben coincidir, cuánto puede tardar la operación más pesada, qué reportes deben dar el mismo resultado que el viejo. Si el criterio es "cuando los usuarios digan que está bien", el proyecto no tiene final.

Lo que vemos casi siempre

El problema no suele ser el lenguaje del sistema viejo. El problema es que no expone servicios: no tiene forma de que otro sistema le pregunte algo y reciba una respuesta en línea. Todo lo que sale de él sale por reportes, archivos o procesos nocturnos.

Y resulta que es exactamente lo que piden las normas de 2027: responder dentro del flujo, dejar rastro auditable, mirar al cliente completo. No hace falta reemplazar un sistema para eso. Hace falta ponerle delante una capa que responda, registre y traduzca, y que el sistema viejo siga siendo la fuente de verdad mientras se decide qué hacer con él. Eso es lo que construimos en migración y modernización de sistemas y en desarrollo de APIs e integraciones.

Un escenario típico, para aterrizarlo: una empresa tiene un sistema propio que hace facturación e inventario y del que salen reportes cada noche. Necesita que su cliente bancario consulte en línea y que su portal muestre saldos al día. En vez de reemplazarlo, se le pone delante un servicio que lee lo que necesita, responde en línea, guarda el registro de cada consulta y expone solo lo necesario. El sistema viejo no se toca; lo nuevo crece al lado. Si después se decide reemplazar, la fachada ya está y los consumidores no se enteran.

La parte de infraestructura la contamos en migración a la nube, y el contexto del sector financiero en transformación digital en la banca panameña.

Checklist para decidir

1. ¿Qué obligación con fecha te afecta, y cuál es la fecha real?
2. ¿Cuánto tarda hoy un cambio pequeño en el sistema viejo?
3. ¿Cuántas personas saben cómo funciona por dentro?
4. ¿El sistema puede responder a otro sistema en línea, o todo sale por archivos?
5. ¿Qué módulo se movería primero y por qué ese?
6. ¿Qué no se va a tocar en esta etapa?
7. ¿Habrá doble escritura y comparación, y por cuánto tiempo?
8. ¿Quién reconcilia mientras los dos sistemas estén vivos?
9. ¿Cuáles son los criterios para apagar el viejo, escritos y medibles?
10. ¿Qué pasa si hay que volver atrás a mitad de camino?

Errores comunes

• El reemplazo total de una sola vez. Se ve ordenado en el plan y se descubre tarde.
• Modernizar por antigüedad. La edad del sistema no es un criterio; el costo de cambio sí.
• Dejar los datos para el final. Es el retraso más común y el más caro.
• No escribir el criterio de salida. Sin él, el sistema viejo nunca se apaga y pagas dos.
• Subestimar la convivencia. La fachada y la reconciliación son proyecto, no detalle.
• Olvidar a quien opera el sistema todos los días. Es quien conoce las excepciones que no están documentadas en ninguna parte.
• Empezar por el módulo más difícil para "quitárselo de encima". Se empieza por donde se puede aprender y volver atrás.

Si tienes una fecha encima

Si hay un plazo de 2027 que te toca y un sistema que no sabe responder en línea, lo primero no es elegir tecnología: es decidir qué se queda, qué se mueve y en qué orden. En Grupo Codev hacemos ese trabajo desde hace más de 7 años con sistemas que no se pueden detener.

Escríbenos por WhatsApp o por el formulario de contacto y revisamos qué tienes hoy y qué conviene mover primero.