Ir al contenido

Recursos // Modernización

Cómo modernizar un sistema legado sin detener la operación

Por Jude Hermoza · 10 de octubre de 2026 · 7 min

Un plan práctico para reemplazar un sistema antiguo por etapas: inventario, datos, pruebas, convivencia y reversión antes de apagarlo.

Un sistema antiguo puede ser incómodo y seguir siendo indispensable. Tal vez guarda años de pedidos, se conecta con facturación o contiene reglas que solo conoce una persona del equipo. Cambiarlo de un día para otro introduce un riesgo que ninguna interfaz nueva compensa.

La decisión útil no es «reescribir todo o no hacer nada». Es separar lo que debe seguir funcionando de lo que ya puede cambiarse, y probar cada paso con datos y usuarios reales.

Primero: decide qué parte merece cambiar

Haz una lista de las tareas que el sistema resuelve hoy. Para cada una, anota quién la ejecuta, qué dato entra, qué resultado espera y qué pasa cuando falla. Incluye los atajos manuales: hojas de cálculo paralelas, correos de aprobación y reportes que alguien corrige antes de enviarlos.

Clasifica después cada tarea en tres grupos:

SituaciónDecisión inicial
Funciona, tiene responsable y pocos erroresMantenerla mientras se moderniza lo demás.
Obliga a copiar datos o depende de una sola personaDiseñar una mejora acotada y medible.
No se entiende bien o afecta pagos, clientes o cumplimientoInvestigar y documentar antes de reemplazar.

Esta clasificación evita presupuestar una plataforma completa cuando el cuello de botella es una sola conexión. Si el problema principal es duplicar información, empieza por integrar las herramientas actuales.

Mapea los datos antes de diseñar pantallas

En una migración, la pregunta difícil suele ser «¿cuál es el dato correcto?». El cliente puede tener tres nombres distintos, una orden puede estar abierta en un sistema y cerrada en otro, y los campos obligatorios del sistema nuevo pueden no existir en el viejo.

El inventario mínimo incluye entidades, campos, dueño de cada dato, reglas de validación, volumen y frecuencia de actualización. Toma una muestra con casos normales y excepcionales. Si la muestra no se puede limpiar y explicar, migrar toda la base solo hará que el problema viaje de plataforma.

Define desde el principio cómo comprobarás la migración: conteo de registros, importes totales, relaciones entre entidades y revisión manual de casos críticos. Conserva una copia recuperable del origen y limita quién puede modificarla durante el cambio.

Cambia por etapas con una salida de emergencia

Un recorrido razonable para una operación B2B es:

  1. Observar. Medir el proceso actual: tiempo por tarea, errores recurrentes y pasos manuales. Eso da una referencia para saber si la mejora funciona.
  2. Aislar. Elegir un flujo que pueda operar sin sustituir todo el sistema, por ejemplo la recepción de pedidos o la consulta de estados.
  3. Construir y probar. Usar datos de prueba y luego una muestra controlada de datos reales, con usuarios que conocen las excepciones del negocio.
  4. Convivir. Ejecutar ambos flujos durante un periodo definido. Registrar diferencias; no dar por bueno un resultado solo porque la pantalla nueva se ve bien.
  5. Cambiar y poder volver. Acordar quién autoriza el cambio, qué indicador lo detiene y cómo se recupera el proceso anterior si falla.

La convivencia no tiene por qué duplicar cada tarea. Puede limitarse a comparar resultados y mantener el sistema antiguo disponible para consulta mientras se valida el nuevo. La forma exacta depende de qué operación no puede interrumpirse.

Qué debe quedar escrito en la propuesta

Pide una lista de sistemas afectados, datos que se migrarán, integraciones, entregables por etapa, responsables de prueba y criterios de aceptación. Solicita también una explicación de qué queda fuera del presupuesto: limpieza histórica de datos, licencias de terceros, capacitación y soporte posterior.

Un plazo sin inventario de datos ni plan de reversión es una hipótesis, no un compromiso útil. Por eso el Discovery debe producir un documento que puedas revisar antes de contratar la construcción.

En OXICARE DadeMedical mostramos una plataforma B2B con trazabilidad entre participantes; no lo presentamos como un caso de migración. Sirve para ilustrar por qué los estados y responsables deben estar claros cuando varios actores dependen del mismo flujo.

Si tu empresa ya identificó un proceso que no puede detenerse, llévanos el flujo actual y las herramientas involucradas. Podemos ayudarte a definir qué modernizar primero y cómo comprobar que el cambio no rompa la operación.

¿Tu operación necesita un sistema propio?

Cuéntanos qué proceso quieres mejorar y qué herramientas usas hoy. Te diremos si podemos ayudarte y por dónde empezar.

¿Evaluando proveedor? Conoce cómo trabaja una empresa de desarrollo de software en Perú con precio cerrado, o revisa los casos en producción.