IoT Platform:Usage notes

Limits

Migration notes

Before you migrate the data of a public instance, take note of the following items. This helps you evaluate the possible impacts of the migration on your business.

• Data to be migrated

  When you migrate data of a public instance, IoT Platform automatically synchronizes the products, devices, and message forwarding data of the public instance. The following table describes the data to be migrated.

  Item	Data to be migrated	Usage notes
  Products	Product information: ProductKey, product name, node type, and category. Features: properties, services, events, Thing Specification Language (TSL) model extensions, and draft TSL models. Scripts: data parsing scripts and draft data parsing scripts.	You can migrate products and devices that support the unique-certificate-per-device verification and pre-registration unique-certificate-per-product verification methods. When you migrate sub-devices, the topological relationships between the sub-devices and the related gateway remain unchanged. After you migrate the sub-devices, the sub-devices can connect to IoT Platform as expected. If you want to migrate gateways or the attached sub-devices, you must migrate the gateways and the sub-devices to an Enterprise Edition instance at the same time. You cannot migrate authorized products and devices. The authorization feature is unavailable for products and devices of Enterprise Edition instances. You cannot migrate products and devices for which data services are activated. You cannot migrate products and devices for which LinkVisual is activated. You cannot migrate products and devices that are connected to Link IoT Edge and IoT Platform for Daily Life at the same time. After the migration, the product TSL verification type remains unchanged. After the migration, the system retains the original data on the public instance of the previous version. To prevent data loss due to accidental operations, we recommend that you delete the original data after the instance migration task is complete and the business runs as expected.
  Devices	Device information: device certificate information. Make sure that each device certificate is globally unique. Device data: the data of TSL properties, events, and services.	Important You cannot migrate the distributed devices of an instance. The reconnection feature must be enabled for devices that you want to migrate. You must configure the related Link SDK to connect the devices to IoT Platform and make sure that the devices can communicate with IoT Platform as expected. Note If you use Link SDK provided by IoT Platform to develop a device, the device is automatically connected to the Enterprise Edition instance. You do not need to modify the endpoint of the device. For more information about Link SDK, see Device connection by using Link SDK. If you do not use Link SDK provided by IoT Platform, you must modify the endpoint of the device and develop the reconnection logic of the device. If a device is connected to IoT Platform during the migration, the device is forcibly disconnected from IoT Platform. After the migration, the system removes the migrated devices from the public instance of the previous version. You do not need to modify the related Link SDK. The devices can be connected to the destination Enterprise Edition instance and communicate with the instance as expected. Only users in the whitelist can migrate devices that are verified by using IoT device IDs. You can submit a ticket to apply for the whitelist permission. For more information about IoT device IDs, see Use IoT device IDs to verify devices. When you migrate the TSL data of devices, take note of the following items: By default, the data synchronization feature is disabled. After you create a migration task, enable the data synchronization feature. This ensures that your business is not affected during the migration. After you enable the data synchronization feature, the system synchronizes the data that is submitted by the devices of the product to be migrated from the public instance to the destination Enterprise Edition within one minute. The data synchronization is effective for up to the next 30 days. You can enable or disable the data synchronization feature for devices. If you enable the data synchronization feature, the system automatically disables the feature 30 days after you enable the feature. Before you disable the data synchronization feature, make sure that the instance migration is complete. This prevents your business from being affected. The system performs one-way data synchronization. The data that is submitted by the devices of the product that you want to migrate is synchronized only from the public instance to the destination Enterprise Edition. If you roll back the devices from the Enterprise Edition instance to the public instance when the data synchronization feature is enabled, the device data is not rolled back. If you re-migrate the devices to the Enterprise Edition instance, make sure that the data of the Enterprise Edition is integral. The data of the public instance may not be integral.
  Message forwarding	Server-side subscription: the configuration of Advanced Message Queuing Protocol (AMQP) and Message Service (MNS) server-side subscriptions and subscription relationships. Data forwarding: data forwarding rules that include SQL statements, data sources, data destinations, and data parsing scripts. The data destinations can be ApsaraMQ for RocketMQ, Time Series Database, ApsaraDB RDS, and Function Compute. Consumer groups: consumer group information. After the migration, the system creates consumer groups and generates new IDs for the consumer groups.	After the migration, the system retains the original data on the public instance of the previous version. To prevent data loss due to accidental operations, we recommend that you delete the original data after the instance migration task is complete and the business runs as expected. If AMQP server-side subscriptions are configured or data is forwarded to an AMQP consumer group, you must start two AMQP clients. The AMQP clients can simultaneously receive data from the public instance and the Enterprise Edition instance. This helps prevent data loss. Clients cannot access Enterprise Edition instances by using HTTP/2 subscriptions. After the migration task is complete, we recommend that you change the HTTP/2 server-side subscription for the source public instance to the AMQP server-side subscription.

