Move a Project Between Organizations

[bmertens-datum]

Proposal: Allow admins and owners to move a project between organizations

Right now, once a project is created, it’s stuck in the organization where it originated. If an org gets restructured, renamed, merged, or split, there’s no good way to reassign a project without doing a bunch of manual work or recreating it from scratch.

A few teams have asked for a cleaner, supported way to move a project from one organization to another. This discussion is to scope what that could look like and surface any concerns.

---

Why this matters

• Mistakes during setup (wrong org) are hard to fix today.
• Customers reorganize, and we should support that without friction.
• Manual migration is error-prone and breaks audit history.

A move operation would save a lot of overhead and reduce support cases.

---

Who should be able to do this?

The proposal is that organization owners and admins should be allowed to move a project between organizations they have rights in.

We’d audit every move so it’s clear who moved what, when, and from/to which org.

---

What the move should include

If we support this, a move would ideally carry over:

• Project metadata (name, ID, labels)
• All project-scoped resources (services, policies, configs, secrets, etc.)
• Project-level RBAC bindings, as long as they make sense in the target org

After the move, the project should inherit the target org’s org-level settings and policies.

---

Things we need to figure out

There are a few open questions worth discussing:

• What happens if a project references identities that don’t exist in the target org?
• How strict should validation be? Should we allow a move only when all conditions are met, or allow “soft” failures with warnings?
• Should billing history stay with the old org (likely yes) while future usage goes to the new org (also yes)?
• Are there resource types that can’t be safely moved today?

---

Failure / rollback

If validation fails, we should block the move with clear errors.

If the actual move fails partway through, we should roll back cleanly to the original organization to avoid leaving a project in a broken state.

---

What success looks like

• Admin/owner clicks “Move Project”
• Selects target org
• Passes validation
• Project appears under the new organization
• No resource recreation needed
• Billing switches over at the time of the move
• Audit entry created

---

Feedback welcome

Are there edge cases we’ve missed?
Any concerns about RBAC, billing, or specific resource types?
Should this be exposed via UI, API, or both?

Would love input from anyone who has tried to reorganize projects manually or run into pain here.