Migrating to an Amazon RDS for PostgreSQL Instance

This topic tells you how to migrate from a Amazon Relational Database Service (Amazon RDS) for PostgreSQL instance of the VMware Tanzu Service Broker for AWS tile to the Tanzu Cloud Service Broker for AWS tile.

About Migrating Data to an Amazon RDS for PostgreSQL Instance

Because the VMware Tanzu Service Broker for AWS (hereafter referred to as the legacy broker) tile is going out of support, it is important to move from PostgreSQL instances that were created by the legacy broker over to the Cloud Service Broker for AWS.

The Cloud Service Broker for AWS plans are configurable. When migrating, examine the configuration of the plans in use with the legacy broker and create matching plans in the Cloud Service Broker for AWS.

You can use the AWS Data Migration Service (DMS) to migrate data between Amazon RDS for PostgreSQL Instances. The tool copies data from one database to another. Because the original database is not modified, you can reverse the migration if you detect any problems. It also allows migration to happen over time.

The DMS is a tool provided as part of AWS. For more information about AWS DMS, see the AWS documentation.

Matching Configuration

Both the legacy broker and the Cloud Service Broker for AWS allow you to customize service plans. Create plans in the Cloud Service Broker for AWS that match the plans used in the legacy broker. It may be useful to create a test service instance and compare the properties in the AWS console. For instructions on how to configure plans, see Configure Services with Cloud Service Broker for AWS.

Migrating Data

You might want to migrate data from instances created with the legacy broker to instances created with the Cloud Service Broker for AWS.

Important: Migration of data might incur app downtime. The amount of downtime depends on the method chosen.

There are many options for performing data migration which include AWS DMS, manual data migration, and options available from other vendors. For more information about the data migration process, refer to the documentation for the option that you choose.

In general, the data migration steps are:

Create a backup of the PostgreSQL instance.
Create an Amazon RDS for PostgreSQL instance using the Cloud Service Broker for AWS.
Replicate the data from a legacy broker PostgreSQL instance into the newly created instance.
Unbind apps from the legacy broker PostgreSQL instance and bind them to the newly created instance.
After migration is complete, you can stop on-going migration and optionally delete the legacy broker PostgreSQL instance.

For more detailed steps showing the Cloud Foundry commands necessary to use AWS DMS, see Migrate Data from a VMware Tanzu Service Broker for AWS PostgreSQL Instance.

Migrate Data from a Legacy PostgreSQL Instance

To migrate data from an existing legacy PostgreSQL instance to the Cloud Service Broker for AWS:

Create a backup of the legacy PostgreSQL instance.
Get credentials for the legacy PostgreSQL instance details by running:
```
cf env APP-USING-LEGACY-SERVICE-INSTANCE
```
Where is APP-USING-LEGACY-SERVICE-INSTANCE is the name of an app that is bound to a service instance from the legacy broker. Inspect the VCAP_SERVICES JSON output to see the hostname, database, username, password, and port which are required to configure DMS.
Create a new PostgreSQL service instance using Cloud Service Broker for AWS.
Create a service key in the new PostgreSQL service by running:
```
cf create-service-key SERVICE-INSTANCE-NAME SERVICE-KEY-NAME
```
Where SERVICE-INSTANCE-NAME is the name of the new PostgreSQL service instance and SERVICE-KEY-NAME is a name that you choose for the service key.
Get credentials from the service key by running:
```
cf service-key SERVICE-INSTANCE-NAME SERVICE-KEY-NAME
```
Inspect the JSON output for the hostname, name, username, password, and port which are required to configure data migration.
Configure and run data migration, for example, by using AWS DMS. For how to configure data migration, see the documentation for the process you have chosen.

Note: A data migration process might create schemas and tables without granting access for other users to work with that data. You can resolve this by connecting to the database using the credentials used for DMS, and granting the `binding_user_group` access to the schemas and tables. Alternatively, if you are not using continuous migration, for example, AWS DMS Change Data Capture, delete the service key used for data migration. This re-assigns data ownership to the `binding_user_group` role, automatically giving access to other users.
Disconnect the app from the legacy service binding by running:
```
cf unbind-service APP-NAME LEGACY-SERVICE-INSTANCE
```
Where:
- APP-NAME is the app using the PostgreSQL instance.
- LEGACY-SERVICE-INSTANCE is the name of the VMware Tanzu Service Broker for AWS-brokered PostgreSQL instance.
For example:
```
$ cf unbind-service my-app my-old-instance
```
Bind the app to the new service instance by running:
```
cf bind-service APP-NAME NEW-SERVICE-INSTANCE
```
Where NEW-SERVICE-INSTANCE is the name of the Cloud Service Broker for AWS service instance that you created in step 2 above.

For example:
```
$ cf bind-service my-app my-csb-aws-instance
```
Because Cloud Service Broker for AWS creates new credentials at bind time, this creates new binding credentials for the app.
Restage the app:
```
cf restage APP-NAME
```
After the migration is successful, you can stop continuous migration and remove the legacy service instance.