Nobody chooses an IoT platform planning to leave it. You choose it to ship something, and the faster it lets you build, the deeper it settles into your stack: device decoders, dashboards, automation scripts, alert rules, user management. Each piece saves weeks. But each piece is also a strand of dependency, and the strands add up to a number nobody quotes you at signing: the cost of leaving.
That cost is vendor lock-in, and it stays invisible until a price increase, an acquisition, or a stalled roadmap forces you to ask what a migration would take. The answer lives on four specific surfaces, and all four can be tested before you sign anything.
Surface one: your data and how it gets out
Data is the obvious surface and still the most mishandled, because it splits into two questions people treat as one.
The first is ownership: does the contract state plainly that the data is yours and the vendor is a processor handling it on your behalf? The second is mechanics: can you export everything, in a documented format, through an API that does not throttle bulk reads into uselessness?
A vendor can grant you ownership on paper and still hold your history hostage in practice, because five years of time-series readings behind a rate-limited endpoint is a hostage situation with extra steps. 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 read. Ask whether the export covers raw device payloads or only the aggregated values the dashboard happens to show. Ask about row limits, time windows, and what it costs to pull years of data at once.
We covered the contract half in who owns your IoT data. The mechanical half is something you verify in a trial account, not in a sales call. This is the surface to fight hardest, because it is the only one that gets worse the longer you stay.
Surface two: device provisioning and payload decoding
Your devices speak binary. Somewhere, code turns those payloads into temperature readings and door states, and where that code lives decides how portable your fleet is.
If decoders are a black box inside the platform, every device type you onboard deepens the dependency, because migrating means rewriting decoding logic you cannot see, one device model at a time. Provisioning works the same way: if adding a device requires proprietary tooling with no API equivalent, re-registering thousands of units on a new platform becomes a manual project instead of a script.
The transport layer matters just as much. MQTT is the common open protocol 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, and reflashing a deployed fleet is not a migration, it is a recall.
Look for decoders you can read and copy out, written in a standard language, and provisioning that works end to end through a documented API.
Surface three: application logic tied to proprietary services
This is the surface engineers underestimate. Dashboards are rebuildable in a week; the logic behind them is the real investment.
Alert rules, scheduled jobs, data transformations, and third-party integrations accumulate over years, and if they were written against proprietary abstractions with no standard equivalent, they are the part of the migration you rewrite from scratch.
You cannot eliminate this surface, and you should not try, because a platform that offers no native services is not offering much. What you can do is prefer platforms where the logic layer is ordinary code, JavaScript or Python you can copy into a repository, rather than behavior trapped inside a visual builder that exports nothing. The related question is API coverage: 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 wait on a roadmap.
Surface four: commercial terms that tax the exit
The first three surfaces are technical. The fourth is written into the contract, and it is often the sharpest.
Egress fees that price data export by the gigabyte turn your own history into a ransom note. Multi-year terms with auto-renewal and a 90-day cancellation window mean the exit door is open a few weeks per year. Discounts contingent on exclusivity raise the cost of running a second platform in parallel, which is how careful migrations actually happen. Per-device pricing that punishes growth belongs here too.
None of this is hidden. It sits in the order form and the master agreement, and the mistake is reading those documents as a purchase and never as an exit. Ask what the notice period is, and whether your export access survives the end of the contract. An export feature you lose the day your subscription lapses is not portability. If you resell the platform, the same discipline applies one layer down, which is what a reseller SLA has to get right.
Test the exit before you sign
Every platform demo shows you the way in. Your job during evaluation is to walk the way out, while your negotiating position is strongest and your data volume is smallest.
Open a trial account, load a few weeks of real device data, then run a genuine exit drill: export every reading through the public API, pull the decoder for one device type, and recreate one alert rule outside the platform. Time each step, then multiply by the size of your production fleet. If the vendor cannot support this exercise at trial scale, you have your answer at the cheapest possible price.
While you are at it, request the egress pricing and termination terms in writing, because a number quoted on a call is not a contract term.
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. The full cost comparison is worth running before you decide.
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. The goal is to minimize the costly kinds, your data and your devices, and accept the rest as the cost of not running infrastructure.
What honest portability looks like
No platform can promise a free exit, and any vendor who claims zero switching cost is selling something. What an honest platform can do is keep the cost proportionate, and the shape of that honesty is recognizable:
- Full-coverage APIs, meaning everything the UI does is available programmatically, so an exit can be scripted rather than clicked through.
- Standard protocols at the edges, MQTT for device traffic and LoRaWAN through open network servers, so devices get repointed rather than reflashed.
- Decoders as visible, exportable code.
- A written commitment that the data is yours, with export at no punitive charge.
Those are the positions TagoIO builds on. TagoIO is a managed platform, which 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: the platform is fully API-accessible, devices connect over standard protocols including MQTT and LoRaWAN, payload parsers are plain JavaScript you can read and copy, and the data ownership stance is published rather than negotiated deal by deal. 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. We would rather be chosen again at every renewal than hold anyone in place.
Next steps
Before you commit to any IoT platform, run the four surfaces against it: export format and rate limits, decoders and provisioning, where the logic lives, 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
Lock-in is not a reason to avoid platforms. Building everything yourself just moves the dependency to your own backlog. It is a reason to price the exit while asking is still cheap. Book a demo or start free and run the exit drill on us.
