Migración

Qué significa el plazo de preaviso de un proveedor para tu migración

El plazo de preaviso de un proveedor, el periodo entre el anuncio de una retirada o un cierre y la fecha en que realmente entra en vigor, es uno de los recursos más valiosos y más desaprovechados en una migración forzada. Existe precisamente para dar a los equipos que integran el servicio tiempo para reaccionar de forma ordenada, pero un número sorprendente de migraciones acaban aun así haciéndose con prisas en los últimos días, porque las primeras semanas de un plazo de preaviso suelen dedicarse a otras prioridades antes de que la fecha límite parezca real.

El error de fondo es tratar una fecha límite lejana como si no hubiera fecha límite. Un plazo de preaviso de varios meses parece, al principio, tiempo de sobra para planificar una migración cuando convenga. Rara vez sigue siendo conveniente durante mucho tiempo, ya que el resto del trabajo sigue llegando a su propio ritmo, y una fecha límite que parecía cómodamente lejana tiene la costumbre de volverse urgente de golpe.

Una mejor forma de aprovechar un plazo de preaviso es trabajar hacia atrás desde la fecha de corte real e incluir el tiempo de revisión y pruebas que una migración realmente necesita, en lugar de partir de "tenemos tiempo de sobra" y dejar que el calendario se llene de otras cosas. Un reparto razonable para un plazo de preaviso de varios meses podría ser este:

  1. El primer cuarto del periodo: evaluar el alcance completo de lo que depende del servicio retirado, inventariar cada punto de llamada y elegir un sustituto
  2. La mitad central: crear y probar la integración sustituta, incluida la gestión de errores, el comportamiento de la cuota y los casos límite propios de tus datos
  3. El último cuarto: ejecutar ambos proveedores en paralelo si es posible, vigilar las discrepancias y completar el cambio con tiempo real de sobra como margen, no justo al límite de la fecha

Esta estructura trata la última parte del plazo de preaviso como un margen para el retraso inevitable, en lugar de como el periodo en el que se hace el trabajo real, que es donde suelen torcerse las migraciones hechas con prisas.

Si existe un host compatible para el proveedor que se retira, eso cambia cuánto de la fase central, crear y probar la integración sustituta, es realmente necesario, ya que un host compatible equivalente significa que el código de análisis de respuestas que ya tiene tu aplicación no necesita reescribirse en absoluto, solo apuntarse a un nuevo host con nuevas credenciales. Los 17 hosts compatibles de My Geocode, que aparecen en /compatibility/, cubren exactamente este escenario para una gama significativa de proveedores, y merece la pena consultar esa lista al principio del plazo de preaviso, justo en la fase de evaluación, antes de dedicar tiempo de ingeniería a reescribir desde cero una lógica de análisis que un host compatible podría hacer innecesaria.

Sea cual sea el calendario real, la disciplina que más importa es empezar la fase de evaluación el día en que llega el aviso, no la semana en que la fecha límite empieza a parecer cercana.