El desafío: Migrar sin apagar el negocio

Es 2026. Tu PYME tiene un sistema hecho en Visual Basic 6 hace 15 años. El desarrollador original ya no está. Nadie entiende bien cómo funciona. No tiene documentación. Cada cambio toma semanas. Las bases de datos crecen y el sistema se vuelve lento.

El gerente dice: "Necesitamos algo moderno". El departamento IT contesta: "Pero no podemos apagar el sistema ni una hora. Dependemos de él para todo: facturación, inventario, clientes, reportes".

Ahí está el dilema: necesitas modernizar, pero no puedes parar. Una migración mal hecha puede costar:

• Pérdida de datos (clientes, transacciones, historial).
• Downtime: S/ 10,000-50,000/hora dependiendo del rubro.
• Errores en migración: datos inconsistentes que tardan meses en arreglarse.
• Empleados sin sistema y trabajando "a mano" con documentos.

La solución: migración gradual, controlada, en etapas. No es reemplazar todo de una. Es ir moviendo piezas mientras el sistema viejo sigue corriendo.

Qué es un sistema legacy

Legacy significa "heredado". Es un sistema antiguo que aún funciona pero:

• Está escrito en lenguaje/tecnología obsoleta (COBOL, VB6, ASP clásico).
• No hay documentación clara.
• Los desarrolladores originales se fueron.
• Mantener/mejorar es costoso y lento.
• Acopla malas prácticas (sin tests, código espagueti, bases de datos no normalizadas).

Por qué es crítico: Una PYME típica tiene su legado corriendo 10-12 horas/día. No puede apagarse sin que el negocio se paralice. Una compañía de seguros podría perder S/ 50,000/hora. Una distribuidora, S/ 30,000/hora.

Por qué es urgente modernizar

Riesgo 1: Seguridad. Sistemas legacy no tiene parches. A cada día que pasa sin actualizar, eres más vulnerable a ataques. Si almacena datos de clientes sin cifrado = exposición legal.

Riesgo 2: Talento. Nadie quiere programar en VB6 o COBOL. Encontrar desarrolladores es imposible. Cuando alguno se va, queda todo paralizado. He visto empresas pagando S/ 8,000-12,000/mes a jubilados para mantener sistemas legacy.

Riesgo 3: Integración. El sistema legacy no habla con cloud, APIs, móviles. Tu equipo de ventas necesita acceso remoto? No puede. Quieres integrar con SUNAT para facturación electrónica automática? Es un dolor. Usualmente se hace con VB script que copia datos.

Riesgo 4: Performance. Bases de datos con 15 años de datos (nunca archivada, nunca optimizada) crecen a GB. Un reporte que antes tardaba 5 minutos ahora tarda 45 minutos. Los empleados esperan. La productividad baja.

Cuándo migrar: Las señales

Señal	Urgencia	Acción
Sistema cae 5+ veces/año	CRÍTICA	Migrá YA
Cambios tardan 3+ meses	Alta	Plan en 30 días
Solo 1 persona entiende el código	Alta	Comienza documentación
Lenguaje es EOL (end-of-life)	Alta	Roadmap de migración
Reportes toman 30+ minutos	Media	Análisis de costo-beneficio
Quieres API o integración moderna	Media	Presupuesta desarrollo nuevo

Estrategia 1: Big Bang (NO RECOMENDADO)

Qué es: Apagar el sistema viejo el viernes, prender el nuevo el lunes. Migración de datos de una sola vez. "1 fin de semana sin sistema".

Riesgos:

• Datos inconsistentes (qué pasa con transacciones que ingresaron 5 minutos antes del apagón?).
• El nuevo sistema falla el lunes → operación paralizada, sin fallback.
• Empleados no saben usar el sistema nuevo → caos de soporte.
• Bugs que requieren rollback (volvemos al viejo? pero los datos ya fueron migrados!).

Costo potencial de un Big Bang fallido: Downtime de 2-3 días = S/ 100,000-200,000. Plus costo de reparación manual de datos = S/ 50,000-100,000. Total: S/ 150,000-300,000.

Cuándo usarlo: Casi nunca. Solo si sistema legacy cae por completo y hay que reconstruir de cero (riesgo aceptable = perder algo que ya está perdido).

Estrategia 2: Migración por fases (RECOMENDADO)

