Move Harness Projects Between Orgs Without Downtime | Harness Blog

TLDR: We have rolled out Project Movement: the ability to transfer entire Harness projects between Organizations with a few clicks. It's been our most-requested Platform feature for a reason. Your pipelines, configurations, and rest come along for the ride.

What are Projects and Organizations?

In Harness, an Account is the highest-scoped entity. It contains organizations and projects. An organization is the space that represents your business unit or team and helps you manage users, access, and shared settings in one place. Within an organization, a project is where your teams do their day-to-day work, such as building pipelines, managing services, and tracking deployments. Projects keep related resources grouped together, making it easier to collaborate, control permissions, and scale across teams.

‍

The main benefit of keeping organizations and projects separate is strong isolation and predictability. By not allowing projects to move between organizations, you can ensure that each organization serves as a rigid boundary for security, RBAC, governance, billing, and integrations. Customers could trust that once a project was created within an org, all its permissions, secrets, connectors, audit history, and compliance settings would remain stable and wouldn’t be accidentally inherited or lost during a move. This reduced the risk of misconfiguration, privilege escalation, broken pipelines, or compliance violations — especially for large enterprises with multiple business units or regulated environments.

However, imagine this scenario: last quarter, your company reorganized around customer segments. This quarter, two teams merged. Next quarter, who knows—but your software delivery shouldn't grind to a halt every time someone redraws the org chart.

We've heard this story from dozens of customers: the experimental project that became critical, the team consolidation that changed ownership, the restructure that reshuffled which team owns what. And until now, moving a Harness project from one Organization to another meant one thing: start from scratch.

Not anymore.

That’s why we have rolled out Project Movement—the ability to transfer entire Harness projects between Organizations with a few clicks. It's been our most-requested Platform feature for a reason. Your pipelines, configurations, and rest come along for the ride.

What Moving a Project Actually Feels Like

You're looking at 47 pipelines, 200+ deployment executions, a dozen services, and countless hours of configuration work. The company's org chart says this project now belongs to a different team. Deep breath.

Click the menu. Select "Move Project." Pick your destination Organization.

The modal shows you what might break—Organization-level connectors, secrets, and templates that the project references. Not an exhaustive list, but enough to know what you're getting into.

Type the project identifier to confirm.

Done.

Your project is now in its new Organization. Pipelines intact. Execution history preserved. Templates, secrets, connectors—all right where you left them. The access control migration happens in the background while you grab coffee.

What used to take days of YAML wrangling and "did we remember to migrate X?" conversations now takes minutes.

To summarize:
To move a Harness project between organizations:

1. Open the project menu and select “Move Project.”

2. Choose the destination organization.

3. Review impacted organization-level resources.

4. Confirm by typing the project identifier.

5. Monitor access control migration while pipelines remain intact.

‍

What Moves with Projects

Here's what transfers automatically when you move a project:

• Platform - Your pipelines with their full execution history, all triggers and input sets, services and environments, project-scoped connectors, secrets, templates, delegates, and webhooks.
• Continuous Delivery (CD) - All your deployment workflows, service definitions, and infrastructure configurations. If you built it for continuous delivery, it moves.
• Continuous Integration (CI) - Build configurations, test intelligence settings, and the whole CI setup.
• Internal Developer Portal (IDP) - Service catalog entries and scorecards.
• Security Test Orchestration (STO) - Scan configurations and security testing workflows.
• Code Repository - Repository settings, configurations, and more.
• Database DevOps - Database schema management configurations and more.

Access control follows along too: role bindings, service accounts, user groups, and resource groups. This happens asynchronously, so the move doesn't block, but you can track progress in real-time.

The project becomes immediately usable in its new Organization. No downtime, no placeholder period, no "check back tomorrow."

What doesn’t Move with Projects?

Let's talk about what happens to Organization-level resources and where you'll spend some time post-move.

Organization-scoped resources don't move—and that makes sense when you think about it. That GitHub connector at the Organization level? It's shared across multiple projects. We can't just yank it to the new Organization. So after moving, you'll update references that pointed to:

