Every IoT project starts with a platform decision that feels reversible. You pick a vendor, connect a few devices, build a dashboard, and ship. Two years later you have ten thousand devices reporting in, a custom firmware build tied to one cloud, and three years of historical data you cannot get out in any usable shape. The decision was never reversible. It just looked that way at the start, and that gap between how it felt and how it really was is exactly where vendor lock-in lives.
Lock-in is not a single trap. It is four separate ones, and most buyers only check for one of them before signing. This post breaks down each kind, gives you the concrete question to ask a vendor to test for it, and is honest about the fact that the only way to reach near-zero lock-in is to take on work you may not want.
Data lock-in is the expensive one
Your historical data is the asset that grows every day and the hardest thing to move. If a platform stores your telemetry in a proprietary format and only lets you read it back through its own dashboard, you do not own that data in any practical sense. You can see it. You cannot leave with it.
The test question: “Can I export all of my raw historical data, and in what format?” Push past the marketing answer. A vague “yes, you can export your data” is not the same as a documented bulk export to CSV, JSON, or a direct database read. Ask whether the export covers raw device payloads or only the aggregated values the dashboard happens to show. Ask if there is a row limit or a time window. Ask what it costs to pull years of data at once, because for large datasets the transfer and the engineering time to reshape it can become the real bill.
Data lock-in is the one to fight hardest, because it is the only kind that gets worse the longer you stay.
Device and protocol lock-in decides whether your hardware travels
If a platform requires its own firmware, its own SDK, or a closed transport protocol to get a device online, your hardware is married to that platform. Move the cloud and you reflash every unit in the field, which on a deployed fleet is not a migration, it is a recall.
The test question: “Does my device connect over open standards, or do I need your firmware?” Open protocols are what keep devices portable. MQTT is the common one for telemetry: it is published, widely implemented, and your device speaks it the same way to any broker. For long-range sensor networks, LoRaWAN plays the same role, with the network and application server layers defined by an open spec rather than one company. A device that talks plain MQTT or sits on a standard LoRaWAN network can be pointed at a new endpoint with a config change instead of a field visit. A device that only speaks a vendor’s proprietary protocol cannot.
Integration lock-in is about whether you can build around the platform
A platform you cannot script is a platform you cannot grow past. If the only way to get data in or out is through the vendor’s own screens, every workflow you ever need has to already exist as a feature, or you are stuck waiting for a roadmap.
The test question: “Is there a documented REST API that covers everything the dashboard does, or only part of it?” The honest version of this question matters. Many platforms have an API that reads data but cannot provision a device, or one that handles devices but not user management. You want full coverage: create devices, push and pull data, manage users, configure the things you would otherwise click. If the API is a subset of the product, the rest of the product is a wall.
Contractual lock-in is the one written in plain language
The last kind is not technical at all. It is the term length, the auto-renewal clause, the per-device pricing that punishes growth, and the support tier you have to buy to keep the lights on. None of this is hidden. It is in the contract, which is why it is the easiest to check and the most often skipped.
The test question: “What is the notice period to leave, and does my export access survive the end of the contract?” An export feature you lose the day your subscription lapses is not portability. Read the offboarding terms before the onboarding ones.
The honest trade-off: open source you self-host
If lock-in is the enemy, the lowest-lock-in option is open-source software you run yourself. ThingsBoard is the well-known one, and TagoCore is our own open-source edge runtime. You hold the code, the database, and the deployment. Nobody can change your terms, deprecate your plan, or hold your data, because all of it sits on infrastructure you control.
That freedom has a price, and it is not in dollars. When you self-host, you own the operations. You patch the servers, you scale the database when device count climbs, you handle the 3 a.m. outage, you carry the security posture. The lock-in you removed gets replaced by an operational burden that now belongs to your team. For some organizations with the engineering depth and the appetite, that is the right trade. For most, it is not, and pretending otherwise does nobody any favors.
So the real question is not “managed or open source.” It is “which kinds of lock-in am I willing to accept in exchange for someone else running the platform.” Every managed platform carries some lock-in. That is the nature of a managed service. The goal is to minimize the costly kinds, your data and your devices, and accept the rest as the cost of not running infrastructure.
Where TagoIO fits
TagoIO is a managed platform. That means it is not zero lock-in, and we would rather say that plainly than dress it up. What we do is push the lock-in down to the kinds that hurt least.
On data, TagoIO supports exporting your data, so your history does not live in a one-way box. On devices, it speaks MQTT and works with standard LoRaWAN device data, so your hardware is not bound to a proprietary firmware build to talk to us. On integration, there is a full REST API that covers what the platform does, so you can build, provision, and automate around it instead of waiting on a feature request. The platform is multi-tenant and runs TagoRUN for white-label deployments, it is ISO 27001 certified and GDPR-aligned, and the same open-protocol approach extends to the edge through TagoCore, which is open source if you want to run that part yourself.
You are still on a managed service, and there is still a switching cost if you leave. What there is not is a closed data format or a firmware lock that turns leaving into a rebuild.
Next steps
Before you commit to any IoT platform, run the four test questions against it: export format, open protocols, full API, offboarding terms. Then check the answers against the platform itself.
- See how device connectivity and data work on TagoIO
- Read the API and integration details in the TagoIO documentation
- Compare plans and per-device costs on TagoIO pricing
A platform that gives clear answers to all four questions is one you can leave. That is exactly why you should feel safe staying.
