Migración de software de escritorio y procesos SSIS

El problema no es que todavía exista una app de escritorio o un paquete SSIS. El problema es que muchas veces sostienen procesos críticos sin que nadie pueda describir con precisión dónde termina el escritorio y dónde empieza el ETL. Ahí es donde una migración aparentemente simple termina afectando cierres, conciliaciones o reportes que el negocio necesita al día siguiente.

El riesgo real está en las dependencias invisibles

En este tipo de entornos suele haber más piezas de las que aparecen en el diagrama oficial: drivers de 32 bits, carpetas compartidas con nombres heredados, tareas programadas en un servidor olvidado, archivos Excel que alguien corrige manualmente antes de la carga, credenciales incrustadas o paquetes que solo funcionan porque un equipo específico conserva una configuración vieja.

Mientras esas dependencias no estén mapeadas, la migración no es técnica, es una apuesta.

Qué suele romper un cutover improvisado

• El paquete SSIS corre, pero la cuenta de servicio nueva no ve la carpeta o la base que usaba antes.
• La aplicación abre en el nuevo servidor, pero cambia el driver, la región o el runtime y los resultados ya no coinciden.
• El ETL termina dentro de la ventana esperada en pruebas, pero en producción no aguanta el volumen real.
• El reporte carga, pero cambia un total, una fecha o una lógica intermedia y nadie detecta la diferencia hasta el cierre.

El error común es validar solo que “ejecuta”, cuando lo que de verdad importa es que entregue exactamente el mismo resultado, con mejor trazabilidad y menos fragilidad.

Cómo plantear una migración que sí proteja la operación

1. Levanta el flujo completo, no solo el paquete

Inventario real de fuentes, archivos, jobs, credenciales, ventanas horarias, owners y consumidores aguas abajo. Si el dato termina en un dashboard, un PDF o una conciliación, eso también entra en el alcance.

2. Corre en paralelo antes del día de corte

No basta con una prueba aislada. Conviene comparar varias corridas con datos casi productivos, revisar conteos, totales, tiempos y diferencias en reportes finales. La meta es reconciliar, no solo compilar.

3. Saca la lógica del borde frágil

Siempre que sea posible, mueve archivos locales a storage administrado, centraliza schedules, reduce intervención manual y deja explícitas las dependencias técnicas. Una migración bien hecha también simplifica la operación futura.

4. Observa el comportamiento después del cambio

Logging, alertas, ownership y rollback claro para las primeras ejecuciones. Muchas fallas no aparecen en el primer run, sino cuando coinciden picos de volumen, ventanas apretadas o un refresh posterior de BI.

Señales de que ya no conviene esperar

• Solo una o dos personas entienden cómo corre el flujo completo.
• Un upgrade de sistema operativo o de SQL quedó frenado por compatibilidades viejas.
• Las cargas nocturnas ya van al límite y cualquier desviación rompe la ventana.
• Seguridad o compliance ya cuestionan componentes sin soporte o accesos poco auditables.

Cómo lo abordamos en Eximus

En Eximus tratamos estas migraciones como trabajo de continuidad operativa, no como un simple movimiento de servidor. Primero aislamos dependencias, luego probamos en paralelo y recién después hacemos el cutover. Cuando hace falta, afinamos SQL, reforzamos monitoreo y ordenamos la capa de reporting para que la mejora no termine trasladando el problema a BI.

Próximo paso

Si tienes SSIS o software de escritorio sosteniendo procesos críticos, vale la pena revisar qué dependencias invisibles siguen ahí antes de mover nada. Podemos ayudarte a definir un cutover por fases, con validación paralela y resguardo de performance. Contáctanos o explora SQL Performance Boost y Power BI in Order.