Moving a web application between clouds is hard. Moving a fleet of devices that you cannot easily touch is harder, because the thing you are migrating is sitting in a basement, a vehicle or a field with firmware that has a hard-coded idea of where home is. The teams that do this well treat it as a firmware project first and a cloud project second.

Start With the Question of Reach

Before comparing platforms, answer one question: can you update every device remotely, and how confident are you that the update will land? Everything else in the plan depends on it.

If your devices can receive a firmware or configuration update that changes their cloud endpoint, you can migrate gradually. If a portion of the fleet cannot be updated, because it is offline, on an old image or physically unreachable, you will be running two platforms for a long time, and that cost belongs in the business case.

In practice, you should audit the fleet by firmware version and last-seen date before anything else. The long tail of devices that have not reported recently is where migrations quietly fail.

Separate the Four Things That Move

A migration is really four migrations bundled together:

1. Connectivity. Endpoint addresses, ports and protocols the device connects to.
2. Identity. Certificates or credentials that prove which device is which.
3. State. Device metadata, groups, configuration and any stored twin or shadow data.
4. History. Historical telemetry that dashboards and models rely on.

Each has a different difficulty. Connectivity is a configuration change. Identity is the one that bites, because credentials issued by the old platform’s certificate authority will often not be trusted by the new one. History is optional for devices but not for analysts, so decide early whether it is copied, left in an archive, or abandoned.

Design the Device Side for Two Homes

The most useful thing you can do is ship a firmware update that knows about both platforms before you move anyone. The device learns a second endpoint and credential set, keeps its current connection, and switches only when told to.

The switch instruction should be reversible. A device that moves to the new platform and cannot connect should fall back to the old one after a defined number of failures. Without that, a bad endpoint value turns a fleet into a pile of unreachable hardware.

A common trap is changing the endpoint and the firmware logic in the same release. If something breaks, you cannot tell which change caused it. Ship the dual-home capability first, confirm it is live on the fleet, then trigger the move.

Migrate in Rings

Move devices in stages, and make each stage larger only after the previous one is quiet. A sensible sequence:

• Internal test devices on your own bench and in your office.
• A small canary group in a low-risk location, ideally with easy physical access.
• A representative slice across hardware revisions, regions and network types.
• The bulk of the fleet, in batches sized to what your support team can handle.
• The stragglers, handled individually.

After each ring, check that devices report to the new platform at their normal cadence, that commands reach them, and that alerts and dashboards still work. Do not judge success by connection counts alone. A device that connects and then fails to send data looks healthy on a presence screen.

Keep the Data Path Honest

Ingestion rules, routing and transformations built on the old platform need to be recreated, and this is where subtle differences appear. Timestamp handling, payload size limits, topic structure and retry behavior can differ between providers, so check each platform’s current documentation instead of assuming equivalence.

Run old and new pipelines side by side for a period, sending the same devices’ data to both where possible, and compare outputs. Differences in the first week are cheap to fix. Differences found a quarter later, when someone notices a report is off, are not.

A Staged Plan at a Glance

Phase	Goal	Exit check
Audit	Know firmware versions and last-seen dates	List of unreachable devices agreed
Dual-home firmware	Devices can hold two endpoints	Update confirmed on target group
Canary move	Prove the full path with few devices	Data, commands and alerts verified
Ring rollout	Move the fleet in batches	Each batch quiet before the next
Decommission old side	Stop paying for the old platform	No active devices, data archived

A Hypothetical Example

Picture a small operator with a few thousand pump controllers. Roughly most check in daily, but a stubborn minority only appear when a technician visits. The team ships dual-home firmware to the reachable devices, moves a canary group, and then discovers that the new platform’s certificate chain was never added to the devices’ trust store on one hardware revision. Because they had a fallback to the old platform, those canaries simply reconnected to the old side and reported an error. The fix was a second small update. Without the fallback, that revision would have gone dark.

Mistakes That Hurt

Cutting off the old platform on a calendar date rather than on measured readiness is the classic one. Contracts push people toward deadlines, so negotiate overlap time up front.

Another is forgetting everything that quietly depends on the old platform: a billing export, a customer-facing status page, a support script. List the consumers of your data before you start.

Finally, teams often forget to plan for devices that arrive later. New stock coming off the line should be provisioned for the new platform as early as possible so the migration target stops growing.

Frequently Asked Questions

How long does a fleet migration take? It depends mainly on how quickly you can reach devices and how cautious your rings are. Plan around the slowest-to-update portion of the fleet, not the average.

Do I have to migrate historical data? No. Many teams leave older history in an archive and start fresh on the new platform. Migrate it only if analysts or models genuinely need continuity.

Can devices keep their existing certificates? Only if the new platform trusts the issuing authority. Some platforms let you bring your own certificate authority, which simplifies this a great deal. Check current documentation.

What if some devices never come back online? Plan for them. Decide whether they stay on the old platform until retirement, get a technician visit, or are written off.

Should I migrate everything at once to save on overlap costs? That saves money only if nothing goes wrong. A staged approach usually costs less than a failed big-bang move.

Next Step

Export a list of all devices with firmware version and last-seen date, and sort it. Count how many you could not update remotely today. That number tells you whether your migration is a quarter-long project or a year-long one.