Pre-move validation checklist
Validate organization-level dependencies before moving a project across organizations.
Moving a project from one organization to another requires careful planning to maintain service continuity and prevent broken dependencies. This checklist helps you identify what might break during the move so you can plan accordingly.
What you will learn in this topic
By the end of this topic, you will be able to:
Identify organization-level dependencies that will break during a project move.
Validate pipelines, connectors, secrets, and access controls before the move.
Understand important considerations and limitations for project moves.
Before you begin
Before you move a project between organizations, make sure you have:
Account Admin or Organization Admin permissions: You need these permissions to move projects and set up access controls. Go to RBAC in Harness to review roles.
Access to both organizations: You need permissions in both the source and destination organizations to check what resources exist and recreate them where needed.
Inventory of organization-level resources: Make a list of all connectors, secrets, templates, policies, and access controls your project uses at the organization level.
No running pipelines: Make sure all pipelines in the project have finished running before you start the move.
Check dependencies before moving a project
Before you move a project, review these items for organization-level dependencies that will break after the move.
This list covers the most common issues. Your project might have additional organization-level dependencies not listed here.
Pipelines
Organization-level connectors
Pipelines that use connectors from the organization level will break after the move.
Organization-level secrets
If your pipelines use secrets scoped at the organization level, those secrets will no longer be accessible in the new organization.
Organization-level templates
Templates used to build pipelines might be scoped at the organization level. Make sure these templates exist in the destination organization, or your pipelines will fail to render or execute.
Hardcoded organization identifiers
YAML files might include hardcoded references such as orgIdentifier. These will still point to the old organization, but this will not affect pipeline execution.
Pipeline chaining
If you use pipeline chaining, moving the child pipeline will break the chain. Go to Pipeline chaining for details.
Running pipelines
Any pipelines currently running will fail when the move starts. Finish all pipeline runs before you begin the move.
Notifications
Organization-level channels
Notification rules that use channels from the organization level will break after the move.
User group notifications
Email notifications that use organization-level user groups will stop working.
Git Experience
Git file paths
Git file paths will become outdated after the move because they still point to the old organization in URLs and navigation links.
Services
Manifest and artifact sources
Services that use manifest sources and artifact sources with organization-level connectors will break.
Environments
Configuration files
Environment configurations, application settings, manifest sources, and connection strings that reference organization-level resources will become unavailable.
Service overrides and infrastructure
Service overrides, infrastructure definitions, and GitOps clusters that reference organization-level resources will break.
Monitored services
Organization-level resources
Services or environments that reference organization-level resources will become inaccessible after the move.
Webhooks
Connectors and secrets
Git connectors, generic webhooks, and Slack webhooks that use organization-level connectors or secrets will break.
Custom webhook triggers
Custom webhook triggers will stop working.
Access control
Organization-level RBAC components
User groups and service accounts inherited from the organization level do not move with the project. You will need to recreate them in the destination organization if your project still 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.
Temporary access restrictions
Project-level access controls (users, service accounts, user groups, role bindings, resource groups, and roles) move with the project, but this happens in the background. 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 will appear in the destination organization.
Policy management
Project-level policies
Project-level policies and policy sets move with the project to the destination organization.
Organization-level policies
Organization-level policies referenced by the project will no longer be accessible. You might need to recreate these policies in the destination organization or update your policy sets to use policies that exist there.
Policy set references
Policy sets that reference organization-level policies will break and need to be updated to use policies from the destination organization.
Terraform
State file inconsistencies
Terraform state and configuration files that reference the project might become inconsistent after the move.
Provider identifiers
Resources created with the Harness Terraform Provider include organization and project identifiers. After the move, these identifiers will not match the new organization.
Related articles
Post-move remediation guide - Fix issues after moving a project.
Create organizations and projects - Manage organizations and projects in Harness.
RBAC in Harness - Understand roles and permissions.
Last updated
Was this helpful?