Migración de plataforma IoT: guía para no perder datos

Los dispositivos se reconectan en un día. El histórico, no. Toda migración de plataforma IoT se juega en los datos que ya tienes: cinco años de telemetría, las reglas de alerta que alguien ajustó a mano un domingo, y el código que convierte un payload de 11 bytes en una lectura de nivel. Reapuntar un endpoint MQTTProtocoloMQTTEl protocolo pub/sub estándar del IoTVer perfil es la parte fácil, y es la única que suele estar en el plan.

Esta guía recorre el proceso completo tal y como lo afrontan integradores y fabricantes cuando cambian la plataforma que sostiene su producto: qué inventariar antes de tocar nada, cómo se ejecuta el cambio en cinco fases sin ventana de apagón, cómo demostrar después que no falta un solo registro, y qué exigir a la plataforma destino para no repetir el ejercicio dentro de dos años.

El contexto ayuda a entender por qué el tema aparece cada vez más en las mesas técnicas. Según IoT Analytics, el parque mundial de dispositivos conectados supera los 18.000 millones de unidades, y una parte importante de esos despliegues ya no es nueva: son proyectos de hace cinco o siete años que arrastran decisiones de plataforma tomadas cuando el parque tenía 200 equipos y hoy tiene 20.000.

Qué se pierde de verdad en una migración de plataforma IoT

La telemetría en vivo es el activo más visible y el menos problemático. Un sensor que publica cada 15 minutos empieza a publicar contra otra dirección en cuanto se le cambia la configuración, y a partir de ahí la plataforma nueva tiene datos frescos. El problema está en todo lo demás.

El histórico. Cinco años de lecturas a 15 minutos por 4.000 dispositivos son unos 700 millones de puntos. Ese volumen no cabe en una exportación por interfaz web, ni suele estar disponible en un formato directamente cargable. Y sin histórico, cualquier función que dependa de comparar contra el pasado (líneas base de consumo, umbrales adaptativos, informes anuales, modelos de mantenimiento predictivoMCaso de usoMantenimiento predictivoVer perfil) nace ciega el primer día.

Las identidades de dispositivo. En LoRaWANProtocoloLoRaWANLPWAN abierta de largo alcance y bajo consumoVer perfil son el DevEUI, el JoinEUI y las claves de aplicación; en MQTT, los client ID y sus credenciales o certificados. Cambiar de plataforma implica reprovisionar cada equipo, y en despliegues con sensores en arquetas, torres o cámaras frigoríficas, "reprovisionar" puede significar una visita física. El plan de migración que ignora ese coste se desvía en meses.

Los decoders. El código que traduce el payload binario a magnitudes con unidades es propiedad intelectual acumulada, muchas veces escrita para un runtime concreto de la plataforma origen. Es la pieza que más se subestima y la que con más frecuencia obliga a reescribir.

Luego está todo lo que se configuró una vez y nadie volvió a mirar. Una instalación madura acumula cientos de reglas de alerta con sus umbrales, su histéresis, sus ventanas de silencio y sus listas de correo o teléfonos, y casi nunca están documentadas fuera de la propia plataforma. Con las integraciones salientes pasa igual: webhooks hacia el ERP, consultas del BI, capas del GIS, tickets automáticos en el sistema de mantenimiento. Cada una tiene una credencial y un contrato de datos que hay que replicar en destino, y la forma habitual de descubrir que faltaba una es que un informe deje de actualizarse.

Antes de negociar plazos con nadie, exporta 24 horas de datos de un solo dispositivo de principio a fin. Ese ensayo revela en una tarde si la plataforma origen limita el ritmo de descarga, si el timestamp viene en hora local sin zona, o si el histórico está agregado y ya no existe el dato crudo.

Los cinco activos que hay que inventariar antes de mover nada

El inventario es el entregable que convierte una migración en un proyecto acotado. Sin él, el equipo descubre los requisitos a medida que rompe cosas.