• Features:

  After devices are migrated to the Enterprise Edition instance, you can use the configuration of the device as expected. If you want to use more features, you can configure the feature on the Enterprise Edition instance. For more information about how to use the features, see Usage notes on features after a migration.

• Billing:

  After devices are migrated to the Enterprise Edition instance, you are no longer charged for the following items: messaging, connection duration, and over-the-air (OTA) updates.

Before you begin

After you read the preceding migration notes, you must evaluate business impacts and transform your business system before you migrate the instance. This helps ensure that the migrated devices can communicate with IoT Platform as expected.

Instance migration process

The instance migration process consists of four steps that are shown in the preceding figure.

Migration procedure

1. Step 1: Create a migration task: Create a migration task for a specific product.

   Important

   To ensure that your business is not affected during the instance migration, you can enable the data synchronization feature after you create the migration task. This way, the system synchronizes the data that is submitted by the devices of the product that you want to migrate from the public instance to the destination Enterprise Edition. For more information, see the Optional: Enable data synchronization section of the "Procedure" topic.

2. Step 2: Perform the phased migration: The system copies the product and the data of the message forwarding feature in sequence and migrates device data in phases.

   Warning

   If AMQP server-side subscriptions are configured or data is forwarded to an AMQP consumer group, you must copy the new consumer group ID and connect a new AMQP client to IoT Platform by using the SDK to receive data after the phased migration.

   Before you perform full migration, make sure that the migration task does not affect your business.

3. Step 3: Perform full migration: Query all data of the product and migrate the data of all devices.

   Warning

   Make sure that the system is transformed and released. For example, the ID of the Enterprise Edition instance must be specified as the value of a request parameter of an IoT Platform API operation that you want to call and the consumer group ID of the SDK that is used to connect the AMQP client is updated. For more information, see the Before you begin section of this topic.

   After the full migration is complete, check the status of the business and migration result. Make sure that the object for which the IoT Platform API operations that you want to call take effect is changed to the Enterprise Edition instance.

4. Optional: Roll back the migration task: If the migration task fails or an error occurs, you can roll back all device data, including the device certificate information and TSL data to the public instance. This way, the devices can run as expected. This step does not delete the migrated server-side subscription and the data of the message forwarding feature on the destination Enterprise Edition instance.

References

• Best practices for instance migration

• FAQ about IoT Platform instances

FAQ

Before migration

• What do I need to take note of when I migrate a public instance of the previous version to an Enterprise Edition instance?

• Does a public instance of the previous version that is migrated to an Enterprise Edition instance occupy the specification of the Enterprise Edition instance?

• Am I able to migrate an IoT Platform public instance of the previous version to an Enterprise Edition instance across accounts?

• Am I able to migrate an IoT Platform Enterprise Edition instance? How do I migrate an IoT Platform Enterprise Edition instance?

• Am I able to migrate the OTA update package when I migrate an IoT Platform public instance of the previous version to an Enterprise Edition instance?

• Am I able to migrate the authorized products and devices from a public instance of the previous version to an Enterprise Edition instance?

• Am I able to migrate a public instance of the previous version to an Enterprise Edition instance of any type?

• Am I able to migrate a public instance of the previous version to an Enterprise Edition instance across regions and accounts?

During migration

• What is phased migration during instance migration?

• Do I need to create products, devices, and message forwarding rules on the Enterprise Edition instance before I migrate the public instance of the previous version to the Enterprise Edition instance?

• Does the migration of the public instance of the previous version affect the connected devices?

After migration

• What do I do if the phased migration of a public instance of the previous version is complete, but no information about devices and the migration is displayed on the migration details page?

• Do I need to modify the endpoint of a device after the device is migrated from a public instance of the previous version to an Enterprise Edition instance?

• Do I need to specify the ID of the Enterprise Edition instance to call API operations on the server after a public instance of the previous version is migrated?