Migrate from Replicated

YugabyteDB Anywhere has ended support for Replicated installation. If your YugabyteDB Anywhere installation uses Replicated, use YBA Installer to migrate from Replicated.

You can migrate your existing Replicated installation to YBA Installer in place on the same VM (recommended). When migrating in place, both your Replicated configuration and the YBA metadata (universes, providers, and so on) are migrated to the YBA Installer format.

Alternately, you can migrate the Replicated installation to YBA Installer on a different VM. Only the YBA metadata (universes, providers, and so on) is migrated to the new VM; the Replicated configuration is not.

Before you begin

• Review the prerequisites.

• YBA Installer can perform the migration in place. Make sure you have enough disk space on your current machine for both the Replicated and YBA Installer installations.

• If your Replicated installation is v2.18.5 or earlier, or v2.20.0, upgrade your installation to v2.20.1.3 or later.

• If you haven't already, download and extract YBA Installer. It is recommended that you migrate using the same version of YBA Installer as the version of YBA you are running in Replicated. For example, if you have v.2.23.1.0 installed, use the following commands:

  wget https://downloads.yugabyte.com/releases/2.23.1.0/yba_installer_full-2.23.1.0-b220-linux-x86_64.tar.gz
  tar -xf yba_installer_full-2.23.1.0-b220-linux-x86_64.tar.gz
  cd yba_installer_full-2.23.1.0-b220/
  

Migrate from Replicated to YBA Installer in place

If you have high availability configured, you need to migrate your instances in a specific order. See In-place migration and high availability.

To migrate in place, do the following:

1. Optionally, configure the migration as follows:

   sudo ./yba-ctl replicated-migrate config
   

   This generates a configuration file /opt/yba-ctl/yba-ctl.yml with the settings for your current installation, which are used for the migration. You can edit the file to customize the install further.

   Note that the installRoot (by default /opt/ybanywhere) in yba-ctl.yml needs to be different from the Replicated Storage Path (by default /opt/yugabyte). If they are set to the same value, the migration will fail. You can delete yba-ctl.yml and try again.

   Install Root

   The installRoot must not be a subdirectory of the Replicated Storage Path (/opt/yugabyte and /opt/yugabyte/ybanywhere) or upon completion of replicated-migrate finish all data will be lost while cleaning up Replicated.

   For a list of options, refer to Configuration options.

2. Start the migration, passing in your license file:

   sudo ./yba-ctl replicated-migrate start -l /path/to/license
   

   The start command runs all preflight checks and then proceeds to do the migration, and then waits for YBA to start.

3. Validate YBA is up and running with the correct data, including Prometheus.

   If YBA does not come up or the migration has failed, you can revert to your Replicated installation using the replicated-migrate rollback command.

   After the new YBA comes up successfully, do not attempt to roll back to the original Replicated install of YBA. Rollback is only intended for scenarios where the migration fails. Any changes made with a new YBA (either using the UI or the API) are not reflected after a rollback.

   In particular, do not configure high availability until running the finish command (next step) on all instances.

4. If the new YBA installation is correct, finish the migration as follows:

   sudo ./yba-ctl replicated-migrate finish
   

   This uninstalls Replicated and makes the new YBA instance permanent.

In-place migration and high availability

If you have high availability configured, you need to upgrade the active and standby YBA instances if they are running older versions of YBA. In addition, you need to finish migration on both the active and standby instances for failover to be re-enabled.

Replicated uses HTTPS

Note that if your node has a timezone that is not UTC, in-place migration requires changing the timezone to UTC. If this is not possible, follow the instructions for Replicated uses HTTP instead.

If Replicated is using HTTPS, migrate as follows:

1. If your instances are v2.18.5 or earlier, or v2.20.0, upgrade your active and high availability standby instances to v2.20.1.3 or later.
2. Migrate and finish the active instance.
3. Migrate and finish the standby instances.

Failovers are only possible after you finish the migration on both the primary and standby.

Replicated uses HTTP

If Replicated is using HTTP (or any servers are configured with a timezone that is not UTC), you need to remove the standbys and delete the high availability configuration before migrating. Migrate as follows:

1. Remove the standby instances.
2. On the active instance, navigate to Admin > High Availability and click Delete Configuration.
3. If your instances are v2.18.5 or earlier, or 2.20.0, upgrade the primary and standby instances to v2.20.1.3 or later.
4. Migrate and finish the active instance.
5. Migrate and finish the standby instances.
6. Configure high availability on the updated instances.

Failovers are possible again after the completion of this step.

Migrate from Replicated to YBA Installer on a different VM

Note that the Replicated configuration is not migrated when using this method.

To migrate to a different VM, do the following:

1. Install and configure YBA Installer on a new VM.

2. Disable high availability (if configured) on the Replicated installation.

3. Perform a full backup of YBA on the Replicated installation.

   This backup includes Prometheus data and all imported releases.

   If the backup is too large, consider removing unused releases; and/or reducing the Prometheus retention interval in the Replicated Admin console.

4. Stop YBA on the Replicated installation using the Replicated UI or command line.

   This is a critical step, otherwise you could end up with two YBA instances managing the same set of universes, which can lead to severe consequences.

5. Transfer the full backup from Step 3 to the YBA Installer VM.

6. Restore the backup on the YBA Installer VM using the command line as follows:

   sudo yba-ctl restoreBackup --migration <path to backup.tar.gz>
   

7. Verify the resulting YBA Installer installation contains all the YBA metadata, such as universes, providers, backups, and so on, from the original Replicated installation.

8. Completely delete the Replicated installation or re-image the Replicated VM.