Transfer account from one Bosch IoT Cloud service instance to another

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