IoT Platform Migration: How to Move Without Data Loss

Devices reconnect in a day. History does not. Every IoT platform migration is decided by the data you already own: five years of telemetry, the alert rules someone tuned by hand on a Sunday, and the code that turns an 11-byte payload into a tank level reading. Repointing an MQTTProtocolMQTTThe standard pub/sub protocol of IoTView profile endpoint is the easy part, and it is usually the only part anyone plans for.

This guide walks through the full process as integrators and manufacturers actually face it when they change the platform underneath their product: what to inventory before touching anything, how to run the switch in five phases with no blackout window, how to prove afterwards that not a single record is missing, and what to demand from the destination platform so you never repeat the exercise two years from now.

Some context explains why the topic keeps landing on technical agendas. According to IoT Analytics, the global installed base exceeds 18 billion connected devices, and a growing share of those deployments is not new. They are five- and seven-year-old projects carrying platform decisions made when the fleet had 200 units and today has 20,000.

What an IoT Platform Migration Actually Puts at Risk

Live telemetry is the most visible asset and the least problematic one. A sensor publishing every 15 minutes starts publishing to a different address as soon as its configuration changes, and from that moment the new platform has fresh data. Everything else is where the work hides.

History. Five years of readings at 15-minute intervals across 4,000 devices is roughly 700 million points. That volume does not fit through a web interface export, and it rarely comes out in a format you can load directly. Without history, every function that compares against the past goes blind on day one: consumption baselines, adaptive thresholds, annual reports, and predictive maintenancePUse casePredictive maintenanceView profile models.

Device identities. In LoRaWANProtocolLoRaWANOpen long-range, low-power LPWANView profile these are the DevEUI, the JoinEUI, and the application keys; in MQTT, the client IDs with their credentials or certificates. Changing platforms means reprovisioning every unit, and in deployments with sensors inside manholes, on towers, or in cold rooms, "reprovisioning" can mean a site visit. A migration plan that ignores that cost slips by months.

Decoders. The code that translates binary payloads into engineering units is accumulated intellectual property, often written for one platform's specific runtime. It is the piece most commonly underestimated and the one most likely to force a rewrite.

Then there is everything that was configured once and never looked at again. A mature installation accumulates hundreds of alert rules with their thresholds, hysteresis, quiet windows, and distribution lists, and they are almost never documented outside the platform itself. Outbound integrations behave the same way: webhooks into the ERP, BI queries, GIS layers, automatic tickets in the maintenance system. Each one carries a credential and a data contract you have to reproduce at the destination, and the usual way to find out you missed one is a report that quietly stops updating.

Before you negotiate timelines with anyone, export 24 hours of data for a single device end to end. That rehearsal reveals in one afternoon whether the source platform rate-limits downloads, whether timestamps arrive in local time with no zone, or whether history has been rolled up and the raw sample no longer exists.

Five Assets to Inventory Before Anything Moves

The inventory is the deliverable that turns a migration into a scoped project. Without it, the team discovers requirements by breaking things.

The fifth line deserves extra attention if you are an integrator. In a multi-tenant platform, migration does not move a data hierarchy: it moves a business model. Every end client has its own scope, its own users, and sometimes its own branding. Rebuilding that by hand at the destination is where the unbudgeted time goes.

One legal point works in your favor. The European Union Data Act, applicable since September 2025, requires providers of data processing services to enable switching: maximum transition periods, export in a structured and commonly used format, and the progressive removal of egress charges. If your current provider operates in the EU, you can request portability in writing and point to that regulation.

Want a reference for how this plays out when the source service has already been discontinued? The migration paths for retired IoT services follow exactly this order of work.

IoT Platform Migration Step by Step: Five Phases

Never switch off the source to switch on the destination. The two platforms run side by side for weeks, and cut-over becomes an administrative decision you make once the data proves the destination works. Most migration horror stories start by skipping that overlap.

Phase 1. Audit and Test Export

