Picking an IoT cloud platform is one of the few early decisions that is genuinely expensive to reverse. Devices in the field carry credentials, endpoints and protocol assumptions, and changing any of them later means touching hardware you may not be able to reach. This guide walks through how to evaluate platforms in a way that survives contact with a real deployment.

Start With the Fleet, Not the Feature List

Vendor comparison pages tend to list dozens of capabilities. Most of them will not matter to you. Before opening any of those pages, write down what your fleet actually looks like:

• What kinds of devices connect, and how constrained are they (memory, battery, radio)?
• Do devices talk directly to the cloud, or through gateways?
• Is traffic mostly device-to-cloud telemetry, or do you also need commands going the other way?
• How long do devices stay in the field, and who can physically reach them?

The answers narrow the field quickly. A fleet of battery-powered sensors that wake briefly has very different needs from mains-powered gateways running containers.

The Capabilities That Usually Decide It

Most platforms, whether from a hyperscaler or a specialist vendor, cover the same broad building blocks. The differences show up in how well each one fits your constraints.

Connectivity and protocols. Check which protocols are supported natively. MQTT is common, but support for HTTP, CoAP or vendor-specific protocols varies. Confirm how the platform handles intermittent connections, session persistence and message ordering.

Identity and provisioning. Every device needs a unique identity. Look at how credentials are issued, rotated and revoked, and whether the platform supports certificate-based authentication suited to your manufacturing process.

Device state and commands. Many platforms offer a “shadow” or “twin” concept that stores the last known and desired state of a device. This is very useful when devices are offline often, but the semantics differ between products.

Data routing. Telemetry rarely stays in one place. Check how easily the platform routes messages to storage, stream processors and downstream applications, and what happens to messages when a destination is down.

Operations. Fleet grouping, firmware update orchestration, logging and alerting are the day-two features that decide whether your team can run the system without heroics.

Managed Services Versus Building on Primitives

There are broadly three approaches, and each trades control against effort.

Approach	Strengths	Trade-offs
Hyperscaler IoT service	Tight integration with the vendor’s storage, analytics and identity tools	Deeper dependency on one cloud’s conventions
Specialist IoT platform	Often faster to a working dashboard and device onboarding	Less flexibility outside its intended workflows
Self-assembled (broker plus services)	Maximum control and portability	Your team owns scaling, patching and availability

None of these is universally best. A small team shipping a first product often benefits from managed services, while a team with strong platform engineering and strict portability needs may prefer to run an open broker such as an MQTT implementation on infrastructure they control.

Test Lock-In Before It Becomes Real

Lock-in is not only about the cloud API. It lives in several places:

• Device firmware that embeds a vendor SDK or endpoint format.
• Message formats that assume one platform’s topic structure.
• Rules and automation written in a proprietary language.
• Identity tied to a vendor’s certificate authority.

A useful design habit is to put a thin abstraction between your firmware and the platform. Keep topic naming, payload schemas and credential handling in your own layer, so that changing platforms means changing an adapter rather than rewriting every device.

Run a Proof of Concept That Hurts a Little

A demo with five devices on a desk proves almost nothing. A better proof of concept deliberately stresses the parts that fail in production:

1. Provision devices the way manufacturing will, not by hand.
2. Disconnect devices for a long period and reconnect them together.
3. Rotate a credential and confirm devices recover.
4. Push a configuration or firmware change to a group and observe failures.
5. Break a downstream destination and see where messages go.
6. Export your data and device registry to confirm you can leave.

Record what required manual work. Those manual steps are your future operating cost.

A Hypothetical Example

Imagine a team building a fleet of environmental monitors for commercial buildings. The devices report a few readings at regular intervals and need occasional configuration changes. The team shortlists a hyperscaler service and a specialist platform. During the proof of concept, they simulate a few thousand devices reconnecting after a network outage and find that one option makes it simple to throttle reconnections while the other needs custom logic. They also discover that exporting the device registry from the specialist platform is awkward. Neither finding appears on a feature list, yet both shape the final choice.

Questions for Vendors and Your Own Team

Ask vendors how pricing is structured in general terms (per message, per device, per connection minute) and then model your own traffic against it, using their current published terms rather than rough recollection. Ask how outages are communicated and how data residency is handled. Ask your own team who will be on call and whether they are comfortable with the platform’s operational model.

Frequently Asked Questions

Should I always pick the platform from my existing cloud provider? It is a sensible default because identity, networking and storage are already familiar, but it is not mandatory. Compare it on device-facing needs such as provisioning and update orchestration, not just on convenience.

Is MQTT required? Not strictly, but it is widely used and well suited to constrained devices and unreliable links. If your devices use another protocol, confirm native support rather than relying on translation layers.

How many devices do I need before platform choice matters? It matters from the first production unit, because credentials and endpoints are baked into devices. The cost of a wrong choice grows with every device shipped.

Can I migrate platforms later? Yes, but it is easier if devices can receive remote updates and if you kept an abstraction layer. Devices that cannot be updated remotely are the hardest to move.

Do I need a custom dashboard from the platform? Often not. Many teams route data to existing analytics or visualization tools. Evaluate built-in dashboards as a convenience rather than a deciding factor.

Next Step

Write a one-page description of your fleet and its failure scenarios, then use it to design a proof of concept that includes provisioning, long disconnections, credential rotation and a data export. Run the same test against your top two candidates and compare the manual effort each one demanded.