Transfer (migrate) a project to an environment in Jitterbit Integration Studio
Introduction
Project transfer moves projects between environments within a single Harmony organization. This feature helps you promote design changes through your development lifecycle. Use project transfer to maintain separate development, testing, and production environments. Project transfer ensures controlled deployment of changes.
Project transfer provides controlled deployment by moving projects or components through development stages in a planned way. It maintains environment isolation by keeping development, testing, and production separate. Project transfer creates an audit trail to track transfer history for compliance.
You can use project transfer to accomplish the following:
- Move projects or components between environments in the same organization.
- Promote changes through development stages.
- Maintain environment-specific configurations.
- Preserve transfer history and dependencies.
Note
To move projects between organizations, see Project exports and imports.
You can transfer projects using either of these two options:
-
Full project transfer: Transfer the entire project into an environment. (This option appears as Migrate in the current interface.)
-
Selective transfer (Beta): Transfer only specified components into an environment.
The following table compares the key features of each transfer option:
Feature | Migrate | Selective transfer (Beta) |
---|---|---|
Components moved | Entire project (all components) with user-selected project variables | User-selected components |
Change detection | None | Component level:
|
Cardinality | One source project to many targets | One source project to many targets |
Directionality | Bi-directional | One way |
Note
You can transfer projects or components whether they have been deployed or not.
Prerequisites
Before transferring a project or project component, complete these requirements:
-
Make sure you have appropriate access in both source and target environments.
-
Verify the target environment has the necessary agent type (cloud or private) if using features that are limited to a certain agent type.
Important
Projects using private agent-only connectors or endpoints created with them cannot be transferred to cloud agent environments.
Transfer chains
A transfer chain is a linked sequence of environments through which a project moves during its lifecycle. Once established, these chains create dependencies that you must manage carefully.
Typical transfer flow
A typical workflow involves these steps:
[Development] → [QA/Testing] → [Production]
↓ ↓ ↓
(Create) (Test/Fix) (Go Live)
- Create a project in a development environment.
- Transfer to a QA (Quality Assurance) environment for testing.
- Fix any issues in the development environment.
- Transfer to the QA environment again for retesting.
- Transfer from QA to production when ready.
- Repeat steps 3-5 for ongoing changes.
Project transfers are based on internal IDs, not names, so renamed projects maintain their transfer relationships.
ID-based transfer example
- Transfer Project A from a development environment to a QA environment. A new project named Project A is created in the QA environment.
- Rename Project A to Project B in the development environment.
- Transfer components from Project B in the development environment to the QA environment. The existing project in the QA environment (named Project A) is updated.
The system recognizes these as the same project based on their internal ID, regardless of name changes.
Chain dependencies
Project transfer creates these permanent dependencies between projects:
-
Projects cannot be deleted if dependent projects exist downstream.
-
Chains cannot be broken without deleting downstream projects.
-
Renaming projects does not affect chain relationships.
A transferred project has a dependency on the project it was transferred from. You can't delete a project at the start of a transfer chain until you delete all projects farther down the chain. For more information, see Delete a project in Project creation and configuration.
You can only break a transfer chain by deleting projects farther down the chain or by exporting and importing the project. For more information, see Project exports and imports. Renaming a transferred project does not break the chain.
Note
Only project exports and imports can create independent copies.
Best practices
We recommend these best practices when designing a transfer chain:
-
Make design changes only in the first environment in the chain. In the typical transfer flow example, this is the development environment. In later environments, we recommend that you only change project variable values. Make these changes within the Integration Studio application so they appear in the project history. Project variable value changes made from the Management Console Projects page don't appear in the project history. During project transfer, you can select whether to transfer all project variable values or only selected project variable values (described in the next section).
-
Make the first environment in the chain accessible to those who may need to make changes to the project over time. We recommend against a single developer designing the project in a personal organization. If this happens, first export the original project and then import it into the environment that will start the chain. Make future changes to the project in the environment that starts the chain.
Project transfer
You can transfer projects using either of these two options:
- Full project transfer: Transfer the entire project into an environment. (This option appears as Migrate in the current interface.)
- Selective transfer (Beta): Transfer only specified components into an environment.
Transfer a full project
When you transfer a full project using the Migrate option, all project components and project metadata are transferred.
Caution
When transferring a project, note these considerations for schedules:
- When an operation with an associated schedule is transferred and deployed to a target environment for the first time, the schedule is created and enabled by default, regardless of the schedule's enablement state in the source environment. After the initial deployment, the schedule's enablement state in the target environment remains unchanged by subsequent transfers and deployments. Schedules can only be enabled and disabled through the Management Console's Schedules tab in the Projects page.
- When transferring a source environment operation without an assigned schedule to a target environment operation with an assigned schedule, the resulting operation in the target environment will not have an assigned schedule.
The Migrate option is accessible from these locations:
- The project toolbar. For more information, see Project actions menu in Project toolbar.
- The design canvas. For more information, see Deploy/migrate actions menu in Design canvas.
When you select Migrate, a configuration screen opens. You can choose the target environment and whether to transfer the values of individual project variables:
-
Organization and Project: The Harmony organization where the project resides and the name of the project to be transferred, separated by a comma.
-
Current environment and Target environment: The current environment where the project resides and the target environment where the project will be transferred to are listed along with their associated agent group type (cloud agent or private agent).
When the project is transferred, the existing project in the current environment remains unchanged. If the project has already been transferred to the target environment, the target environment project is overwritten using the selections for project variable values below.
Caution
If the source project uses connectors that are available only on private agents, you can't transfer it to an environment associated with a cloud agent group. These environments still appear in the Target Environment dropdown, but cannot be selected.
-
Project history tag name: Enter a tag to label the transfer event. The tag appears as a label on the transfer event and is recorded in the deploy details accessible from the project history. Entering a unique tag is recommended but not required.
-
Global Endpoints: Any global endpoints used by the project being transferred that don't exist in the target environment are listed. When the project is transferred, the global endpoint is added to that environment and needs configuration after transfer.
-
Migrate all variable values: Select this option to transfer all project variable values. If the project already exists in the target environment, the values of all project variables are overwritten. The first time a project is transferred, this option is selected by default. Later transfers default to Select variable values to migrate.
-
Select variable values to migrate: Select this option to transfer all project components and project metadata, except for the values of project variables listed under Exclude. If the project already exists in the target environment, all project components, including the values of project variables listed under Include, are overwritten.
When Select variable values to migrate is selected, no project variables are selected for transfer by default unless the project already exists in the target environment. When the project has already been transferred, newly added or renamed project variables are selected for transfer by default, but variables whose values have been changed are excluded.
- Search: Enter any part of a project variable name to filter the list of project variables in the current environment.
- Current environment: Select project variables whose values you want to transfer to the target environment. As you select project variables, they appear under Include. The Select all and Deselect all links add or clear all project variable selections at once.
- Exclude: Project variables whose values are excluded from transfer. If the project already exists in the target environment and already contains the project variable, its existing value in the target environment is kept. If the project variable doesn't already exist, then the project variable component is transferred but isn't assigned any value.
- Include: Project variables whose values are included in transfer. If the project already exists in the target environment and already contains the project variable, its existing value in the target environment is overwritten.
-
Migrate: Click to transfer the project to the selected environment. If the project has already been transferred to the target environment, a message asks you to confirm that you want to transfer. This transfer overwrites the existing project in the target environment using the selections for project variable values above.
Dialog text
Confirm Migrate
A project with the same name in the target environment already exists. Are you sure you want to overwrite it?When you click Continue, if the transfer to the target environment succeeds, the transferred project opens in the project designer.
Transfer components from a project (Beta)
Note
To provide feedback on this beta feature, contact the Jitterbit Product Team.
Selective transfer lets you transfer only specified components from a project. This feature helps you avoid interfering with work that other collaborators are doing in the same project and environment. Use selective transfer when you want to promote your changes without overwriting other users' work in the target environment.
To transfer only specified components from a project, use the project actions menu or operation actions menu in a project and click Selective Transfer:
On the configuration screen, you select the target environment and components to transfer:
Caution
After the initial transfer establishes a direction between two projects, all later transfers must follow the same direction. For example, if you transfer from Development to QA, you cannot later transfer from QA back to Development. This restriction applies to each project pair individually. Other projects in the same environments may have different transfer directions.
This limitation doesn't apply when performing a full project transfer (using Migrate).
Component selection
You can select individual components based on your needs. When you select components to transfer, the system automatically includes required dependencies.
Caution
When transferring project components, note these considerations for schedules:
- When an operation with an associated schedule is transferred and deployed to a target environment for the first time, the schedule is created and enabled by default, regardless of the schedule's enablement state in the source environment. After the initial deployment, the schedule's enablement state in the target environment remains unchanged by subsequent transfers and deployments. Schedules can only be enabled and disabled through the Management Console's Schedules tab in the Projects page.
- When transferring a source environment operation without an assigned schedule to a target environment operation with an assigned schedule, the resulting operation in the target environment will not have an assigned schedule.
The system groups components based on their status in the source and target environments:
-
Create: Components that exist in the source project but not in the target project. When selected, these components are created in the target project.
-
Overwrite: Components that exist in both projects but have different content based on last-modified date and user comparison. When selected, these components are overwritten in the target project.
-
Delete: Components that exist in the target project but not in the source project. When selected, these components are removed from the target project.
-
Unchanged: Components that exist in both projects and have the same content based on last-modified date and user comparison. These components cannot be selected.
You can select or deselect components in the Create, Overwrite, and Delete categories to configure your transfer.
Configuration options
-
Target environment: Choose the environment where you want to transfer the selected components.
Warning
If an unrelated project with the same name already exists in the target environment (not part of the transfer chain), the transfer cannot proceed. You see an empty screen. In this case, you must rename one of the projects before attempting the transfer.
-
Project history tag name: Enter a tag to label the transfer event for tracking in project history. In subsequent transfers, components are displayed with the project history tag name. This helps you identify which version each component came from when deciding whether to overwrite during future transfers.
-
Global endpoints: Global endpoints not in the target environment are automatically added during transfer. The same configurations as in the current environment are used.
-
Project variables and Include values: When you select a project variable to include in the transfer, you can decide which project variable values to include or exclude from the transfer using its Include value checkbox. Your selections are saved for later transfers to the same target environment.
-
Show: Show hidden data for Last Modified. Click to display this information.
-
Hide: Hide visible data for Last Modified. Click to hide this information.
-
Transfer: Start the transfer process with your selected components and configuration. When the transfer is complete, a confirmation dialog appears with an option to open the project in the target environment.
-
Cancel: Cancel the transfer and return to the project.