The IoT platform market is mature enough to have dozens of options and immature enough that many of them aren’t really platforms at all. Choosing the wrong one doesn’t usually blow up at deployment. It surfaces later, when margins shrink, projects stall, and switching costs are already too high.
After years of watching system integrators, OEMs, and enterprise teams navigate this choice (and sometimes deeply regret it), I’ve distilled a 20-point selection checklist. But before you go through all twenty, here are five traps that keep destroying projects and business relationships. These are not edge cases. They are patterns.
Trap 1: You’re Evaluating a Dashboard Builder, Not a Platform
A vendor shows you a slick demo. Nice charts, clean UI, data flowing from an MQTT broker into a time-series database, some alerts on top. Looks like an IoT platform, right? It’s not. A dashboard builder with an MQTT broker bolted on is not an IoT platform. A device management tool with a web interface isn’t one either. And a single-vertical solution repackaged as something “generic” is probably the worst offender: it looks convincing until you try to do something outside that one vertical.
Before you evaluate anything else, make sure the platform covers the absolute minimum: multi-protocol connectivity (not only MQTT/HTTP), bi-directional device control, structured hierarchical data modeling, event-driven processing with correlations and root cause analysis, native visualization, API-based integrations, and a security model that goes beyond TLS and passwords.
If even one of these is missing, it’s not an enterprise IoT platform. It’s a component that will require five more components around it, each with its own integration cost, maintenance burden, and point of failure. Walk away early.
Trap 2: “MQTT and REST” Is Not a Connectivity Strategy
This one is deceptively simple. MQTT and REST work beautifully for modern sensors and clean APIs. The first project flows, everyone is happy. Then comes the second project with industrial PLCs, Modbus, OPC UA, and even legacy serial protocols. The platform can’t connect to half the devices, and the team is stuck.
Even if you’re building just one solution today, think about tomorrow. Your next customer or vertical will almost certainly bring devices that don’t speak MQTT. And if every unsupported device requires an expensive gateway or the vendor’s professional services to integrate, your margins will erode with every new project.
What you actually need is broad industrial protocol support covering both IT and OT, an SDK or driver framework you can use yourself, and the ability to build custom protocol adaptors without calling the vendor every time. Gateway and edge connectivity should be part of the deal, not a separate product with a separate price tag. If the platform locks you into “MQTT/REST only”, you’re selecting a constraint, not a platform.
Trap 3: Weak Data Modeling: the Silent Margin Killer
Data modeling is invisible during demos and tends to surface only when real money is already on the table.
Most platforms offer some form of “device twins” or “digital twins”, essentially a flat structure where each device has properties and maybe some metadata. That works for monitoring dashboards. It does not work for real IoT solutions where you need hierarchy: Enterprise → Factory → Workshop → Production Line → Unit, or Building → Floor → Zone → Room → Sensor. These aren’t cosmetic layers. They define how data flows, how access control works, how alerts propagate, and how operators actually interact with the system.
Ask explicitly: does the platform support a formal, platform-wide data model? Can you visually design custom business object hierarchies, not just flat device lists? Can you define parameters, operations, event types, and dynamic object-to-object bindings? Is this reusable across projects?
Here’s a practical test I always recommend: take the platform’s demo and try to build your actual asset hierarchy. Not the vendor’s example. Yours. If it takes more than a day and still feels awkward, you have your answer.
When data modeling is weak, every project turns into custom development. You hardcode what should be configurable, duplicate what should be inherited, and every new customer multiplies the problem instead of reusing the solution. This is how SIs end up losing money on projects that looked profitable at the proposal stage.
Trap 4: Cloud-Only Deployment is a Time Bomb
Cloud-native is great. Cloud-only is a serious strategic risk, especially in industrial IoT, telco, and government sectors. A significant share of enterprise customers either can’t or won’t put their operational data into a public cloud. Utility companies have data residency requirements. Manufacturers want everything behind their firewall. Telcos need to run the platform in their own data centers. This isn’t a niche concern; it’s the reality for most industrial deployments.
If the platform only runs in the vendor’s cloud or supports just one public cloud provider, you’ve put a ceiling on your customer base. And the vendor’s promise of “we’ll add on-prem support later” should not give you any comfort. Cloud-to-on-prem portability is an architectural decision that either exists from day one or costs a fortune to retrofit.
The checklist is rather obvious: on-premise deployment, private cloud, multiple public clouds (not just AWS or Azure), hybrid architectures, cloud-provider agnostic operation, and edge deployment. Mandatory for any serious industrial, telco, or MSP-oriented business.
Trap 5: The Edge-Cloud Frankenstein
This trap is particularly nasty because it hides behind good-looking slides. An “edge solution” and a “cloud platform” that work together seamlessly. On paper. In reality, these are often two separate codebases — sometimes from two separate acquisitions — duct-taped together via APIs.
The practical consequence is painful: what’s built for the cloud gets rebuilt for the edge. The team maintains two platforms instead of one, needs two sets of skills, and runs two deployment pipelines. Code portability between edge and cloud remains a slide-deck fantasy rather than an engineering reality.
What you need is fundamentally simple (and surprisingly rare): same codebase across edge and central platform, same development tools, no “rewrite for edge” requirement. When a model, a dashboard, or an alert rule designed in the cloud can be deployed to an edge node without modification — that’s real edge-cloud compatibility. Everything else will cost you months per project.
Ask the vendor directly: “Is your edge product the same software as your cloud product?” If the answer involves phrases like “lightweight version” or “seamless integration between our two products”, you know what you’re dealing with.
These Five Are Just the Start
Platform selection has more dimensions than connectivity and deployment. Think vendor maturity, AI readiness (yes, it’s 2026 and MCP servers and development agents are part of the conversation now), security architecture, pricing transparency, and the uncomfortable question of what happens if the vendor disappears.
The key takeaway: platform choice defines your profitability, scalability, and reputation for years to come. Weak platforms have a way of silently destroying margins before anyone notices.
I’ve put together a comprehensive IoT Platform Selection Checklist covering the full picture. It’s designed as a practical yes/no/maybe tool: if too many boxes stay unchecked, walk away.
→ Read the full IoT Platform Selection Checklist (2026 Edition)
The post IoT Platform Selection: Five Traps to Avoid appeared first on IoT Business News.