El quinto punto merece atención especial si eres integrador. En una plataforma multi-tenant, la migración no traslada una jerarquía de datos: traslada un modelo de negocio. Cada cliente final tiene su ámbito, sus usuarios y a veces su marca. Reconstruir eso a mano en destino es donde se va el tiempo que nadie presupuestó.

Un apunte legal que juega a favor. El Reglamento de Datos de la Unión Europea, en aplicación desde septiembre de 2025, obliga a los proveedores de servicios de tratamiento de datos a facilitar el cambio de proveedor: plazos máximos para la transición, exportación en formato estructurado y de uso común, y eliminación progresiva de las tarifas de salida. Si tu proveedor actual opera en la UE, puedes reclamar la portabilidad de tus datos por escrito y apoyarte en esa norma.

¿Quieres una referencia de cómo se aborda esto cuando el servicio de origen ya está descatalogado? Las rutas de migración para servicios IoT discontinuados siguen exactamente este orden de trabajo.

Migración de plataforma IoT paso a paso: cinco fases

Nunca apagues el origen para encender el destino. Las dos plataformas conviven durante semanas, y el corte es una decisión administrativa que se toma cuando los datos ya demuestran que el destino funciona. Casi todos los desastres que hemos visto contar empiezan por saltarse esto.

Fase 1. Auditoría y exportación de prueba

Completa el inventario anterior y ejecuta una exportación real de una muestra: un dispositivo, un mes, todos sus campos. Mide cuánto tarda, en qué formato sale y con qué límites de peticiones. Multiplica por el parque completo y ya tienes la duración de la fase de carga, que en despliegues grandes se cuenta en días, no en horas.

De ese ensayo salen dos cifras que pertenecen al plan de proyecto. La primera es el techo de velocidad de exportación, que casi siempre lo marca un límite de peticiones de la API y no el ancho de banda. La segunda es el coste de salida de datos, que algunos proveedores facturan por gigabyte que abandona su infraestructura. Un parque con años de histórico a alta frecuencia puede convertir esa línea en una factura de cuatro cifras, y conviene descubrirla en la primera semana y no en la del corte.

Fase 2. Mapeo del modelo de datos

Aquí se decide la calidad del resultado. Punto por punto: nombres de variable, unidades, tipos, precisión, tratamiento de nulos y, sobre todo, marcas de tiempo. Todo a UTC en el destino, con la zona horaria como atributo de presentación. Las migraciones que mezclan hora local y UTC producen huecos de una hora dos veces al año, y esos huecos aparecen meses después en un informe de facturación.

Si en origen el histórico está agregado por hora pero el dato crudo cada 15 minutos ya no existe, esa pérdida es irreversible: documéntala ahora y decide si el destino guarda ambas resoluciones. Este es también el momento de revisar el modelo de dispositivo, porque una plataforma con soporte nativo de sensores y protocolos heterogéneos permite normalizar familias que en origen estaban resueltas con parches.

Fase 3. Doble ingesta

En lugar de mover los dispositivos, se duplica el flujo. Un bridge MQTT en el broker de origen, o una salida adicional en el gateway, reenvía cada mensaje también a la plataforma nueva. Los dispositivos no se tocan, el origen sigue operando como sistema de referencia y el destino empieza a recibir datos reales en producción.

Si el bridge no es posible porque el proveedor de origen no lo permite, la alternativa es reconfigurar los dispositivos por grupos pequeños, empezando por una familia poco crítica y accesible físicamente.

El orden de esos grupos no es arbitrario. Se ordenan por tres criterios combinados: criticidad del servicio que sostienen, accesibilidad física del equipo y complejidad del decoder. El primer grupo debe puntuar bajo en los tres, porque su función real es descubrir los problemas del procedimiento cuando todavía son baratos. Los equipos críticos y de difícil acceso van los últimos, cuando el procedimiento ya se ha ejecutado veinte veces y tiene su lista de comprobación depurada. Conviene entender bien cómo funciona un broker MQTT y su modelo de publicación y suscripción antes de diseñar este reparto, porque de él dependen la duplicación de mensajes y el consumo de datos durante la convivencia.

Fase 4. Carga del histórico

