## 4.3.1.3.6 Migrating Service Instances and Service Bindings from a Custom SAP BTP Service Operator
Learn how to migrate service instances and service bindings from your custom SAP BTP service operator to a Kyma cluster.
## Prerequisites
- You have a new Kyma cluster deployed without any service instances in it.
- You have the SAP BTP Operator module added. For instructions on adding modules, see Adding and Deleting a Kyma Module [page 3157].
- For CLI interactions: kubectl configured to communicate with your Kyma instance. See Access a Kyma Instance Using kubectl [page 2018].
- For processing JSON data output from kubectl commands: jq .
## Context
If you have service instances and service bindings created outside the Kyma environment, and you want to continue using them in the Kyma environment, you must migrate them into your Kyma cluster.
## Preparing Migration Data from Your Custom SAP BTP Service Operator
## Procedure
1. To connect kubectl to the cluster with with your custom SAP BTP service operator, set either the KUBECONFIG environment variable or the cluster context with the kubectl config use-context command.
2. Find the sap-btp-service-operator Secret by running the kubectl get secrets -A command.
3. Save the Secret name and its namespace in the SAP\_BTP\_OPERATOR\_SECRET\_NAME and SAP\_BTP\_OPERATOR\_SECRET\_NAMESPACE environment variables.
4. Save the SAP BTP service operator credentials in the following environment variables:
CLIENT\_ID=$(kubectl get secret -n $SAP\_BTP\_OPERATOR\_SECRET\_NAMESPACE $SAP\_BTP\_OPERATOR\_SECRET\_NAME -o jsonpath={.data.clientid}) CLIENT\_SECRET=$(kubectl get secret -n $SAP\_BTP\_OPERATOR\_SECRET\_NAMESPACE $SAP\_BTP\_OPERATOR\_SECRET\_NAME -o jsonpath={.data.clientsecret}) SM\_URL=$(kubectl get secret -n $SAP\_BTP\_OPERATOR\_SECRET\_NAMESPACE $SAP\_BTP\_OPERATOR\_SECRET\_NAME -o jsonpath={.data.sm\_url}) TOKEN\_URL=$(kubectl get secret -n $SAP\_BTP\_OPERATOR\_SECRET\_NAMESPACE $SAP\_BTP\_OPERATOR\_SECRET\_NAME -o jsonpath={.data.tokenurl})
5. To find the sap-btp-operator-config ConfigMap in the cluster, run the kubectl get configmaps -A command.
6. Save the ConfigMap name and its namespace in the SAP\_BTP\_OPERATOR\_CONFIGMAP\_NAME and SAP\_BTP\_OPERATOR\_CONFIGMAP\_NAMESPACE environment variables.
7. Save the cluster ID in the environment variable:
CLUSTER\_ID=$(kubectl get configmap -n $SAP\_BTP\_OPERATOR\_CONFIGMAP\_NAMESPACE $SAP\_BTP\_OPERATOR\_CONFIGMAP\_NAME -o jsonpath={.data.CLUSTER\_ID} | base64)
8. List all service instances with the kubectl get serviceinstances -A command. Take note of the namespaces that must be present in the Kyma cluster.
When you migrate service instances into the Kyma cluster, you must use these noted namespaces to recreate the necessary structure within the new environment.
9. Save each service instance you want to migrate as a manifest in a JSON file. To do that, replace the placeholders with the actual service instance name and its namespace, and run:
10. List all service bindings with the kubectl get servicebindings -A command. Take note of namespaces that must be present in the Kyma cluster.
```
kubectl get serviceinstance -n <SERVICE_INSTANCE_NAMESPACE> <SERVICE_INSTANCE_NAME> -o json \ | jq 'del(.metadata.annotations, .metadata.creationTimestamp, .metadata.finalizers, .metadata.generation, .metadata.resourceVersion, .metadata.uid, .status)' \ > <SERVICE_INSTANCE_NAME>-si.json
```
When you migrate service bindings into the Kyma cluster, you must use these noted namespaces to recreate the necessary structure within the new environment.
11. Save each service binding you want to migrate as a manifest in a JSON file. To do that, replace the placeholders with the actual service binding name and its namespace, and run:
```
kubectl get servicebinding -n <SERVICE_BINDING_NAMESPACE> <SERVICE_BINDING_NAME> -o json \ | jq 'del(.metadata.annotations, .metadata.creationTimestamp, .metadata.finalizers, .metadata.generation, .metadata.ownerReferences, .metadata.resourceVersion, . metadata.uid, .status)' \ > <SERVICE_BINDING_NAME>-sb.json
```
## Migrating Resources to a Kyma Cluster
## Procedure
To migrate your resources to a Kyma cluster, you must first customize the sap-btp-manager Secret. See Customizing the Default Credentials and Access [page 1890]. To prevent automatic reversion of your custom changes, add the kyma-project.io/skip-reconciliation: 'true' label to the Secret. Then, perform the following steps:
1. To connect kubectl to your Kyma cluster, set either the KUBECONFIG environment variable or the cluster context with the kubectl config use-context command.
2. To find the sap-btp-manager Secret in the Kyma cluster, run the kubectl get secrets -A command.
3. Save the Secret name and its namespace in the BTP\_MANAGER\_SECRET\_NAME and BTP\_MANAGER\_SECRET\_NAMESPACE environment variables.
4. When preparing resources for migration, you noted the namespaces that must be present in the Kyma cluster. To avoid errors and maintain structures based on specific namespace assignments, recreate these namespaces required for the service instances and service bindings you are migrating.
5. To override the SAP BTP service operator credentials and cluster ID, patch the sap-btp-manager Secret:
6. To create service instances and service bindings from the saved manifests in JSON format, replace the placeholder with the actual service instance or service binding JSON manifest, and use the kubectl apply -f &lt;JSON\_MANIFEST&gt; command.
```
kubectl patch secret -n $ "{\"data\":{\"clientid\":\"${CLIENT_ID}\",\"clientsecret\":\"${CLIENT_SECRET}
```
```
{BTP_MANAGER_SECRET_NAMESPACE} ${BTP_MANAGER_SECRET_NAME} -p \",\"sm_url\":\"${SM_URL}\",\"tokenurl\":\"${TOKEN_URL}\",\"cluster_id\":\"$ {CLUSTER_ID}\"}}"
```
## Deleting Migrated Resources
## Procedure
To limit service instances and service bindings management to the SAP BTP service operator in the Kyma cluster, perform the following steps:
1. To avoid deleting the resources from your Kyma cluster, ensure that you connect kubectl to the cluster with your custom SAP BTP service operator. Set either the KUBECONFIG environment variable or the cluster context with the kubectl config use-context command.
2. To find the sap-btp-operator-controller-manager deployment in the cluster with your custom SAP BTP service operator, run the kubectl get deployments -A command.
3. Save the deployment name and its namespace in the SAP\_BTP\_OPERATOR\_DEPLOYMENT\_NAME and SAP\_BTP\_OPERATOR\_DEPLOYMENT\_NAMESPACE environment variables.
4. To scale the deployment to 0 replicas, run:
5. To delete the SAP BTP service operator webhooks, run:
```
kubectl scale deployment -n $SAP_BTP_OPERATOR_DEPLOYMENT_NAMESPACE $SAP_BTP_OPERATOR_DEPLOYMENT_NAME --replicas=0
```
kubectl delete mutatingwebhookconfigurations sap-btp-operator-mutatingwebhook-configuration &amp;&amp; kubectl delete validatingwebhookconfigurations sapbtp-operator-validating-webhook-configuration
6. Delete finalizers from each migrated service instance and service binding.
7. Delete migrated service bindings.
8. Delete migrated service instances.
## Results
Your service instances and service bindings are now migrated from another environment to the Kyma environment, and you manage them from the SAP BTP service operator in your Kyma cluster.