Retomar software de otro proveedor: qué evaluar primero

Si tu empresa tiene equipo IT y un sistema que sigue operando, el problema inicial es decidir qué trabajo encargar al nuevo proveedor. Pedí que se separen tres resultados: recibir los recursos, entender el sistema y ejecutar una mejora. Podés tener el código y todavía desconocer qué proceso nocturno modifica los datos o qué integración depende de una regla antigua.

La entrega de software a medida explica cómo recibir código, cuentas y documentación. Esta guía trata otra decisión: qué evaluación necesitás antes de comprometer presupuesto de continuidad o reemplazo. El mantenimiento define la cobertura recurrente posterior; no reemplaza esa evaluación inicial.

Describí el recorrido que necesita una decisión: quién inicia una operación, qué sistema guarda el resultado, qué área lo usa y qué falla observable motiva el cambio. Sumá la frecuencia y el impacto que tu empresa pueda comprobar. Una queja como «todo está lento» todavía no distingue una consulta de datos, un servicio externo o una pantalla.

Acordá versión y entornos que se revisarán, componentes incluidos, acceso autorizado, pruebas permitidas y exclusiones. Pedí que cada hallazgo indique cómo se reprodujo y qué parte quedó fuera. Un informe sobre un módulo no debe presentarse como evaluación de todo el sistema. Si una integración no pudo probarse, la conclusión tiene que conservar esa incertidumbre.

Usá una matriz de decisión con el hecho observado, su consecuencia operativa, la evidencia, la incógnita y el siguiente ensayo. El proveedor debe poder explicar qué hallazgo cambiaría su recomendación. Esta es una propuesta de trabajo de Duotach para comparar alcances, no una certificación ni una auditoría de seguridad completa.

Por ejemplo: «la tarea de exportación devuelve error al repetirla con el mismo lote» es comprobable; «la arquitectura está mal» necesita demostrar dónde impide el resultado. Un listado de librerías antiguas puede orientar la revisión, pero no decide por sí solo si conviene reconstruir el proceso.

Pedí alternativas para el mismo resultado operativo y las mismas restricciones. Conservar puede alcanzar si el problema es localizado y el recorrido relevante se puede probar. Reemplazar una parte merece evaluación cuando se puede definir un límite claro. La reconstrucción necesita justificar por qué las intervenciones acotadas no cumplen el objetivo y cómo se comprobará la transición.

La documentación de AWS sobre Strangler Fig describe migración incremental de monolitos hacia microservicios y sus condiciones. Es una referencia específica, no una razón para convertir cualquier aplicación en microservicios. Microsoft describe una capa de adaptación para traducir entre sistemas con modelos distintos; también exige considerar latencia, consistencia y operación. Ambas referencias fueron consultadas el 5 de noviembre de 2026.

Una solución gradual mantiene dependencias durante la convivencia. Compará quién escribe cada dato, cómo se detectan diferencias y cuándo se puede retirar la parte anterior. No aceptes «se revierte el despliegue» como respuesta suficiente si el cambio ya modificó registros o disparó acciones externas.

Una empresa ficticia tiene una aplicación interna que registra solicitudes y envía una exportación a otro sistema. Quiere cambiar de proveedor porque, al reintentar, aparecen registros duplicados. El objetivo acotado es que repetir una exportación no vuelva a crear la misma operación en el destino. Este escenario es didáctico; no describe un cliente ni una mejora medida.

El diagnóstico debe seguir el identificador desde la solicitud hasta el destino y comprobar qué ocurre cuando la respuesta se pierde. Si existe un identificador estable y el receptor permite consultar el resultado, se puede evaluar una corrección del tramo. Si el receptor no permite distinguir operaciones, esa limitación debe aparecer antes de prometer el arreglo. Una pantalla nueva no elimina esa incógnita.

Para aceptar la primera intervención, acordá un ensayo aislado con datos autorizados: envío normal, repetición del mismo envío y recuperación después de una respuesta incierta. Registrá resultados esperados y observados en ambos sistemas. La empresa acepta el comportamiento acordado; no solamente que un test o una demostración termine sin error.

Pedí un documento que conecte alcance revisado, hallazgos reproducibles, riesgos priorizados, alternativas y primera intervención propuesta. Cada alternativa debe expresar dependencias, límites y condiciones para estimarla. Cuando falta acceso o evidencia, pedí la actividad que despejaría esa incógnita y su alcance; una cifra cerrada sin ese límite puede estar cotizando un supuesto distinto.

Definí quién valida la regla de negocio y quién autoriza el cambio técnico. Acordá qué resultado permite continuar, cuál requiere volver a evaluar y quién mantiene el proceso mientras tanto. El diagnóstico, la implementación y la cobertura posterior necesitan alcances explícitos. El trabajo de entender y probar un sistema existente se contrata; no queda implícito en una consulta comercial.

Duotach desarrolla software a medida para empresas. Si necesitás continuar o ampliar un sistema existente, describí el proceso afectado, el cambio que buscás y qué documentación y accesos tiene tu empresa. La compatibilidad técnica y el alcance se verifican antes de comprometer una intervención; no tomamos cualquier sistema por el solo hecho de recibir su repositorio.

El formulario abre una consulta sobre el proyecto. No adjuntes contraseñas ni datos de usuarios para explicar el problema. Un relevamiento específico, una revisión de código o una prueba sobre tus sistemas requiere un alcance de trabajo acordado.