Con la doble ingesta corriendo, el histórico se carga en frío por lotes, empezando por lo más reciente. Ese orden importa: si el proyecto se detiene a mitad, tendrás el último año completo en lugar de los cinco años de hace una década. Cada lote se verifica al terminar, y se registra el rango cargado por dispositivo.

Fase 5. Corte y ventana de reversión

El corte llega cuando los dos sistemas llevan al menos dos semanas coincidiendo. Se detiene la escritura en origen, se mantiene su lectura durante 30 a 90 días, y se comunica una fecha concreta de baja.

El plan de reversión se escribe antes del corte, no durante la incidencia. Debe caber en una página y responder a tres preguntas: quién decide volver atrás, qué hay que ejecutar para que los dispositivos vuelvan a publicar en origen, y qué se hace con los datos que llegaron al destino mientras tanto. Mientras la configuración anterior siga viva en los dispositivos, revertir cuesta minutos; una vez borrada, cuesta una campaña de campo. Nadie borra nada hasta que ha pasado un ciclo completo de facturación y un cierre mensual con informes contra el sistema nuevo.

¿Necesitas contrastar este plan con tu parque real? Habla con el equipo y revisamos volumen, protocolos y ventana de convivencia antes de que muevas un solo dispositivo.

Convivencia: por qué vas a operar dos plataformas a la vez

La fase de solapamiento incomoda a quien firma las facturas y tranquiliza a quien opera. Suele durar entre dos y ocho semanas, y tiene tres efectos que conviene anticipar.

Coste doble temporal. Dos suscripciones y, en despliegues celulares, más consumo de datos si el dispositivo publica dos veces. Se presupuesta desde el principio, no se descubre en la factura del segundo mes. La duplicación en el servidor, mediante bridge, evita ese sobrecoste de conectividad por completo: el dispositivo transmite una vez y es la infraestructura la que reparte. En redes con limitación de ciclo de trabajo, como LoRaWAN en la banda de 868 MHz, duplicar en el dispositivo suele ser inviable: el margen legal de emisión no da para transmitir dos veces.

Alertas duplicadas. Con dos plataformas evaluando las mismas reglas, cada incidencia genera dos avisos. La práctica sana es silenciar las notificaciones en el destino durante la convivencia y comparar sus disparos contra los del origen en un panel interno. Si la nueva plataforma habría avisado con los mismos umbrales y a la misma hora, la regla está bien portada.

Divergencia silenciosa. Un decoder mal portado no rompe nada: escribe un número plausible pero equivocado. Por eso la comparación no puede ser visual. Se hace con consultas de agregados sobre las dos bases, dispositivo a dispositivo y día a día.

El criterio de salida de la convivencia se define antes de entrar en ella. Por ejemplo: siete días consecutivos con menos del 0,1% de discrepancia en conteo de mensajes, cero diferencias en agregados diarios de las variables de facturación, y todas las alertas críticas reproducidas.

Cómo verificar que no falta un solo dato

La verificación es la parte del proyecto que se corta cuando hay prisa, y es la única que produce evidencia. Cuatro comprobaciones cubren la mayoría de los fallos reales.

Conteo por dispositivo y día. Una tabla con dispositivo, fecha y número de registros en cada sistema. Las diferencias se ordenan de mayor a menor y se investigan de arriba abajo. Los huecos casi siempre se agrupan: un día concreto, una familia de sensores, un gateway. Que se agrupen es justo lo que hace manejable el ejercicio: un hueco compartido por todos los dispositivos de un mismo gateway apunta a la ruta de reenvío, mientras que un hueco repartido por una familia de dispositivos en todos los gateways apunta al decoder o al lote de aprovisionamiento. Los huecos aislados de un solo equipo suelen ser reales, y se corresponden con una caída que también existe en origen: el informe de reconciliación debe decirlo de forma explícita en lugar de dejarlo a la interpretación de quien lo lea.

Agregados diarios. Para cada variable numérica: mínimo, máximo, media y suma por día. Coincidir en conteo pero no en agregados delata un problema de escala o de unidades, que es exactamente el fallo que un decoder mal portado produce.

