Migration playbook

Prerequisites

Before you begin:

  • Consult with your CSM about scope, the desired timeframe, and other requirements.
  • Choose the members from your organization for the migration team.
  • Engage your internal stakeholders to understand how downstream processes and applications use data processed by the SnapLogic Platform. All systems and applications that call public APIs and tasks will need to change the URLs (unless you use custom URLs).
  • Communicate business cycles and commitments to the team so that the migration can be planned around them.
  • Environments usually contain assets that are used only for development or that are no longer operational. If you can identify these and remove them, it greatly simplifies the migration process.

Migration team

The migration team should include at least one person in each of the following roles:

  • From your organization: Environment admin, Integration developer, QA
  • From SnapLogic: Customer Success Manager (CSM), Professional Services (PS), Project Manager

Playbook

The following tables outline the steps required in the source and target environments and indicate who is responsible for each step. Follow the links to access detailed instructions.

Table 1. Source environment
Step Responsible party Description Estimated time
1) Grant Environment admin privileges to everyone on the migration team. Customer: Environment admin From the UI, refer to: Edit accounts. With an API, refer to: Update a user. < 1 hour
2) Set up a Service account (email and password to run APIs) with admin privileges. The migration tool uses this account, which can be deleted in both environments after successful migration. Customer: Environment admin Refer to Create a service account. 5 minutes
3) Audit the environment to identify requirements. SnapLogic: CSM and PS Run the migration tool to discover source environment assets and save results. The CSM also confirms contractual product and feature entitlements. 4 hours
Table 2. Target environment
Step Responsible party Description Estimated time
1) Provision the new environment. SnapLogic: CSM and PS SnapLogic creates the environment with the same entitlements and Cloudplexes as the source environment. < 1 hour
2) If required, set up SSO, GitHub Integration, and Secrets Management. Customer: Environment admin

Refer to the following for details:

 < 1 hour
3) Reproduce the rest of source environment settings in target, including uploading custom and private Snap Packs. (The CSM and PS supply a text file with the source environment settings.) Customer: Environment admin

Refer to the following for details:

 2 hours
4) Verify environment settings. Customer: QA Check manually, or you might want to create a script. 1 hour
5) Configure the data plane (for Groundplexes only). Customer: Environment admin Refer to Migrate data plane. Environment-dependent
6) Migrate the foundational and integration assets. SnapLogic: PS Run the migration tool.
Important: After the migration of user accounts and integration assets is complete, you must track any changes in the source environment. These must be synchronized with the target environment to prevent drift.
Note: Steps 6 through 12 can be performed iteratively, per-project, or in phases, in a cadence worked out between you and the SnapLogic team members.
 1 day or more, depending on the number of assets
7) Validate the migrated assets. Customer: Environment admin, Integration developer The CSM and PS provide a report to use for validation. Verify that the migrated assets are present and correctly configured in the target environment. Environment-dependent
8) Synchronize Git-tracked projects by pulling from the repository. Customer: Integration developer, SnapLogic PS Environment-dependent
9) Configure accounts manually, if required. Customer: Environment admin Re-enter passwords and upload keys for accounts that require manual configuration. For example, for OAuth accounts you'll need to get a new access token. Environment-dependent
10) Enable the tasks required for testing to begin cut-over. Customer: Environment admin or Integration developer Refer to Enable and disable task. Environment-dependent
11) Update downstream applications with new task URLs, if required. Customer: Integration developer No change needed if you are using your own URLs. Environment-dependent
12) Begin cut-over from source to target environment. Customer: Integration developer After validating that downstream apps are working correctly, disable tasks in the source environment. Refer to Enable and disable task. Environment-dependent
13) QA verification. Customer: QA Perform manually or with a script. Environment-dependent
14) Acceptance testing. Customer: Environment admin, QA, Integration developer Refer to Acceptance testing. Environment-dependent