Principio: Dividir el sistema en módulos. Migrar 1 módulo a la vez. Sistema viejo y nuevo conviven mientras se prueban resultados.

Ventajas:

• Si algo falla, solo afecta 1 módulo, no todo.
• Empleados aprenden gradualmente.
• Datos se pueden validar antes de comprometerse.
• Si necesitas rollback, es simple: vuelves al viejo para ese módulo.

Ejemplo: Sistema legacy con 5 módulos: Clientes, Órdenes, Inventario, Facturación, Reportes.

• Fase 1: Migrar Clientes (menos riesgo, no depende de otros).
• Fase 2: Migrar Órdenes (depende de Clientes, pero controlable).
• Fase 3: Migrar Inventario (independiente de Órdenes).
• Fase 4: Migrar Facturación (depende de Órdenes e Inventario).
• Fase 5: Migrar Reportes (al final, cuando todo está en nuevo sistema).

Cada fase toma 2-4 semanas. Total: 3-4 meses. Durante ese tiempo, ambos sistemas corren. Validación constante.

Los 6 pasos de una migración exitosa

Paso 1: Auditoría y mapeo (2 semanas)

Qué hacer:

• Documentar el sistema legacy: Qué tablas tiene? Qué campos? Qué reportes genera? Qué usuarios tiene?
• Identificar integraciones: ¿Conecta con otros sistemas? ¿APIs? ¿Archivos batch?
• Listar procesos críticos: ¿Qué módulos no pueden fallar ni una hora?
• Entrevistar usuarios: ¿Qué funcionalidades usan? ¿Qué les molesta?

Entregables:

• Diagrama de base de datos (tablas, relaciones, tamaño).
• Lista de módulos/funcionalidades.
• Documento de procesos críticos.
• Matriz de riesgos.

Costo estimado para PYME: S/ 3,000-8,000 (consultor externo 2 semanas).

Paso 2: Limpieza de datos (3-4 semanas)

Los datos en legacy son sucios. 15 años acumulando errores:

• Clientes duplicados (Juan García vs Juan Garcia vs J. García).
• Registros huérfanos (órdenes sin cliente asignado).
• Datos nulos donde no deberían (cantidad en blanco en una venta).
• Formatos inconsistentes (fecha como "01/01/2010" vs "01-01-10").

Procesos de limpieza:

• Deduplicación: Identificar registros duplicados con 90% similitud.
• Validación: ¿Cada orden tiene cliente? ¿Cada cliente tiene empresa válida?
• Normalización: Fechas, formatos de teléfono, direcciones.
• Archivado: Datos muy antiguos (más de 5 años sin movimiento) se archivan, no migran.

Costo estimado para PYME: S/ 5,000-15,000 (herramientas + horas técnicas).

Paso 3: Diseño del nuevo sistema (4-6 semanas)

Decisiones clave:

• Tecnología: ¿Python/FastAPI? ¿Node.js/NestJS? ¿.NET? ¿Cloud o on-premise?
• Base de datos: ¿SQL (PostgreSQL, MySQL)? ¿NoSQL (MongoDB)?
• Arquitectura: ¿Monolito o microservicios?
• UI: ¿Web? ¿Mobile? ¿Ambas?

Para PYMES: Recomendación típica:

• Backend: Python FastAPI o Node.js NestJS (ambos rápidos, talento disponible en Perú).
• BD: PostgreSQL (robusta, confiable).
• Frontend: React (si web) o Flutter (si mobile).
• Cloud: AWS EC2 o DigitalOcean (S/ 500-2,000/mes).

Costo estimado: S/ 30,000-60,000 (arquitecto + senior developer, 4-6 semanas).

Paso 4: Desarrollo iterativo + construcción de data pipeline (12-16 semanas)

Enfoque ágil: Desarrollar módulo por módulo (no todo de una vez).

Cada módulo:

• Diseño de esquema de BD.
• APIs backend.
• Interfaz frontend.
• Tests automatizados.
• Construcción de script de migración de datos (legacy → nuevo).

Data pipeline (es crítico): Script que:

• Lee datos del legacy (SQL, Excel, CSV).
• Transforma a formato nuevo (mapea campos).
• Valida (¿datos están completos y correctos?).
• Carga en BD nueva.
• Verifica (¿cantidad de registros = original?).

