Migration guide for typical scenarios

更新时间:
复制 MD 格式

IoT Platform supports migrating applications from public instances to Enterprise instances. The following typical business scenarios illustrate the migration process and key considerations.

Scenario 1

Business scenario

  • Devices use unique-certificate-per-device authentication and a public instance domain name to connect to IoT Platform.

  • Devices use custom topics to report data, which is forwarded to your business servers through other cloud products by using the message forwarding feature.

  • The server calls the Pub API to send messages to devices.

Migration guide

  1. No changes are required on the device side.

  2. Use grayscale migration to verify devices in small batches.

  3. During grayscale migration, configurations for products, message forwarding to cloud products, and AMQP server-side subscriptions are automatically migrated. Enterprise instances do not support MNS server-side subscriptions. Use AMQP server-side subscriptions instead.

  4. Verify that the devices are online and can report data normally.

  5. Verify the Pub API calls and check that your services are running as expected.

    The Pub API supports Enterprise instance IDs. You can submit a ticket to request this feature and reduce server-side changes.

  6. Use grayscale batch migration or full migration to migrate existing devices.

Scenario 2

Business scenario

  • Devices use unique-certificate-per-device authentication and a public instance domain name to connect to IoT Platform.

  • Some devices connect to IoT Platform as sub-devices of a gateway device.

  • Devices use custom topics to report data, which is forwarded to your business servers through other cloud products by using the message forwarding feature.

  • The server calls the Pub API to send messages to devices.

Migration guide

  1. No changes are required on the device side. For devices that connect as sub-devices of a gateway device, ensure that the topology remains unchanged during the migration.

  2. Use grayscale migration to verify sub-devices in small batches.

  3. During grayscale migration, configurations for products, message forwarding to cloud products, and AMQP server-side subscriptions are automatically migrated. Enterprise instances do not support MNS server-side subscriptions. Use AMQP server-side subscriptions instead.

  4. Verify that the devices are online and can report data normally.

  5. Verify the Pub API calls and check that your services are running as expected.

    The Pub API supports Enterprise instance IDs. You can submit a ticket to request this feature and reduce server-side changes.

  6. Use grayscale migration to verify gateway devices by following Steps 2, 3, 4, and 5.

  7. Use grayscale batch migration or full migration to migrate existing devices.

Scenario 3

Business scenario

  • Devices use unique-certificate-per-product pre-authentication and a public instance domain name to connect to IoT Platform.

  • Devices use custom topics to report data, which is sent to your business servers through an AMQP server-side subscription.

  • The server calls the Pub API to send messages to devices.

Migration guide

  1. No changes are required on the device side.

  2. Use grayscale migration to verify device information.

  3. During grayscale migration, products are automatically migrated and a new AMQP server-side subscriber is generated. You must update and verify the server-side application.

  4. Verify that the devices are online and can report data normally.

  5. Verify the Pub API calls and the AMQP server-side subscription, and check that your services are running as expected.

    The Pub API supports Enterprise instance IDs. You can submit a ticket to request this feature and reduce server-side changes.

  6. After the grayscale verification is complete, if you have new devices, create them directly in the destination Enterprise instance and verify that your services are running as expected.

  7. Use grayscale batch migration or full migration to migrate existing devices.

Scenario 4

Business scenario

  • The product is defined by using the Thing Specification Language (TSL) model feature. Devices use unique-certificate-per-device authentication and a public instance domain name to connect to IoT Platform.

  • Devices use Alink topics to report data, which is forwarded to your business servers through other cloud products by using the message forwarding feature.

  • The server calls the InvokeThingService API to invoke services provided by devices.

Migration guide

  1. No changes are required on the device side.

  2. Use grayscale migration to verify devices in small batches.

  3. During grayscale migration, configurations for products, message forwarding to cloud products, and AMQP server-side subscriptions are automatically migrated. Enterprise instances do not support MNS server-side subscriptions. Use AMQP server-side subscriptions instead.

  4. Verify that the devices are online and can report data normally.

  5. Verify the InvokeThingService API calls and check that your services are running as expected.

    The InvokeThingService API supports Enterprise instance IDs. You can submit a ticket to request this feature and reduce server-side changes.

  6. To migrate historical data for TSL model properties, events, and services, enable data synchronization and wait for 7 to 30 days.

  7. After 7 to 30 days, use grayscale batch migration or full migration to migrate existing devices. After the migration, the devices in the Enterprise instance will have historical data from the last 7 to 30 days.