Muestreo aleatorio con valor crudo. Cincuenta registros al azar de todo el periodo, comparados campo a campo contra el payload original. Es la única prueba que verifica la cadena completa, del byte a la lectura.

Prueba de alertas con evento sintético. Se inyecta una lectura fuera de umbral en el destino y se comprueba que el aviso sale, llega al destinatario correcto y respeta la ventana de silencio.

El resultado de las cuatro se guarda en un informe con fecha. Cuando dentro de dos años alguien pregunte por qué un consumo de 2024 no cuadra, ese documento es la diferencia entre una respuesta y una tarde de arqueología.

Qué exigir a la plataforma destino para no repetir esto

Una migración se asume una vez. Tener que repetirla a los dos años por haber elegido mal el destino se evita con cinco preguntas planteadas antes de firmar.

1. ¿Cómo salgo? Pide la documentación de la API de exportación masiva, su límite de peticiones y su coste. Si la respuesta es un formulario de soporte, ya sabes lo que costará irse.
2. ¿Los decoders son míos y son portables? Deben ser código en un lenguaje estándar, versionable en tu repositorio, no una configuración atrapada en una interfaz.
3. ¿El modelo multi-tenant encaja con mi negocio? Si revendes a clientes finales, necesitas aislamiento por cliente, marca propia y administración delegada desde el primer día, no como desarrollo a medida.
4. ¿Qué integraciones nativas trae? Una plataforma con API abierta y webhooks documentados evita la capa intermedia que acabas manteniendo tú. Nuestro trabajo de integración de sistemas parte casi siempre de ahí.
5. ¿Dónde se despliega? Nube o instalación propia, y con qué política de retención. Muchas migraciones se originan por un requisito de soberanía del dato que apareció después del contrato inicial.

Un ejemplo del efecto de estas preguntas: un operador con red propia que documenta sus decoders y guarda el dato crudo puede cambiar de plataforma en semanas. Otro con la misma cantidad de sensores, pero con la lógica escrita dentro de la herramienta y sin dato crudo, se enfrenta a un proyecto de meses o a la pérdida definitiva del histórico. Lo que separa un caso del otro son decisiones de arquitectura tomadas años antes, no la tecnología de radio ni el tamaño del parque. En despliegues de sensórica urbana, donde el parque se mide en miles de puntos, esa diferencia se nota especialmente, como se ve en cualquier red LoRaWAN municipal a escala de ciudad.

Los protocolos estándar juegan a tu favor. Un parque que habla MQTT según la especificación de OASIS o LoRaWAN conforme a la especificación de LoRa Alliance es portable por definición. El acoplamiento aparece más arriba, en la capa de aplicación: los decoders y el formato en que se guarda el histórico.

Conclusión

En una migración de plataforma IoTITérminoIoT (Internet de las cosas)El IoT (Internet of Things) es la red de objetos físicos con sensores, software y conectividad que recogen e intercambian datos y actúan de forma autónoma.Ver perfil bien ejecutada, el día del corte es el menos interesante del proyecto. El trabajo está antes: el inventario, las semanas de convivencia y el informe de verificación que demuestra que los datos están completos.

Los puntos que marcan la diferencia:

• El histórico y los decoders son los activos en riesgo, no la conectividad de los dispositivos.
• Doble ingesta antes que big bang: las dos plataformas conviven semanas y el origen sigue siendo la referencia hasta que los datos digan lo contrario.
• Marcas de tiempo en UTC y un mapeo de unidades explícito evitan errores que aparecen meses después.
• Verificación en cuatro capas: conteos, agregados, muestreo crudo y prueba de alertas, con informe fechado.
• Elige el destino por su puerta de salida, no solo por sus funciones.

El siguiente paso práctico es el ensayo de exportación: un dispositivo, un mes, todos los campos. Con ese resultado en la mano, el plazo de la migración deja de ser una estimación y pasa a ser un cálculo. Si quieres contrastarlo con quien ha hecho el ejercicio en despliegues de miles de dispositivos, reserva una demo y lo revisamos con tus números.