• Organization-level connectors (GitHub, Docker Hub, cloud providers)
• Organization-level secrets (API keys, credentials)
• Organization-level templates (shared pipeline components)
• User groups inherited from the source Organization

After the move, you'll update these references in your pipelines and configurations. Click the resource field, select a replacement from the new Organization or create a new one, and save. Rinse and repeat. The pre-move and post-move guide walks through the process.

A few CD features aren't supported yet, but on the roadmap: GitOps entities, and Continuous Verification don't move with the project. If your pipelines use these, you'll need to manually reconfigure them in the new Organization after the move. The documentation has specific guidance on supported modules and entities.

‍

Security Boundaries Stay Intact

The Harness hierarchical model, Account > Organization > Project, exists for strong isolation and predictable security boundaries. Moving projects doesn't compromise that architecture. Here's why: Organization-level resources stay put. Your GitHub connectors, cloud credentials, and secrets remain scoped to their Organizations. When a project moves, it doesn't drag sensitive org-wide resources along; it references new ones in the destination. This means your security boundaries stay intact, RBAC policies remain predictable, and teams can't accidentally leak credentials across organizational boundaries. The project moves. The isolation doesn't.

An Example of Moving Projects

A platform engineering team had a familiar problem: three different product teams each had their own Harness Organization with isolated projects. Made sense when the teams were autonomous. But as the products matured and started sharing infrastructure, the separation became friction.

The platform team wanted to consolidate everything under a single "Platform Services" Organization for consistent governance and easier management. Before project movement, that meant weeks of work—export configurations, recreate pipelines, remap every connector and secret, test everything, hope nothing broke.

With project movement, they knocked it out in an afternoon. Move the projects. Update references to Organization-level resources. Standardize secrets across the consolidated projects. Test a few deployments. Done.

The product teams kept shipping. The platform team got its unified structure. Nobody lost weeks to migration work.

Try It (With Smart Guardrails)

Moving a project requires two permissions: Move on the source project and Create Project in the destination Organization. Both sides of the transfer need to agree—you can't accidentally move critical projects out of an Organization or surprise a team with unwanted projects.

When you trigger a move, you'll type the project identifier to confirm.

A banner sticks around for 7 days post-move, reminding you to check for broken references. Use that week to methodically verify everything, especially if you're moving a production project.

Our recommendation: Try it with a non-production project first. Get a feel for what moves smoothly and what needs attention. Then tackle the production stuff with confidence.

Why This Took Time (A Peek Behind the Scenes)

On the surface, moving a project sounds simple-just change where it lives, and you’re done. But in reality, a Harness project is a deeply connected system.

Your pipelines, execution history, connectors, secrets, and audit logs are all tied together behind the scenes. Historically, Harness identified these components using their specific "address" in the hierarchy. That meant if a project moved, every connected entity would need its address updated across multiple services at the same time. Doing that safely without breaking history or runtime behavior was incredibly risky.

To solve this, we re-architected the foundation.

We stopped tying components to their location and introduced stable internal identifiers. Now, every entity has a unique ID that travels with it, regardless of where it lives. When you move a project, we simply update its parent relationship. The thousands of connected components inside don’t even realize they’ve moved.

This architectural shift is what allows us to preserve your execution history and audit trails while keeping project moves fast and reliable.

What's Coming

This is version one. The foundations are solid: projects move, access control migrates, pipelines keep running. But we're not done.

We're listening. If you use this feature and hit rough edges, we want to hear about it.

The Bottom Line

Organizational change is inevitable. The weeks of cleanup work afterward don't have to be.

Project Movement means your Harness setup can adapt as fast as your org chart does. When teams move, when projects change ownership, when you consolidate for efficiency, your software delivery follows without the migration overhead.

No more lost history. No more recreated pipelines. No more week-long "let's just rebuild everything in the new Organization" projects.

Ready to try it? Check out the step-by-step guide or jump into your Harness account and look for "Move Project" in the project menu.

‍