Definition
Device Migration refers to when a device is migrated into or out of an old platform, migrating Device Credentials, Thing Model, Device Shadow, Telemetry, etc. Supports bulk export/import, incremental migration, Dual-Write, and Pre/Post data verification.
Migration Strategies and Processes
Migration can be carried out through full export-import, incremental synchronization, or Dual-Write. Full migration is suitable for platform switching and requires exporting device credentials, vouchers, thing models, and historical data, and performing consistency verification after importing into the target platform. Incremental migration is suitable for continuous synchronization and requires handling change detection and conflict resolution. Dual-Write writes to both old and new platforms during migration, facilitating gradual rollout and rollback. Pre-validation (source data integrity) is required before migration, and post-validation (target data consistency) is required after migration to ensure key data such as Device Credentials credentials and Device Lifecycle status are correct.
Integration with DMP
The Device Management Platform provides migration tools, export templates, and import APIs. During migration, it is necessary to handle product and thing model mapping, credential format conversion, and device ID mapping. On the device side, it is necessary to update access addresses, credentials, and other configurations, which can be done via OTA configuration delivery or Provisioning re-networking. Large-scale migration should be executed in batches, with progress monitoring and support for resuming from breakpoints, avoiding impact on business continuity.
Use Cases
It is applicable to platform migration, multi-instance merging, cross-region deployment, data backup and recovery, etc. Device migration is an important part of platform selection and architecture evolution, requiring careful planning and execution.
What one migration batch must move together
Device migration means moving, in a batch that can be checked, a terminal’s identity and operating context from the source environment to the target, so that when it later connects to the new environment it is still recognized as the same device. What has to be considered together is more than the record: the credentials, or the way to reissue them, the thing-model version, desired state in the shadow that has not yet been carried out, unfinished upgrade jobs, and historical telemetry that needs to be kept. Moving only the device name and the key, and not the thing model, makes properties the device reports get rejected in the new environment or written to the wrong field. Moving only history, and not credentials, leaves the device connected to the old entry. A batch needs a boundary: which devices it includes, data up to which point in time, and which data is explicitly not moved.
Migration fits when the source and the target have already compared their rules for device identity, and when there is a period that can be rolled back. A full export fits a cutover inside a downtime window. An increment fits warming up before the cutover. Dual-write fits an observation period, with both old and new receiving at the same time, but dual-write is not two independent edits. During the move, freeze operations that change identity, such as resetting a key, renaming a device, or disposal. Records related to the audit log should at least keep which environment this device moved out of, and when it first connected in the target environment. Check, before the move, whether the source is complete. Check, after the move, the target counts, sampled hashes, and whether a few real devices can authenticate.
When identifiers on the two sides disagree during dual-write
A common mistake is the source environment using the device name as the primary key and the target using the serial number. At merge time the two identity schemes do not match. The same physical object becomes two devices, or two different devices are squeezed into one. Another mistake is desired state in the shadow being moved, and then the old environment delivering a new desired state. Dual-write has no conflict rule, and the device does not know which side to obey after it comes online. If historical telemetry is stored by each side’s own clock, the same moment has two sets of readings. An incremental sync that misses deletes leaves, in the target, devices the source has already disposed of.
At cutover, changing only the server address in the device and not the environment the credentials belong to makes authentication fail. Changing only the cloud access address, while the device still points at the old address, leaves the old environment still receiving data and the new environment empty. Rollback has to keep the old credentials and the old address in advance, not invalidate them as soon as the cut is done. If device grouping and permissions do not move with the batch, the device arrives in the new environment in the wrong project, or invisible to everyone. A migration tool showing “the same number of imported rows” only says the row count. It does not say those rows can still connect and can still explain properties. The completion condition should be a real session and a property comparison on sampled devices.
Equal row counts do not mean the migration is finished
An import tool reporting the same number of rows on both sides only says the table has the same number of rows. It does not say those rows can still authenticate, can still explain properties, or still belong to the original project. The completion condition should be that sampled devices open a session with the material after migration, that key properties match the source environment, and that unfinished desired configuration was not lost and was not covered by a new write from the old environment. Identity rules have to be compared before the move. When one side uses the device name and the other uses the serial number, there must be an explicit mapping. They must not be merged by a fuzzy name. A fuzzy merge stacks two devices into one, or splits one into two, and historical telemetry hangs on the wrong object.
During dual-write, state which side’s desired state wins. Otherwise the device comes online and changes back and forth between two targets. At cutover, the address and the environment the credentials belong to have to change together. Changing only the address makes the old credentials invalid in the new environment. Changing only the cloud, and not the device, leaves data still entering the old environment. Rollback needs both the old address and the old credentials still usable. Invalidating them the moment the cut is done leaves no way back. If a delete is not carried by the incremental sync, the target keeps a device the source has already disposed of. If groups and permissions do not move with the batch, the device may be invisible to everyone in the new environment, or fall into the wrong project. None of that shows up in the row count.