Costo estimado: S/ 80,000-200,000 (equipo de 3-4 devs × 3-4 meses).

Paso 5: Pruebas paralelas (4 semanas antes de corte final)

Objetivo: Validar que nuevo sistema funciona idéntico al legacy para casos de uso reales.

Pruebas a hacer:

• Unit tests: Cada función/API funciona bien?
• Integration tests: ¿Módulos hablan bien entre sí?
• End-to-end tests: ¿Un flujo completo (orden → inventario → facturación) funciona?
• Performance tests: ¿10,000 órdenes cargadas rápido?
• Stress tests: ¿Aguanta 100 usuarios simultáneos?
• UAT (User Acceptance Testing): ¿Empleados dicen "sí, funciona igual"?

Pruebas en paralelo: Mientras legacy genera un reporte, nuevo también lo genera. ¿Resultados iguales? Si no, hay bug.

Costo estimado: S/ 10,000-20,000 (QA engineer + usuarios finales tiempo).

Paso 6: Corte final y monitoreo (1-2 semanas post-corte)

El gran día:

• Viernes 5 PM: Último backup del legacy. Última migración de datos.
• Viernes 6 PM - Lunes 8 AM: Ventana de mantenimiento. Sistema nuevo está vivo, legacy apagado.
• Lunes 8 AM: Empleados empiezan a trabajar con sistema nuevo.

Monitoreo intensivo (semana 1):

• ¿Hay errores en producción?
• ¿Empleados pueden trabajar?
• ¿Datos están consistentes?
• Hotline de soporte activo 24/7.

Plan de rollback (por si falla): Volver a legacy en máximo 4 horas. Script automatizado para eso.

Caso real 1: Distribuidora de Lima (6 meses, S/ 280K)

CONTEXTO:

• Tipo: Distribuidor de bebidas y alimentos.
• Tamaño: 120 empleados, 300 clientes.
• Sistema legacy: Visual Basic 6 (18 años).
• Problemas: Lento, crece BD diaria, no integra con SUNAT, solo 1 dev entiende código.

PLAN DE MIGRACIÓN:

• Mes 1: Auditoría + limpieza de datos. Eliminó 50K registros duplicados. Costo: S/ 8,000.
• Mes 2-3: Desarrollo backend (módulos Clientes, Órdenes). Costo: S/ 120,000.
• Mes 3-4: Frontend + integración con SUNAT. Costo: S/ 90,000.
• Mes 4-5: Pruebas paralelas. Empleados trabajan con nuevo sistema en paralelo. Costo: S/ 15,000.
• Mes 5-6: Migración final + soporte post-go-live. Costo: S/ 47,000.

TOTAL: S/ 280,000 (desarrollo + infraestructura).

BENEFICIOS (primeros 12 meses):

• Velocidad: Cambios que tardaban 3 meses ahora tardan 1 semana.
• Confiabilidad: 0 caídas en 6 meses (vs 8 caídas/año antes).
• Performance: Reportes que tardaban 45 min ahora tardan 2 min.
• SUNAT: Facturación automática (antes era manual + lenta).
• Productividad: 15 empleados antes dedican 2h/día a "trabajo manual", ahora 15 min. Ahorro: S/ 150,000/año.

ROI: Inversión S/ 280K. Beneficio año 1: S/ 150K ahorrado. Año 2: S/ 150K (sin costos de desarrollo). Recupera inversión en 22-24 meses. A partir de mes 25: puro ahorro.

Caso real 2: Aseguradora de Arequipa (9 meses, S/ 420K, riesgo alto)

CONTEXTO:

• Tipo: Seguros (automóvil, vida, hogar).
• Tamaño: 200 empleados, 50K clientes.
• Sistema legacy: COBOL con BD Oracle (25 años).
• Problema: Crítico. Si cae, no pueden emitir pólizas. Pérdida: S/ 50,000/hora.

DESAFÍOS ÚNICOS:

• 50K clientes = 5M de pólizas. Migración de datos = riesgo altísimo.
• Regulación: Superintendencia de Seguros exige auditoría de datos migrados.
• Legacy muy complejo: 200K líneas de COBOL, documentación inexistente.

SOLUCIÓN: Estrategia de 2 fases + firma de auditor externo.

