Preparing to Migrate
  • Dark

Preparing to Migrate

  • Dark


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:

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.

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 whitelisted, to allow the target instance to update.
  • Does not connect to the same Matillion ETL database as the source Matillion ETL server.


  • 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.

Permissions still apply as usual to both the source user and target user. For example, if the target instance user does not have permission to write Shared Jobs, then that user cannot import Shared Jobs via the Migrate wizard. Read Manage Permissions for more information on how these are set.