Cambiar de alojamiento: planificar juntos datos y transición

Para su equipo, el cambio de alojamiento termina cuando el flujo acordado funciona en el nuevo lugar con el estado de datos correcto. Defina antes cuándo se aceptarán modificaciones, quién autoriza la transición y en qué condiciones podrá volver atrás el equipo.

Identificar el flujo y sus vías de escritura

En este ejemplo ficticio, una empresa opera el portal de clientes P-65. Un cliente crea la solicitud A-65 con el adjunto F-65. La base de datos y el almacén de archivos deben tratarse conjuntamente. Además del navegador, una interfaz y un proceso en segundo plano pueden modificar datos. Todas esas vías de escritura deben entrar en el plan.

El ejemplo prevé una pausa de escritura anunciada. Es una elección deliberada, no una exigencia para toda migración. El equipo termina de forma controlada las modificaciones en curso y registra qué trabajos abiertos podrán continuar en destino. Transferir continuamente nuevas modificaciones sería otro método, con sus propias comprobaciones de sincronización y conflictos.

Acordar la transición como secuencia de trabajo

AWS recomienda documentar y ensayar dependencias, orden de tareas, responsables, comprobaciones y retorno antes del cambio. La plantilla cumplimentada describe pasos previstos, no resultados de una migración realizada.

Distinguir parada y retorno de antemano

Microsoft recomienda adaptar los criterios de parada y los pasos de retorno ensayados a la carga de trabajo. En el ejemplo, un adjunto ausente ya impide autorizar. Mientras no se hayan aceptado cambios nuevos en destino, puede servir un retorno preparado al estado antiguo conservado sin cambios.

Tras cambios nuevos en destino, restaurar la dirección DNS no basta. Esas modificaciones pueden faltar en el sistema antiguo. El retorno requiere entonces un estado de datos de referencia definido y un método comprobado para los cambios intermedios. Entretanto no se abren vías paralelas de escritura sin coordinación. Si el equipo no puede tratar ese caso de forma segura, debe revisar el plan antes de autorizar.

Completar conjuntamente DNS y transición

El TTL de DNS describe la caché normal de una respuesta. Algunos clientes pueden seguir usando el acceso antiguo. Su comportamiento debe corresponder a la pausa de escritura o al nuevo sistema de referencia; dos copias modificables de forma independiente no constituyen un cambio terminado.

Compruebe el flujo completo en un entorno de prueba adecuado: solicitud nueva, adjunto, roles y trabajo en segundo plano. Las acciones externas quedan limitadas allí a destinos de prueba. Prevea también supervisión y un contacto responsable tras autorizar. El servicio antiguo se retira cuando se han aclarado las condiciones de finalización y el procedimiento de copia de seguridad.

Fuentes

• AWS: Pre-cutover stage

• Microsoft: Plan your migration

• IETF: DNS Terminology