Convivencia de dos proveedores en una migración

Cambiar de proveedor de datos no es un interruptor. Entre la primera consulta al proveedor nuevo y la última al que se retira hay un período en el que dos fuentes describen la misma realidad, y ese período tiene reglas propias.

La tentación es tratarlo como un asunto de infraestructura: se levanta el conector nuevo, se compara a ojo y se apaga el viejo. Pero la convivencia se juega en el dato que ve quien consulta: si nadie define cuál de las dos respuestas es la vigente, una misma patente puede devolver resultados distintos según el camino que tomó la consulta.

Llamamos convivencia al estado transitorio en el que ambos proveedores están conectados y se comparan, pero sólo uno gobierna la respuesta publicada. El otro corre en sombra: se ejecuta, se registra y no se muestra.

La unidad que migra es la fuente, no el proveedor entero

Un proveedor no cubre una jurisdicción sola y rara vez se comporta igual en todas. Migrar de una sola vez obliga a aceptar o rechazar en bloque comportamientos distintos: puede resolver bien un municipio y devolver campos incompletos en otro.

Conviene declarar la unidad de corte por fuente —jurisdicción, portal o trámite— y llevar una tabla con el proveedor vigente de cada una, la fecha desde la que rige y el estado de la comparación. Esa tabla es el único lugar donde se decide qué se publica: el código la lee, no la deduce.

Una identidad propia para dos orígenes

El riesgo más caro de la convivencia es la duplicación. Si la clave de una infracción se deriva del identificador interno del proveedor, el mismo hecho aparece dos veces cuando llega por dos caminos.

La clave tiene que ser propia y estable, con los criterios que describimos en identificadores estables. Para emparejar registros que llegan en formatos distintos conviene normalizar primero y comparar después. RFC 8785 sirve para el segundo paso: define una serialización canónica de JSON —orden de las claves, espacios, forma de los números— para que dos representaciones equivalentes produzcan el mismo texto y el mismo resumen. Lo que no hace es igualar dos fechas escritas distinto: eso sigue siendo trabajo del normalizador.

El emparejamiento tampoco es siempre completo. Un registro puede existir en un proveedor y no en el otro; ese caso se marca, no se descarta.

Clasificar las diferencias antes de decidir cuál prevalece

Cuando los dos proveedores no coinciden, “hay una diferencia” es información pobre. Al menos cuatro casos piden respuestas distintas:

diferencia de normalización: el mismo dato con otro formato de fecha, monto o estado;
diferencia de cobertura: uno completa un campo que el otro nunca trae;
diferencia de momento: cada consulta llegó al portal en un instante distinto;
diferencia real: ambos leyeron lo mismo y afirman cosas incompatibles.

Las tres primeras se resuelven en el normalizador o en el diseño de la comparación; la cuarta obliga a volver a la fuente oficial antes de tocar nada.

Validar ambas respuestas contra el mismo esquema separa un problema de forma de uno de contenido: JSON Schema describe tipos y campos requeridos con una única definición. Con format conviene ser prudente: en la especificación de validación 2020-12 se recoge como anotación y su evaluación es opcional y viene desactivada por defecto, así que un esquema que confía sólo en format puede dar por buena una fecha con otra forma.

Distinguir el tercer caso del cuarto exige saber de dónde salió cada valor. PROV-O modela esa cadena con entidades, la actividad que las generó y el agente responsable, y el detalle está en proveniencia campo por campo. Sin ese registro, un cambio de proveedor y un cambio real en el portal se vuelven indistinguibles.

Que el corte no invente infracciones nuevas

Si el sistema emite eventos o alertas, la convivencia puede fabricar avisos falsos: el día del cambio, todo lo que el conector nuevo ve por primera vez se parece a un alta.

Dos reglas ayudan. La primera es emitir por primera observación de esa identidad en el sistema, no por primera observación de ese conector. La segunda es que la fuente del evento describa al sistema que publica y no al proveedor que lo alimentó: CloudEvents pide que el par de identificador y fuente sea único por evento, y habilita al receptor a tratar como duplicados los que comparten ambos valores. Si la fuente se muda con el proveedor, el mismo hecho vuelve a parecer nuevo. Qué evento corresponde a cada cambio está en alta, corrección y retiro.

