Cambiar de proveedor de datos de multas sin cortar el servicio

Cambiar el proveedor que entrega los datos de infracciones rara vez falla por el código. Escribir un cliente HTTP nuevo lleva poco; lo difícil es sostener un servicio que ya alimenta tableros, avisos y decisiones de cobro mientras dos respuestas distintas describen lo mismo.

Una migración sin corte tampoco es un despliegue con una bandera de funcionalidad. Es un período de convivencia con reglas explícitas: qué se compara, qué diferencia se acepta, quién autoriza el corte y qué queda del lado anterior.

Un modelo propio antes que un cliente nuevo

Si el sistema habla el dialecto del proveedor —sus nombres de campo, sus códigos de estado, su forma de paginar— migrar significa reescribir todo lo que lo toca. Llamamos fachada a la alternativa: un modelo interno de infracción, jurisdicción y estado, con un adaptador por proveedor que traduce hacia él.

Esa capa convierte la migración en una decisión de configuración y no en un refactor, y es donde queda anotado de qué jurisdicción vino cada campo. Si no existe, construila antes de integrar al proveedor nuevo: migrar y desacoplar a la vez mezcla dos causas de error.

Mapear el contrato campo por campo

La descripción del proveedor nuevo —una especificación OpenAPI, por ejemplo— permite comparar tipos, formatos, campos obligatorios y enumeraciones contra el modelo interno antes de escribir el adaptador. Es un contrato de forma, no de contenido: dice cómo viene la respuesta, no qué cubre.

El mapeo se hace en dos columnas. Una estructural: nombre, tipo, formato de fecha, precisión del monto, si el campo puede faltar. Otra semántica: qué significa ese estado del acta y si el proveedor lo deriva o lo copia de la jurisdicción.

Los campos sin equivalente son la parte útil del ejercicio: un dato que el anterior completaba y el nuevo deja vacío no es un error del adaptador, es una diferencia de cobertura que hay que aceptar o cubrir con otra fuente.

Convivencia: consultar a los dos y servir uno solo

Durante la convivencia el sistema consulta las mismas patentes a los dos y responde con el proveedor vigente. La respuesta del candidato se guarda y se compara, pero no llega al usuario.

La comparación necesita una clave estable para afirmar que dos actas describen el mismo hecho. Sin eso, una diferencia de orden, paginación o normalización se lee como un alta o una baja que nunca ocurrió.

Antes de discutirla, clasificá cada diferencia en tres cajones:

• diferencia de cobertura: una fuente que un proveedor consulta y el otro no;
• diferencia de momento: el mismo hecho visto con distinto retraso de actualización;
• diferencia de traducción: el adaptador interpretó mal un estado, una fecha o un monto.

Sólo el tercer cajón es un defecto a corregir; los otros dos son insumo para decidir y quedan escritos antes del corte. La doble lectura tiene costos: cuota en ambos lados, más latencia si las consultas son sincrónicas y una copia adicional de datos personales mientras dure.

El corte se hace por segmentos, con vuelta atrás

Cortar todo un martes a las nueve convierte cualquier sorpresa en incidente. Es preferible avanzar por segmentos —una jurisdicción, un grupo de patentes, un cliente interno— con los dos proveedores activos mientras se asienta.

Cada segmento necesita criterios de vuelta atrás decididos antes: tasa de error, respuestas vacías donde antes había actas, demoras de actualización o reclamos. Cuando el criterio se cumple, se vuelve al anterior sin discutirlo.

La vuelta atrás sólo existe mientras la credencial anterior siga viva y probada: una clave vencida convierte el plan en una intención. Por eso la rotación de credenciales merece su propia ventana.

Cerrar con el proveedor anterior es parte de la migración

Una migración que “terminó” pero deja la integración vieja encendida es una deuda silenciosa. El cierre tiene tres piezas.

Primero, avisar a los consumidores internos si la fachada cambia. HTTP tiene dos señales, ambas referidas al recurso identificado por una URL: Deprecation marca que ese recurso va a entrar o ya entró en desuso, y Sunset publica el momento a partir del cual es probable que deje de responder. Anunciar con fecha sale más barato que romper y explicar después.

Segundo, el histórico: antes de revocar el acceso, exportá las actas obtenidas con el proveedor anterior y verificá que se leen sin su API, con la evidencia de qué patente se consultó y cuándo.

Tercero, los datos que quedan del otro lado. La ley nacional de protección de datos personales define el tratamiento de manera amplia: incluye la conservación y la cesión a terceros. El cierre debería dejar por escrito qué hace el proveedor saliente con lo que recibió. Es orientación general, no asesoramiento.

Una migración sin corte se reconoce por lo aburrido que resulta el día del corte: con el modelo interno en su lugar, las diferencias clasificadas y los segmentos movidos de a uno, cambiar de proveedor es apagar un adaptador. Antes de darla por terminada, verificá que nadie consulte al anterior, que el histórico se lea sin su API y que la convivencia haya cerrado en la fecha anunciada.

Preguntas frecuentes

¿Cuánto tiene que durar la ventana en que conviven dos proveedores?

No hay un número universal. Debería cubrir el ciclo de datos que importa —altas, correcciones y bajas— en los segmentos ya migrados, y tener fecha de cierre desde el primer día. Extenderla sin criterio duplica costo, cuota y copias de datos personales.

¿Una diferencia entre los dos proveedores significa que uno está mal?

No necesariamente. Puede ser cobertura distinta, otro momento de actualización, otra normalización o un vocabulario de estados que no coincide. Conviene clasificar cada diferencia antes de tratarla como defecto: sólo algunas son errores del adaptador.

¿Se puede migrar y apagar el proveedor anterior el mismo día?

Se puede, pero se pierde la vuelta atrás. Mientras el acceso anterior siga vigente y probado, un segmento con problemas vuelve sin negociación. Apagar el mismo día convierte cualquier diferencia inesperada en un incidente sin salida ordenada.

¿Qué pasa con el histórico consultado con el proveedor anterior?

Conviene exportarlo y verificar que se puede leer sin su API antes de revocar el acceso, incluida la evidencia de qué se consultó y cuándo. Además, el cierre debería definir por escrito qué hace el proveedor saliente con los datos que recibió.

Notas relacionadas