• Fase 1 (Meses 1-4): Desarrollo + migración en ambiente de prueba. Auditor valida datos. Costo: S/ 180,000.
• Fase 2 (Meses 5-6): Migración final + rollout en fin de semana (no hay opción de downtime largo). Costo: S/ 120,000.
• Post-go-live (Meses 7-9): Monitoreo 24/7 + correcciones. Costo: S/ 120,000.

TOTAL: S/ 420,000.

BENEFICIOS (año 1):

• Confiabilidad: 99.99% uptime (vs 98% antes).
• Cumplimiento: Sistema auditable para regulator.
• Velocidad: Nuevos productos de seguros se programan en 2 semanas vs 6 meses antes.
• Costo operativo: Reducción de staff técnico (ya no necesita COBOL expert). Ahorro: S/ 200,000/año.

ROI: Año 1 recupera 50% de inversión. A partir de año 3, puro beneficio.

Riesgos comunes en migración

Riesgo 1: Pérdida de datos

Cómo evitarlo:

• Backup triple: legacy original, legacy + copia de seguridad, BD nueva + copia de seguridad.
• Pruebas de restauración: cada backup se restaura y se valida.
• Script de auditoría: cuenta registros antes/después. Si no coincide, halt hasta investigar.

Riesgo 2: Empleados no pueden trabajar

Cómo evitarlo:

• Capacitación ANTES del go-live. No día 1.
• Manual de usuario detallado (por cada función).
• Soporte on-site los primeros 3 días.
• Hotline de soporte dedicado semana 1.

Riesgo 3: Errores en datos migrados

Cómo evitarlo:

• Validación de datos ANTES de migrar. Script que chequea: ¿DNI válido? ¿Fecha en rango correcto? ¿Relaciones entre tablas intactas?
• Pruebas paralelas: nuevo sistema procesa misma transacción que legacy. ¿Resultado igual?
• Auditoría externa (especialmente en sectores regulados).

Riesgo 4: Performance degrada en producción

Cómo evitarlo:

• Load testing ANTES de go-live. ¿Aguanta 200 usuarios simultáneos?
• Índices en BD optimizados.
• Caché en aplicación (Redis).
• CDN para assets estáticos.

Checklist: ¿Estamos listos para migrar?

• ¿Hemos documentado completamente el sistema legacy?
• ¿Limpiamos y validamos todos los datos?
• ¿Tenemos equipo técnico dedicado (no distrayendo con otros proyectos)?
• ¿Presupuesto está aprobado y disponible?
• ¿Tenemos plan B (rollback) si algo falla?
• ¿Usuarios finales están capacitados en nuevo sistema?
• ¿Hay soporte 24/7 listo para semana 1?
• ¿Hemos testeado migración en ambiente de prueba?
• ¿Tenemos ventana de mantenimiento programada y comunicada?

Si contestas "no" a más de 1 pregunta, no estás listo aún. Pospón.

Timeline típico para PYME

Fase	Duración	Costo estimado (S/)	Entregables
Auditoría + Limpieza	2-4 semanas	S/ 5,000-15,000	Documentación, datos limpios
Diseño + Arquitectura	4-6 semanas	S/ 20,000-40,000	Especificación técnica, BD schema
Desarrollo	12-16 semanas	S/ 80,000-160,000	Backend + Frontend, APIs, BD
Testing + Capacitación	4-6 semanas	S/ 15,000-30,000	QA reports, manual de usuario
Go-live + Soporte	1-2 semanas	S/ 10,000-20,000	Sistema en producción, soporte activo
TOTAL	6-8 meses	S/ 130,000-265,000	Sistema moderno, confiable, escalable

Conclusión: Migración no es si, es cuándo

Todo sistema legacy eventualmente necesita modernizarse. La pregunta no es "¿Debería hacerlo?" sino "¿Cuándo?"

Si tu sistema:

• Tiene 10+ años y nadie entiende el código → Comienza planeación YA.
• Se cae más de 2 veces/año → Plan de 6 meses.
• No integra con herramientas modernas → Roadmap para modernizar.
• Es lento con volumen actual → Ya deberías estar en Fase de desarrollo.

El costo de NO migrar (downtime, productividad perdida, riesgos de seguridad) supera rápidamente el costo de migración planificada.

La clave: Migración por fases, controlada, con datos validados, y equipo dedicado. No es Big Bang. Es modernización gradual mientras el negocio sigue corriendo.