Cómo funciona la publicidad en tu sector
La conversación que ordena todo el proyecto no es técnica: es saber qué sistemas pueden estar parados, cuánto tiempo y en qué franja. De eso depende la estrategia entera, el orden, el coste y el riesgo. Empezar por ahí, y no por la arquitectura destino, es lo que diferencia una migración planificada de una aventura.
En toda migración aparece algo que nadie sabía que existía: un servidor bajo una mesa, una aplicación que usa un solo departamento, una integración con un proveedor externo, una tarea programada que nadie recuerda haber creado. Por eso el inventario previo no es burocracia: es lo que evita la mitad de los sustos del proyecto.
Conviene planificar la vuelta atrás antes de empezar: qué se hace si algo no funciona el lunes por la mañana, cuánto tiempo se mantiene lo antiguo encendido, cómo se decide abortar. Un cliente que sabe que hay plan B acepta mucho mejor el riesgo, y un proyecto sin ese plan es el que acaba en una crisis muy cara.
Y conviene ser claro con lo que no mejora sola una migración: una aplicación lenta seguirá siendo lenta, un proceso mal diseñado seguirá mal, unos datos sucios seguirán sucios. Prometer que todo irá mejor por el hecho de cambiar de sitio es la forma más rápida de que el cliente se sienta engañado a los dos meses.