Skip to main content

Move a project (Closed Beta)

Last updated on

Harness allows you to move a project from one organization to another within your account. This is useful when you need to transfer project ownership between teams or restructure your organization hierarchy.

This feature is currently in closed beta and available for select accounts only. Access is determined based on the currently supported modules and entities.

Feature availability

This feature requires the PL_PROJECT_MOVEMENT_ENABLED feature flag. Contact Harness Support to enable it.

What will you learn in this topic?​

By the end of this topic, you will be able to:

Before you begin​

Before you move a project between organizations, make sure you have:

  • Appropriate permissions: The core_project_move permission to move project from source project and core_project_create permission to create projects in destination organization. Go to RBAC in Harness to review roles.
  • Review of supported modules: Confirm that your project uses only supported modules and entities. Go to Supported modules to check compatibility.
  • Pre-move validation: Review the pre-move checklist to understand what will break during the move. Go to Pre-move validation checklist to prepare.

What happens when you move a project​

When you move a project from one organization to another, the following changes occur:

Entities move with the project​

Entities from the supported modules (such as pipelines, services, and environments) move with the project to the destination organization.

Organization-level resources become inaccessible​

Resources scoped at the organization level (connectors, secrets, templates, webhooks, and notifications) become inaccessible after the move. You need to recreate these resources in the destination organization and update project references to point to the new resources. Go to Pre-move validation checklist to review what will break.

Access control components​

  • Organization-level RBAC components: User groups and service accounts inherited from the organization level do not move with the project. You need to recreate them in the destination organization if your project needs them. Roles reused from the organization level also stay behind. Go to Create groups by inheritance and Hierarchical support for service accounts for details.
  • Project-level access control components: Project-level access controls (users, service accounts, user groups, role bindings, resource groups, and roles) move with the project asynchronously. Users might temporarily lose access during the move.

Audit logs​

  • Historical logs: Audit logs from before the move stay in the source organization. They do not transfer with the project.
  • Broken links: Links in old audit logs that point to the project will break because they still reference the old organization.
  • New logs: After the move, new audit logs for the project appear in the destination organization.

Go to Pre-move validation checklist and Post-move remediation guide for detailed validation and remediation steps.

Supported modules​

Project moves are supported for the following Harness modules:

Go to Harness entity reference for details about all Harness entities.