Complete the inventory above and run a real export of a sample: one device, one month, every field. Measure how long it takes, what format comes out, and what request limits apply. Multiply by the full fleet and you have the duration of the load phase, which in large deployments is counted in days, not hours.

Two numbers come out of this rehearsal and both belong in the project plan. The first is the export throughput ceiling, usually set by an API rate limit rather than by bandwidth. The second is the egress cost, which some providers bill per gigabyte leaving their infrastructure. A fleet with years of high-frequency history can turn that line into a four-figure invoice, and it is far better discovered in week one than during cut-over week.

Phase 2. Data Model Mapping

This phase decides the quality of the result. Point by point: variable names, units, types, precision, null handling, and above all timestamps. Everything in UTC at the destination, with the time zone treated as a presentation attribute. Migrations that mix local time and UTC produce one-hour gaps twice a year, and those gaps surface months later inside a billing report.

If history at the source is rolled up hourly and the raw 15-minute sample no longer exists, that loss is irreversible: document it now and decide whether the destination keeps both resolutions. This is also the moment to revisit the device model, because a platform with native support for heterogeneous sensors and protocols lets you normalize families that were patched together at the source.

Phase 3. Dual Ingestion

Instead of moving devices, duplicate the stream. An MQTT bridge on the source broker, or an additional output on the gateway, forwards every message to the new platform as well. Devices stay untouched, the source keeps operating as the system of record, and the destination starts receiving real production data.

If the bridge is not an option because the source provider does not allow it, the alternative is reconfiguring devices in small batches, starting with a low-criticality family that is physically easy to reach. Understanding how an MQTT broker works and its publish/subscribe model matters before designing this split, since message duplication and data consumption during the overlap both depend on it.

Batch order is not arbitrary. Rank groups by three combined criteria: how critical the service they support is, how accessible the hardware is, and how complex the decoder is. The first batch should score low on all three, because its real job is to expose flaws in the procedure while they are still cheap. Critical, hard-to-reach units go last, once the procedure has run twenty times and its checklist is settled.

Phase 4. History Backfill

With dual ingestion running, history loads cold in batches, most recent first. That order matters: if the project stalls halfway, you end up with the last full year rather than the five-year-old data from a decade back. Every batch is verified on completion, and the loaded range per device is recorded.

Phase 5. Cut-Over and Rollback Window

Cut-over arrives once both systems have agreed for at least two weeks. Writes to the source stop, read access stays available for 30 to 90 days, and a concrete decommission date is communicated. Nobody deletes anything until a full billing cycle and one monthly close have run against the new system.

The rollback plan is written before cut-over, not during the incident. It should fit on one page and answer three questions: who decides to go back, what has to be executed for devices to publish to the source again, and what happens to the data that reached the destination in the meantime. While the previous configuration is still alive on the devices, rolling back costs minutes. Once it is wiped, it costs a field campaign.

Need to test this plan against your real fleet? Talk to the team and we will review volume, protocols, and overlap window before you move a single device.

Overlap: Why You Will Run Two Platforms at Once

The overlap phase makes whoever signs the invoices uncomfortable and whoever runs operations relaxed. It usually lasts two to eight weeks and has three effects worth anticipating.

Temporary double cost. Two subscriptions and, in cellular deployments, more data consumption if the device publishes twice. Budget it from the start rather than discovering it in the second month's invoice. Duplicating server-side through a bridge avoids that connectivity overhead entirely: the device transmits once and the infrastructure fans out. On duty-cycle-limited networks such as LoRaWAN in the 868 MHz band, duplicating on the device is usually impossible anyway: the legal transmission budget does not stretch to sending everything twice.

Duplicate alerts. With two platforms evaluating the same rules, every incident produces two notifications. The healthy practice is to mute notifications at the destination during the overlap and compare its would-be triggers against the source in an internal panel. If the new platform would have alerted on the same thresholds at the same time, the rule ported correctly.

Silent divergence. A badly ported decoder breaks nothing: it writes a plausible but wrong number. That is why comparison cannot be visual. It runs as aggregate queries across both stores, device by device and day by day.