El corte se decide con un umbral, no con una fecha

Antes de encender la convivencia conviene escribir la condición de salida: cuántos días de comparación, qué proporción de registros emparejados y qué diferencias son tolerables para esa fuente. Sin ese umbral, la decisión se apoya en la impresión de que viene andando bien.

La vuelta atrás debería costar lo mismo que el avance: si el proveedor vigente cambia editando una fila, revertirlo también.

Antes de apagar el proveedor saliente, verificá que la tabla de vigencia esté completa; que ningún identificador publicado dependa del proveedor; que las diferencias abiertas estén clasificadas y no sólo contadas; y que exista al menos un ensayo de vuelta atrás. Una migración prolija no se nota en la respuesta.

Metodología

Alcance: Operación del período en que dos proveedores de datos de infracciones están conectados en paralelo, desde el encendido del segundo conector hasta el apagado del primero. No evalúa proveedores concretos ni compara ofertas comerciales.
Unidad de análisis: Una fuente consultable —jurisdicción, portal o trámite— con su proveedor vigente y el resultado de comparar ambas respuestas para una misma consulta.
Cobertura: Prácticas de identidad, comparación, eventos y proveniencia derivadas de especificaciones abiertas de canonicalización JSON, validación por esquema, formato de eventos y modelado de procedencia.

Limitaciones

Los umbrales de emparejamiento y la duración de la ventana de sombra dependen del volumen y la variabilidad de cada fuente, y no se pueden fijar de forma universal.
La comparación entre proveedores detecta desacuerdos, pero no determina por sí sola cuál de los dos refleja el portal oficial en ese momento.
Correr dos conectores en paralelo duplica consultas contra el mismo origen y puede chocar con límites de uso del proveedor o del portal.

Fuentes

RFC 8785 JSON Canonicalization Scheme — RFC Editor (consultada el 2026-08-29)
CloudEvents specification — Cloud Native Computing Foundation (consultada el 2026-08-29)
JSON Schema Validation Draft 2020-12 — JSON Schema (consultada el 2026-08-29)
PROV-O — The PROV Ontology — World Wide Web Consortium (consultada el 2026-08-29)

Preguntas frecuentes

¿Por qué no cambiar todas las fuentes de proveedor el mismo día?

Sobre todo porque el corte deja de ser reversible en la práctica. Con una fuente por vez, volver atrás es editar una fila; con todas juntas hay que elegir entre convivir con un problema puntual o revertir la migración entera. El contrapeso es que cada fuente en convivencia duplica consultas contra el mismo origen, así que tampoco conviene estirar el período sin necesidad.

¿Una diferencia entre los dos proveedores significa que uno se equivoca?

No necesariamente. Lo más habitual es que difieran en la forma del dato, en qué campos completa cada uno o en el instante en que cada consulta llegó al portal. Recién cuando ambos leyeron lo mismo y afirman cosas incompatibles hay un desacuerdo real, y ahí compararlos entre sí no alcanza para resolverlo: hay que ir a la fuente oficial.

¿El cambio de proveedor puede generar avisos de multas que ya existían?

Sí, y es el efecto más visible para quien recibe la notificación, porque el día del corte todo lo que el conector nuevo ve es nuevo para él. Conviene comprobarlo antes con el conector en sombra sobre un lote de identidades ya conocidas y confirmar que no dispara ningún aviso.

¿Cuándo se apaga el proveedor saliente?

Cuando se cumple la condición de salida que se escribió antes de encender la convivencia, no cuando llega la fecha prevista. Apagar el conector tampoco es lo mismo que dar de baja el contrato: conviene conservar acceso de lectura mientras dure la reconciliación, porque las preguntas difíciles aparecen después del corte.

Convivencia de dos proveedores durante una migración