# ¿Qué es el vendor lock-in en las plataformas de IoT y cómo lo evito?

> El vendor lock-in es el coste de salir de una plataforma IoT. Las cuatro superficies donde se acumula (datos, aprovisionamiento y decodificación, lógica de aplicación, condiciones comerciales), el ensayo de salida que conviene hacer antes de firmar y cómo es la portabilidad honesta.

![¿Qué es el vendor lock-in en las plataformas de IoT y cómo lo evito?](https://tago.io/og/es/blog/vendor-lock-in-in-iot-platforms.png)

Nadie elige una plataforma IoT con el plan de dejarla. La eliges para poner algo en marcha y, cuanto más rápido te deja construir, más honda se asienta en tu arquitectura: decodificadores de dispositivo, dashboards, scripts de automatización, reglas de alerta, gestión de usuarios. Cada pieza ahorra semanas. Pero cada pieza es también un hilo de dependencia, y los hilos suman una cifra que nadie te menciona al firmar: el coste de salir.

Ese coste es el vendor lock-in, y permanece invisible hasta que una subida de precio, una adquisición o una hoja de ruta encallada obligan a preguntar qué exigiría una migración. La respuesta vive en cuatro superficies concretas, y las cuatro se pueden comprobar antes de firmar nada.

![Las cuatro superficies donde se acumula el lock-in: los datos y cómo salen, el aprovisionamiento y la decodificación, la lógica de aplicación y las condiciones comerciales](https://tago.io/images/blog/vendor-lock-in-in-iot-platforms/vendor-lock-in-four-surfaces.svg)

## Superficie uno: tus datos y cómo salen

Los datos son la superficie obvia y aun así la peor tratada, porque se divide en dos preguntas que muchos tratan como una.

La primera es de propiedad: ¿dice el contrato con claridad que los datos son tuyos y que el proveedor es un encargado que los trata en tu nombre? La segunda es de mecánica: ¿puedes exportarlo todo, en un formato documentado, por una API que no estrangule las lecturas masivas hasta volverlas inútiles?

Un proveedor puede concederte la propiedad en el papel y aun así retener tu histórico en la práctica, porque cinco años de series temporales detrás de un endpoint con límite de tasa es un secuestro con pasos extra. Ve más allá de la respuesta de marketing. Un "sí, puedes exportar tus datos" vago no es lo mismo que una exportación masiva documentada a CSV, JSON o una lectura directa. Pregunta si la exportación cubre los payloads brutos de los dispositivos o solo los valores agregados que el dashboard muestra. Pregunta por límites de filas, ventanas temporales y cuánto cuesta sacar años de datos de golpe.

La mitad contractual la cubrimos en [de quién son tus datos de IoT](https://tago.io/blog/who-owns-your-iot-data-residency-gdpr). La mitad mecánica se verifica en una cuenta de prueba, no en una llamada comercial. Esta es la superficie por la que hay que pelear más fuerte, porque es la única que empeora cuanto más tiempo te quedas.

## Superficie dos: aprovisionamiento de dispositivos y decodificación de payload

Tus dispositivos hablan binario. En algún sitio, un código convierte esos payloads en lecturas de temperatura y estados de puerta, y dónde vive ese código decide lo portable que es tu flota.

Si los decodificadores son una caja negra dentro de la plataforma, cada tipo de dispositivo que incorporas profundiza la dependencia, porque migrar implica reescribir una lógica de decodificación que no puedes ver, modelo a modelo. El aprovisionamiento funciona igual: si añadir un dispositivo exige herramientas propietarias sin equivalente por API, volver a registrar miles de unidades en otra plataforma se convierte en un proyecto manual y no en un script.

La capa de transporte importa igual. MQTT es el protocolo abierto habitual para telemetría: está publicado, ampliamente implementado, y tu dispositivo lo habla igual con cualquier broker. Para redes de sensores de largo alcance, LoRaWAN cumple el mismo papel, con las capas de network y application server definidas por una especificación abierta y no por una empresa. Un dispositivo que habla MQTT puro o vive en una red LoRaWAN estándar se puede apuntar a un endpoint nuevo con un cambio de configuración en lugar de una visita a campo. Uno que solo habla el protocolo propietario de un proveedor no, y reflashear una flota ya desplegada no es una migración, es una retirada de producto.

Busca decodificadores que puedas leer y copiar, escritos en un lenguaje estándar, y aprovisionamiento que funcione de punta a punta por una API documentada.

## Superficie tres: lógica de aplicación atada a servicios propietarios

Esta es la superficie que ingeniería subestima. Los dashboards se reconstruyen en una semana; la lógica que hay detrás es la inversión de verdad.

Las reglas de alerta, los trabajos programados, las transformaciones de datos y las integraciones con terceros se acumulan durante años y, si se escribieron contra abstracciones propietarias sin equivalente estándar, son la parte de la migración que reescribes desde cero.

No puedes eliminar esta superficie, y no deberías intentarlo, porque una plataforma que no ofrece servicios nativos no ofrece mucho. Lo que sí puedes hacer es preferir plataformas donde la capa de lógica es código corriente, JavaScript o Python que puedes copiar a un repositorio, en lugar de comportamiento atrapado en un constructor visual que no exporta nada. La pregunta emparentada es la cobertura de la API: si la única forma de meter o sacar datos es por las pantallas del proveedor, todo flujo que llegues a necesitar tiene que existir ya como función, o esperas a una hoja de ruta.

## Superficie cuatro: condiciones comerciales que gravan la salida

Las tres primeras superficies son técnicas. La cuarta está escrita en el contrato, y suele ser la más afilada.

Las tarifas de salida que cobran la exportación por gigabyte convierten tu propio histórico en una nota de rescate. Los plazos de varios años con renovación automática y una ventana de cancelación de 90 días significan que la puerta de salida está abierta unas semanas al año. Los descuentos condicionados a la exclusividad elevan el coste de mantener una segunda plataforma en paralelo, que es como ocurren las migraciones cuidadosas. El precio por dispositivo que castiga el crecimiento también entra aquí.

Nada de esto está oculto. Está en el pedido y en el contrato marco, y el error es leer esos documentos como una compra y nunca como una salida. Pregunta cuál es el plazo de preaviso y si tu acceso a la exportación sobrevive al fin del contrato. Una función de exportación que pierdes el día en que caduca la suscripción no es portabilidad. Si revendes la plataforma, la misma disciplina aplica una capa más abajo, que es [lo que un SLA de reventa tiene que acertar](https://tago.io/blog/sla-reselling-iot-platform).

## Prueba la salida antes de firmar

Toda demo de plataforma te muestra el camino de entrada. Tu trabajo durante la evaluación es recorrer el de salida, mientras tu posición negociadora es la más fuerte y tu volumen de datos el más pequeño.

Abre una cuenta de prueba, carga unas semanas de datos reales de dispositivo y luego haz un ensayo de salida de verdad: exporta todas las lecturas por la API pública, saca el decodificador de un tipo de dispositivo y recrea una regla de alerta fuera de la plataforma. Cronometra cada paso y multiplica por el tamaño de tu flota en producción. Si el proveedor no puede sostener ese ejercicio a escala de prueba, ya tienes tu respuesta al precio más bajo posible.

Y aprovecha para pedir por escrito el precio de salida de datos y las condiciones de terminación, porque una cifra dicha en una llamada no es una cláusula.

## El intercambio honesto: código abierto que alojas tú

Si el lock-in es el enemigo, la opción con menos lock-in es software de código abierto que ejecutas tú. ThingsBoard es el conocido, y TagoCore es nuestro propio runtime de borde de código abierto. Tú tienes el código, la base de datos y el despliegue. Nadie cambia tus condiciones, retira tu plan ni retiene tus datos, porque todo está en infraestructura que controlas.

Esa libertad tiene un precio, y no es en dinero. Cuando alojas tú, eres dueño de la operación. Parcheas los servidores, escalas la base de datos cuando sube el número de dispositivos, resuelves la caída de las 3 de la mañana, cargas con la postura de seguridad. El lock-in que quitaste queda sustituido por una carga operativa que ahora es de tu equipo. Para algunas organizaciones con profundidad de ingeniería y ganas, ese es el intercambio correcto. Para la mayoría no, y fingir lo contrario no ayuda a nadie. Merece la pena hacer la [comparación completa de costes](https://tago.io/blog/open-source-vs-managed-iot-platforms) antes de decidir.

Así que la pregunta real no es "gestionado o código abierto". Es "qué tipos de lock-in acepto a cambio de que otro opere la plataforma". Toda plataforma gestionada arrastra algo de lock-in. El objetivo es minimizar los tipos caros, tus datos y tus dispositivos, y aceptar el resto como el coste de no operar infraestructura.

## Cómo es la portabilidad honesta

Ninguna plataforma puede prometer una salida gratis, y todo proveedor que asegure coste cero de cambio está vendiendo algo. Lo que una plataforma honesta puede hacer es mantener el coste proporcionado, y la forma de esa honestidad es reconocible:

- APIs de cobertura completa, es decir, todo lo que hace la interfaz está disponible por programación, así que una salida se puede guionizar en vez de hacer a clics.
- Protocolos estándar en los bordes, MQTT para el tráfico de dispositivos y LoRaWAN a través de network servers abiertos, así los dispositivos se reapuntan en vez de reflashearse.
- Decodificadores como código visible y exportable.
- Un compromiso escrito de que los datos son tuyos, con exportación sin cargo punitivo.

Esas son las posiciones sobre las que se construye TagoIO. TagoIO es una plataforma gestionada, lo que significa que no tiene lock-in cero, y preferimos decirlo claro antes que adornarlo. Lo que hacemos es empujar el lock-in hacia los tipos que menos duelen: la plataforma es totalmente accesible por API, los dispositivos se conectan por protocolos estándar incluidos MQTT y LoRaWAN, los payload parsers son JavaScript corriente que puedes leer y copiar, y la postura sobre propiedad de los datos está publicada en vez de negociarse acuerdo por acuerdo. La plataforma es multiinquilino y ejecuta TagoRUN para despliegues de marca blanca, tiene certificación ISO 27001 y alineación con el RGPD, y el mismo enfoque de protocolos abiertos se extiende al borde con TagoCore, que es de código abierto si quieres ejecutar esa parte tú.

Sigues en un servicio gestionado, y sigue habiendo un coste de cambio si te vas. Lo que no hay es un formato de datos cerrado ni un candado de firmware que convierta la salida en una reconstrucción. Preferimos que nos elijan de nuevo en cada renovación antes que retener a nadie.

## Siguientes pasos

Antes de comprometerte con cualquier plataforma IoT, pasa las cuatro superficies por ella: formato de exportación y límites de tasa, decodificadores y aprovisionamiento, dónde vive la lógica, condiciones de salida. Después comprueba las respuestas contra la propia plataforma.

- Mira cómo funcionan la conectividad de dispositivos y los datos en [TagoIO](https://tago.io)
- Lee los detalles de API e integración en la [documentación de TagoIO](https://docs.tago.io)
- Compara planes y costes por dispositivo en [los precios de TagoIO](https://tago.io/pricing)

El lock-in no es motivo para evitar plataformas. Construirlo todo tú solo mueve la dependencia a tu propio backlog. Es motivo para poner precio a la salida mientras preguntar sigue siendo barato. [Agenda una demo](https://tago.io/request-demo) o [empieza gratis](https://admin.tago.io) y haz el ensayo de salida con nosotros.

[llms.txt](https://tago.io/llms.txt)