Evaluar antes de planificar
Empezamos con un inventario: versión y nivel de parches, personalizaciones, integraciones, volúmenes de datos y la infraestructura que hay debajo. Cada personalización se clasifica como mantener, reescribir o retirar, porque el código más barato de actualizar es el que ya no necesita.
Ensayar hasta que resulte aburrido
La actualización se ejecuta una y otra vez sobre una copia de producción. Cada ensayo se cronometra, se valida con las pruebas de aceptación acordadas y se traduce en un runbook más preciso. En el último ensayo, el plan de cutover se mide en horas y minutos, no se estima a ojo.
Cutover con vuelta atrás
La puesta en producción sigue el runbook paso a paso, con puntos de go/no-go y un rollback ya probado. Los usuarios vuelven a un sistema que los usuarios clave han comprobado antes de que acabe el fin de semana.
Migrar a la nube
Una migración a la nube mueve a la vez los vaults, la base de datos y la aplicación, así que la tratamos como un proyecto de migración y no como un simple cambio de hosting. Puede aterrizar en máquinas virtuales o ir directamente a contenedores; en ambos casos, el despliegue está automatizado desde el primer día.
Dejar atrás un sistema heredado
Los datos de sistemas PDM o PLM antiguos, o de carpetas compartidas, se cargan en ensayos sucesivos hasta que cuadran recuentos, enlaces y estados. Acordamos con usted qué merece la pena migrar; el histórico que nadie volverá a abrir puede quedarse archivado.