Transfer account from one Bosch IoT Cloud service instance to another

Introduction

Bosch IoT Rollouts supports the migration of data from a cloud foundry (CF) service instance to another. This can be useful for several scenarios:

  • Migrate your Rollouts service from one CF space to another
  • Migrate your Rollouts service from one CF ORG to another
  • Migrate your Rollouts service from CF installation to another (i.e. BIC v1 to BIC v2)

Please be aware that a service migration invalidates the source service instance, i.e. credentials from existing bindings become invalid and it is no longer possible to bind additional apps to the service.

This document will guide you through the steps based on an example of a Bosch IoT Rollouts service with Cloud User authentication and Standard plan. However, the function is independent of the selected plan or authentication mechanism.

Applicable to Rollouts customers of

  • Rollouts EU2 - Bosch IoT Cloud catalog

Prerequisites

  • A booked Bosch IoT Rollouts service instance on Bosch IoT Cloud.
  • CF Developer permission in origin and target space.
  • You have the Cloud Foundry CLI installed.

Steps

Generate a transfer key for the service instance you want to migrate

The transfer API is based on the CF service key function in order to generate a transfer key. You need to provide a secret as part of the call that is only known to you and will be later used to “claim” you data on the new service.

Note: the transfer key is only valid for 24hrs after generation. However, it is always possible to generate a new key.

cf create-service-key MY-ROLLOUTS-SERVICE MY-TRANSFER-KEY -c '{"type":"transfer", "secret":"MY_SECRET"}'

Example:

cf create-service-key migration-example migration-key -c '{"type":"transfer", "secret":"PleaseDoNotShareThis1234!"}'

Retrieve and note transfer key

Next step is to retrieve the identifier of your transfer key.

cf service-key MY-ROLLOUTS-SERVICE MY-TRANSFER-KEY

Based on the example above:

cf service-key migration-example migration-key

The expected result is something similar to:

Getting key migration-key for service instance migration-example as ...

{
 "transfer-key": "66383830363232372d656636662d343638312d616137612d6637626430316135646335323a42494331"
}

Book your new service instance with transfer key in order to migrate your data

The service booking is similar to regular booking with the addition of providing the transfer key and the secret.

Important: As soon as you trigger the migration your old service instance including all of its bindings and their provided credentials will no longer work! Note as well that the transfer key works only once for the defined source service.

cf create-service rollouts "SERVICE_PLAN" INSTANCE_NAME -c '{"transfer-key": "GENERATED_KEY", "secret":"MY_SECRET"}'

Based on the example above:

cf create-service rollouts "Standard" migrated-service -c '{"transfer-key": "38376363373862622d313033612d343835372d616266632d3630666536376438353461323a42494331", "secret":"PleaseDoNotShareThis1234!"}'

Check your work: verify your migrated service

There are of course multiple ways to do that (e.g. bind your apps) to the new service instance but for this tutorial we will do the check directly by adding a service key to get updated credentials from the new service and log into Management UI to see if everything is where we left it.

cf create-service-key migrated-service example-credentials-migrated

cf create-service-key MY-MIGRATED-ROLLOUTS-SERVICE MY-CREDENTIALS-KEY

Based on the example above:

cf create-service-key migrated-service example-credentials-migrated

Which will result in:

cf service-key migrated-service example-credentials-migrated
Getting key example-credentials-migrated for service instance migrated-service as ...

{
 .
 .
 .
 "password": "f6123c44-3789-44c8-9c1b-04c0e615a2dd",
 "tenant": "1C520920-C5DD-4A27-8B26-6FA2E32381AD",
 "username": "e720d962-2610-4aae-9311-0a260b38a916"
}

You might note that tenant has stayed the same to your origin while username and password have changed. Now open Management UI to check if that works.

Have fun with your service in the new environment!

Clean up task: delete the old service instance out of CF

Delete you old service instance in cloud foundry. As always, with CF you have to unbind your apps first but it can be assumed that these are bound to the new service already. So the only thing left before you can delete the old service is to delete the transfer (service) key itself.

cf delete-service-key MY-ROLLOUTS-SERVICE MY-TRANSFER-KEY
cf delete-service MY-ROLLOUTS-SERVICE

Based on the example above:

$ cf delete-service-key migration-example migration-key 

Really delete the service key migration-key?> y
Deleting key migration-key for service instance migration-example as ...
OK

$ cf delete-service migration-example

Really delete the service migration-example?> y
Deleting service migration-example in org XXX / space YYY as ...
OK