Preparing to Migrate

Overview

Please review this topic and any related linked topics before you perform an instance migration.

Perform a backup

While the risk of issues during a migration is much smaller than performing an in-place upgrade, it is still prudent to take a backup of your Matillion ETL instance before migrating. Refer to the following topics for more information:

• AWS Backups.
• GCP Backups.
• Azure Backups.

Create a target instance

If you don't have a target Matillion ETL instance (where you are migrating resources to) created already, you will need to launch it before migrating.

• If you're a Matillion Hub customer, please read Matillion ETL Instance Creation.
• If you're not a Matillion Hub customer, read Non-Hub Existing Customers.
• If you're not a Matillion Hub customer but would like to become one, please read Matillion Hub Overview.

Make sure that the target Matillion ETL instance:

• Is running a version of Matillion ETL that is identical to or newer than the source instance. For example, if the source instance is running version 1.53, then the target instance must be running version 1.53 or newer.
• Is on the same cloud data warehouse service as the source instance. For example, Snowflake to Snowflake.
• Is hosted on the same marketplace platform as the source instance. For example, AWS to AWS.
• Is given the same cloud privileges as the original, including feature access rights and firewall rules.
• Allows incoming TCP/IP connections from the source Matillion ETL server.
• Has the hostname artifacts.matillion.com whitelisted, to allow the target instance to update.
• Does not connect to the same Matillion ETL database as the source Matillion ETL server.

Security

• Any connections are secured so that data is protected while in transit.
• The user credentials (see User Configuration) that you plan to use to authenticate to each instance (source and target) have the necessary server-level user roles assigned, as follows:
  • API (this applies to all migrations).
  • Global Project Admin (applies when migrating project content such as orchestration jobs, transformation jobs, environments, passwords, queues, schedules, variables, versions, CDC configuration, and CDC tasks).
• All users should be logged out when performing a migration. This is recommended to avoid any issues with changes to resources that are actively being worked on, or any credentials that are in use.