[Guide] Regional Migration Guide

Regional Migration Guide

Date: 2019-09-19
Prepared By: Solutions Engineering

What is Regional Migration?

SendBird currently provides global instance coverage in 6 different regions (Tokyo, Seoul, Singapore, Frankfurt, Oregon, West Virginia) where will serve as a database for our customers.
For customers with high traffic (100,000 MAU and above) we recommend choosing the region closest to their end-users.
The regional migration happens when our customers decide to move their region to the different region that is the closest and this guide includes setup and steps to migration the instance from one region to another region.

Setup

Before we begin, let’s go over the terminology that will be used in this guide.

  1. Source Instance: original instance (i.e. Free tier - Tokyo) that customer wants to migrate from
  2. Target Instance: new instance that customer wants to migrate to

Setup before migration action

  1. Ask SendBird to give you access to your target region for your new app
  2. Create a new app with a target region (Dashboard > create app)
  3. Turn on the data export API on the source instance (contact our Sales Team)
  4. Turn on the migration API on the target instance (contact our Sales Team)

Steps

Now we have everything set up, let’s begin the actual migration.

  1. Data Export
    Download all the messages with the desired time range in Dashboard>Data Export
  1. Migration API to move the downloaded messages from the source instance to the target instance. (https://docs.sendbird.com/platform/migration)

    The migration process takes smaller 3 steps that are written below:
    A. Register the users of your current chat solution to your SendBird application.
    You can migrate the users into the SendBird system using the user creation API.

    B. Create either an open or a group channel to migrate the messages of your chat solution. The SendBird system doesn’t create a channel for your migration automatically.

    C. The maximum number of migrated messages per call is 100. To avoid failure during your migration, you must adjust the number of messages to process at once via the API.