Exit criteria for the overlap are defined before entering it. For example: seven consecutive days below 0.1% discrepancy in message counts, zero differences in daily aggregates for billing variables, and every critical alert reproduced.

How to Prove Nothing Is Missing

Verification is the part of the project that gets cut when time is short, and the only part that produces evidence. Four checks cover most real failures.

Counts per device per day. A table with device, date, and record count in each system. Sort differences from largest to smallest and work down the list. Gaps almost always cluster: one specific day, one sensor family, one gateway. Clustering is what makes the exercise tractable: a gap shared by every device behind one gateway points at the forwarding path, while a gap spread across one device family across all gateways points at the decoder or the provisioning batch. Isolated single-device gaps are usually genuine, matching an outage that also exists at the source, and the reconciliation report should say so explicitly rather than leave the reader guessing.

Daily aggregates. For each numeric variable: minimum, maximum, average, and sum per day. Matching on counts but not on aggregates points to a scaling or unit problem, which is exactly what a badly ported decoder produces.

Random sampling against raw values. Fifty records drawn at random across the whole period, compared field by field against the original payload. It is the only test that verifies the entire chain, from byte to reading.

Alert testing with a synthetic event. Inject an out-of-threshold reading at the destination and confirm the alert fires, reaches the right recipient, and respects the quiet window.

Results from all four go into a dated report. When someone asks two years from now why a 2024 consumption figure does not add up, that document is the difference between an answer and an afternoon of archaeology.

What to Demand From the Destination Platform

One migration is part of the job. Having to run a second one two years later because the destination was chosen badly is avoidable, and five questions asked before signing will do it.

1. How do I leave? Ask for the bulk export API documentation, its rate limits, and its cost. If the answer is a support ticket form, you already know what leaving will cost.
2. Are the decoders mine and portable? They should be code in a standard language, versioned in your own repository, not configuration trapped inside a user interface.
3. Does the multi-tenant model fit my business? If you resell to end clients, you need per-client isolation, your own branding, and delegated administration from day one, not as custom development.
4. What integrations ship natively? A platform with an open API and documented webhooks spares you the middleware layer you would otherwise maintain forever. Our system integration work almost always starts there.
5. Where does it run? Cloud or on-premise, and under what retention policy. Many migrations originate in a data sovereignty requirement that appeared after the original contract.

An example of what these questions are worth: an operator running its own network, with documented decoders and raw data retained, can change platforms in weeks. Another with the same sensor count, but with logic written inside the tool and no raw samples kept, faces a project of months or the permanent loss of history. What separates the two cases is a set of architecture decisions made years earlier, not the radio technology or the size of the fleet. In urban sensing deployments, where fleets are measured in thousands of points, that gap is especially visible, as any municipal LoRaWAN network at city scale shows.

Standard protocols work in your favor here. A fleet speaking MQTT as specified by OASIS or LoRaWAN conforming to the LoRa Alliance specification is portable by definition. Lock-in shows up higher in the stack: in the decoders and in the format your history is stored in.

Conclusion

In a well-run IoTITermIoT (Internet of Things)The IoT (Internet of Things) is the network of physical objects with sensors, software and connectivity that collect and exchange data and act autonomously.View profile platform migration, cut-over day is the least interesting part of the project. The work happens before it: the inventory, the weeks of overlap, and the verification report that shows the data arrived intact.

The points that make the difference:

• History and decoders are the assets at risk, not device connectivity.
• Dual ingestion over big bang: both platforms coexist for weeks and the source stays the reference until the data says otherwise.
• UTC timestamps and an explicit unit mapping prevent errors that surface months later.
• Four-layer verification: counts, aggregates, raw sampling, and alert testing, with a dated report.
• Choose the destination by its exit door, not only by its feature list.

The practical next step is the export rehearsal: one device, one month, every field. With that result in hand, the migration timeline stops being an estimate and becomes arithmetic. To pressure-test it with a team that has run the exercise across fleets of thousands of devices, book a demo and we will go through your numbers.